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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
