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

[Karsten Hilbert]

On Wed, Oct 10, 2007 at 04:27:06AM +0000, Syan Tan wrote:

> 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 , 
That is what we use them for.

> Long running held transactions where a compound record is opened
> for interactive update doesn't fit the simple transaction model very well;
Yes, therefore the whole XMIN story.

> 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.
Ambler suggests that it is often possible to get smart about
*attribute* level non-collision where a container collision
was detected. We do so to some extent.

> 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).
Yep, correct, as it should be IMO. First write first serve.

> 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,
This would be too fragile. How do we know which clients to
signal ? (= registered in a table at connect -- but no
connect triggers in PG) If they are registered in a table we
know whom to signal but what about slow response, dead
client ? This seems like a lot of complexity for little
gain. If we don't care who needs to be notified
(NOTIFY/LISTEN) how do we know we successfully broadcasted
the change to all parties involved ?

Hence the approach is now that changes are broadcasted
*after* the fact by using NOTIFY in an on-commit trigger on
tables. So clients can reload their caches.

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