Re: [Gnumed-devel] Comments on 0.2

[Syan Tan]

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','','','')>
> >     http://lists.gnu.org/mailman/listinfo/gnumed-devel
> >     
> > 
> >