Fwd: Re: [Gnumed-devel] update database - no problem

[Syan Tan]

----- Original Message ----- 
From: Syan Tan  
To: Karsten Hilbert 
Sent: Wed Oct 10  4:27
Subject: Fwd: Re: [Gnumed-devel] update database - no problem


Transactions are good for automated writes , where there is a
bunch of writes which relate to each other in some way e.g.
foreign keys, numerical columns that are summed , 
so its good for concurrent batch processing. 
Long running held transactions where a compound record is opened
for interactive update doesn't fit the simple transaction model very well;
where there is just one level of transaction , if two or more 
clients open the same record for writing , first reading the 
record's values to cache on the client for display, modifying
an item's value based on its initially read value, then one client
would end up being forced to rollback unrelated changes in the medical
record done previously on a write conflict. the next choice is then
to open a transaction only just before changing an item's value, 
but in gnumed's case, if there is a conflict, this is only detected
when the second writer open's the same item to write and finds the
xmin value has changed ( ? correct). Another choice would be 
that within the transaction held to change a value, a completed 
notify loop is broadcast to all other clients , and aknowledgements
received that the other clients have received the changes,
then the transaction can be closed , and the other clients
would not have an opportunity to change the value because of
the held transaction. This is the eager vs. lazy approach of
change notification, which is currently with xmin. 

On Tue Oct  9 14:09 , Karsten Hilbert   sent:

>On Tue, Oct 09, 2007 at 11:50:20AM +0000, Syan Tan wrote:
>
>> There was a post about trying to justify using xmin, 
>> which was something like "it isn't pretty enough".
>Well, XMIN's pretty 'nuff for me at the moment. The thread
>was mainly to let Dave (and the list archive) know that:
>
>- yes we know XMIN can become a problem sometime later
>- yes we know how to solve that
>- yes we are open for patches to do so
>
>> Actually, isn't having data cached at clients in database
>> objects like having a replicated database when two or more
>> clients have opened the same medical record.
>multi-master, that is
>
>> So if one
>> could make it look pretty by implementing two-phase commit
>> protocol amongst all the clients as well as the server.
>That'd be possible but wouldn't exactly reduce complexity,
>methinks ?
>
>Karsten
>-- 
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel