[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Comments on 0.2

From: Syan Tan
Subject: Re: [Gnumed-devel] Comments on 0.2
Date: Fri, 23 Jun 2006 12:21:49 +0800

hashing also begs the question of what do you hash?  it might be different

for different data types, and different for different versions , etc.. my

client hashed on a ,b  , y and his hashed on a , b, x because it 's a new version

made at a different time, in a different place etc... 

sequence numbers are pretty simple in comparison.

On Thu Jun 22 22:24 , Tim Churches sent:

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
> address@hidden','','','')>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]