On Wed, 10 Aug 2005 09:24:22 +0200 Hilmar Berger <[EMAIL PROTECTED]> 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
