Re: [Gnumed-devel] Comments on 0.2

[Syan Tan]

maybe a redundant application layer consistency mechanism like middleware vector timestamps is

needed to avoid playing catchup all the time  ;)


On Thu Jun 22 4:23 , 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
> http://lists.gnu.org/mailman/listinfo/gnumed-devel