[Gnumed-devel] auditing and the multiple-update problem

[Karsten Hilbert]

All,

I believe we have excluded the multiple update problem from
occurring now. Please correct me if I am wrong:

1) Courtesy of the Multi Versional Concurrency Control offered
   by PostgreSQL the multiple-update problem only applies to
   changes to one and the same existing row.
2) Hence only update and delete operations in any combination
   are affected.
3) We now set the default transaction isolation level for any
   connection made via gmPG to "serializable" (not checked
   into CVS yet). This means, that the database itself checks
   whether another concurrent transaction has committed a change
   to our row since we started our transaction (and thus took a
   snapshot of our row). If so, our transaction is aborted
   with a "can't serialize" error. This should not allow for
   races unless the database code is racey. We can thus safely
   redisplay the changed data and retry the commit.
4) All DELETEs and UPDATEs are audited hence any transaction
   succeeding under 3) and being overwritten by another
   transaction soon afterwards is not lost but merely executed
   and preserved as an audited version.

I cannot currently see any gaping holes in this scheme. Please
consider and point out if there is any thinko.

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