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

[ju0815nk]

> 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
> 
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel
> 

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!