Re: [Gnumed-devel] __db_cache updating

[Hilmar Berger]

On Wed, 10 Aug 2005 09:24:22 +0200
Hilmar Berger <address@hidden> wrote:


> or that two signals were send, the first triggering the frontend update while 
> the second somehow only triggered the deletion of 
> self.__db_cache['episodes']. I remember that there was exactly one call to 
> get_episodes after adding a health issue to a new patient (=my bug triggering 
> condition). 

I checked it again, there are indeed two calls to the callback after creating a 
health issue in a new patient. The first deletes __db_cache and then triggers 
the update of the EMR-tree widget. The second might delete episodes while the 
update of episodes (triggered by the first signal) is still underway. 
So, as Karsten suspected, there are concurrent signals that might interfer 
because of non-locking middleware variables. 
In addition, did we ascertain that updates triggered by a backend notification 
check if the respective cache entries are older than what is in the database 
(timestamps or similiar) ? This could reduce the amount of data we have to get 
from backend.
I remeber a related discussion on this list, but I'm not quite sure if we do. 

Hilmar