Re: [Gnumed-devel] Comments on 0.2

[Tim Churches]

address@hidden wrote:
> hash would tell you the row is different, but doesn't offer ordering , which 
> sequence numbers do.

Ordering is not important here - the purpose of checking the hash is to
ensure that the changes which the user has just asked the system to
commit are based on the most up-to-date version of the record. If the
hash has changed, the system needs to re-read the record and present the
updated (by someone else) information to the user and tell them to
review their edits in the light of the new information.

Tim C

> *On Thu Jun 22 3:53 , Tim Churches sent:
> 
> *
> 
>     Ian Haywood wrote:
>      >
>      > Tim Churches wrote:
>      >> Karsten Hilbert wrote:
>      >>> On Tue, Jun 20, 2006 at 10:38:29PM +1000, Tim Churches wrote:
>      >>>
>      >>>> What is wrong with just using a transaction. If the row is locked by
>      >>>> another transaction writing to it, then the transaction will abort. 
> No
>      >>>> need to mess around with explicit row locks, is there?
>      > Okay, let's think about this. We all accept the need for XMIN, it's
>     explicit locking
>      > we are querying.
>      >
>      > Imagine two transactions running in parallel. Postgres forces them to
>     serialize,
>      > (randomly if they hit the server at *exactly* the same time)
>      > Both do
>      > UPDATE foo SET A=B,C=D WHERE pk=123 and xmin=456;
>      >
>      > If we are in read-committed mode, one query sees the result of the 
> other
>     (made to wait if necessary),
>      > and so fails (Cursor.rowcount=0) as xmin doesn't match anymore.
>      > In serialisation mode, they don't see each others results, instead one
>     will fail
>      > with a serialisation error, and forced to try again, whereupon it will 
> fail
>      > (as it has now seen the results of the other)
>      > The docs state that UPDATE and SELECT FOR UPDATE operate in the same 
> way.
> 
>     Thanks.
> 
>     One other thought: is it wise to use xmin as the row "state" identifier?
>     We've been stung by our use of OIDs to identify updated rows - user
>     access to the OID column is now deprecated in PG 8.1 and will disappear
>     entirely in future versions. Maybe a hash on the data read originally
>     from the row might be better, and that would also work where data is
>     read from many different tables to form the patient "row" object by your
>     middleware.
> 
>     Tim C
> 
> 
> 
>     _______________________________________________
>     Gnumed-devel mailing list
>     address@hidden
>     <javascript:top.opencompose('address@hidden','','','')>
>     http://lists.gnu.org/mailman/listinfo/gnumed-devel
>     
> <parse.pl?redirect=http%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fgnumed-devel>
> 
>