[ZODB-Dev] [Ann] "ReadCommitted" transaction isolation level

[Shane Hathaway]

On 03/21/2003 03:00 PM, Dieter Maurer wrote:
> Steve Alexander wrote at 2003-3-21 11:15 +0200:
>  > So, this does not change where the ZODB fits into the ANSI Isolation 
>  > Levels. Rather, it provides a better implementation of "Not Possible" 
>  > for Dirty Reads at the "Read Committed" and "Repeatable Read" isolation 
>  > levels.
> 
> As objects may be deactivated after they have been read,
> the ZODB does not support "Repeatable Read" without the patch
> (as the subsequent read may result in a ReadConflictError)
> while it does with the patch (provided the affected storages support
> history).

Translation for the Rest Of Us: Dieter is working to move ZODB from the 
"read committed" isolation level, where ZODB currently is, to the 
"repeatable read" isolation level, and he just might succeed.

But now I'm looking at a paper by Hal Berenson that critiques the ANSI 
isolation levels.  ZODB is actually at the slightly higher "Cursor 
Stability" isolation level and satisfies some of the requirements for 
higher levels (the paper defines 6 levels).  I believe when Jeremy and 
the gang complete the MVCC work, ZODB will solidly hold the "Snapshot" 
isolation level with a slight advantage since it does not exhibit any 
form of the "phantom" anomaly (unless you consider packing bugs to be a 
violation).

But the final isolation level, "serializable", is harder than the ANSI 
table makes it appear.  Even with MVCC, ZODB can still fall into the 
"write skew" anomaly described by Berenson.  The absence of write skew 
is a requirement for strict serializability that the ANSI tables fails 
to mention (as Berenson says at the end of section 2.2).

Write skew happens when a transaction reads some state from the 
database, another transaction changes that state, then the first 
transaction writes data that does not conflict with the second 
transaction's changes.  This may lead to inconsistency in the database, 
since the first transaction wrote changes based purely on the old state.

There are ways to prevent write skew in ZODB without major changes to 
ZODB.  Although they may come at a performance cost, I'd like to know 
how much interest there is in such a thing.  From a technical 
perspective, it's likely to be a loss for most people, so it must be 
possible to switch it off, but from a marketing perspective, being able 
to say that strictly serializable isolation is available could be a benefit.

Another option is to somehow introduce inter-record consistency checking 
in ZODB.  I wonder how that would work.  Note that consistency within an 
object is already guaranteed, since ZODB uses opaque pickles.

Enough rambling. ;-)  The paper is here:

http://citeseer.nj.nec.com/berenson95critique.html

Shane