gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] re: non-serializability detection


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] re: non-serializability detection
Date: Wed, 19 Jan 2005 08:42:26 +0100
User-agent: Mutt/1.3.22.1i

> has it been sorted out what happens after backend notifications of commits?
Not for all thinkable cases. Also this will need to be handled
differently on a case-by-case basis.

> backend notifies client of another user's commit
> client checks if data has been dirtied by user.
Well, "client" is way to coarse grained.

Let's focus on the EMR:

The clinical record object gets notified about commits to "it's"
tables and flushes it's cache. This will not destroy the
business objects floating around in the application which are
now unlinked from the clinical record cache because Garbage
Collection does not kick in before *all* references to an object
are gone. And the widgets are still holding references to the
VOs they are dealing with. However, the widgets get notified
by the clinical record object that relevant data has changed.

*They* then tell the VOs that are managed by them to save
themselves to the backend - at which point concurrency
detection kicks in which then needs to be handled by the
widget. During that save the XMIN value gets updated. The
widget will then redisplay itself. To make this more
convenient for coders we have the cRegetOnPaintMixin.

Oh, and yes, after a concurrency conflict in save_payload() the
value object IS updated to the new values but does provide the
previously modified values in the class member modified_payload
so merge support widgets can take advantage of that. So,
throwing away our modified data is a no-op. Reverting to our
data means (perhaps selectively) copying from modified_payload
into self.__payload and calling save_payload() again. Retaining
the modified data and putting the new data into a class member
is not desirable because the value objects are supposed to
represent the true state of the backend as closely as possible.

> if dirtied,
>  -client fetches changed data,
>    and  user is showed changed data , and requested whether to :-
>       revert to updated data ,
>       revert to updated data and  diff of  old data and dirtied data 
> appended, 
>       or overwrite updated data.
This is how conflict resolution would work, roughly. We have
no code for that, yet, though.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]