Hello Shane,

Shane Hathaway wrote at 2008-2-3 23:57 -0700:
> ...
>Looking into this more, I believe I found the semantic we need in the 
>PostgreSQL reference for the LOCK statement [1].  It says this about 
>obtaining a share lock in read committed mode: "once you obtain the 
>lock, there are no uncommitted writes outstanding".  My understanding of 
>that statement and the rest of the paragraph suggests the following 
>guarantee: in read committed mode, once a reader obtains a share lock on 
>a table, it sees the effect of all previous transactions on that table.

I have been too pessimitic with respect to Postgres.

While Postgres uses the freedom of the ASNI isolation level definitions
(they say that some things must not happen but do not prescribe that
other things must necessarily happen), Postgres has a precise
specification for the "read committed" mode -- it says: in read
committed mode, each query sees the state as it has been when
the query started. This implies that it sees all transactions
that have been committed before the query started. This is sufficient
for your conflict resolution to be correct -- as you hold the commit
lock during conflict resolution such that no new transaction can happen
during the query in question.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to