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. -- Dieter _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
