Re: [Gnumed-devel] further testing / bugs

[Karsten Hilbert]

On Mon, Aug 08, 2005 at 08:43:26PM +0200, Hilmar Berger wrote:

> > At the end of the day I have a nagging feeling that the root
> > of the evil is non-locking access to middleware variables ...

> If  _db_callback_episodes_modified() gets called
> asynchronously then this could well be the case.
Whenever a row is inserted into clin_episode an
after-trigger sends a NOTIFY to the the NOTIFY listeners.
One such listener happens to be our gmBackendListener code.
Which happens to run in a Python *thread* separate from the
GUI thread of the client.

Upon receiving the NOTIFY gmBackendListener will invoke the
callbacks registered for this NOTIFY. The only registered
listener is the method _db_callback_episodes_modified() in 
cClinicalRecord. This method flushes the "episodes" cache.
It then sends out a *dispatcher* signal "episodes modified".
The dispatcher sends it to its registered listeners for that
signal. Which (among others) happens to be a function in the
EMR tree widget. That function (or any other that happens to
come first) re-gets the episodes from cClinicalRecord
thereby triggering a delayed-until-now backend re-fetch into
the cache thereof.

Basically we'll probably have to:

a) serialize access to re-getting data from the cache so
   that later-but-concurrent cache accesses spin until
   the first one completes the refetch from the database

b) serialize access to the cache per-se such that cache
   flushes vs. cache regets happen atomically (where
   flushes would abort/restart current regets)

Important stuff. 0.2 won't be boring :-)

> I fail to understand why this callback is called at all when another signal 
> already forced an update of this clinical object.
Which would be which ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346