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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
