[ZODB-Dev] RelStorage now in Subversion

[Shane Hathaway]

Dieter Maurer wrote:
>   For "read committed" this means: it garantees that I will
>   only see committed transactions but not necessarily that I will see
>   the effect of a transaction as soon as it is committed.
> 
>   Your conflict resolution requires that it sees a transaction as
>   soon as it is commited.

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.

In RelStorage, all conflict detection and resolution already happens 
under the protection of an exclusive lock on the commit_lock table. 
However, the table we're using for conflict detection is current_object, 
not commit_lock, so we are not yet fulfilling the conditions of the 
above-mentioned guarantee.  We could be relying on undocumented 
behavior.  It's quite conceivable that Postgres might aggressively 
release locks at transaction commit, then allow the data updates to flow 
lazily to other sessions until a share lock is acquired.

To correct this, it appears we only need to add "LOCK current_object IN 
SHARE MODE" before the conflict detection and resolution code.  Do you 
agree that will plug the hole?

Your diligence is much appreciated.

Shane

[1] http://www.postgresql.org/docs/8.1/interactive/sql-lock.html