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

[Dieter Maurer]

Steve Alexander wrote at 2003-3-21 11:15 +0200:
 > ....
 > Here's my understanding of the situation:
 > 
 > In the current ZODB, a Dirty Read is not possible because when a 
 > transaction attempts to read data that has been modified in another 
 > concurrent uncommitted transaction, the transaction will get a 
 > ReadConflictError.
 > 
 > A Non-Repeatableable Read is not possible because (working from the 
 > description referenced above), when the first transaction first reads 
 > the data, that data is marked as having been read in a transaction. If 
 > the second transaction tries to modify that data, it will get a 
 > ConflictError.

That's not how the ZODB works.

When the data is read, no other transaction is ever informed about this.

However, the aim of my patch is to prevent "ReadConflictError",
if possible.

 > A Phantom Read is defined in terms of "search condition" and "query" and 
 > "rows". I'm not sure how this applies to the ZODB because "search 
 > condition" and "query" don't have an obvious equivalent.

Why do you think so?

You do not have SQL queries but you can query ("objectValues",
"searchResults") and (in principle) the result set might
change after your query.

In the ZODB, you will normally see the old state (without the phantoms)
unless the object is deactivated. When the object is reloaded
in such a case, you may see a ReadConflictError.

 > So, if I understand its intent correctly, Dieter's patch is for graceful 
 > avoidance of a Dirty Read. This issue is orthogonal to what isolation 
 > level the ZODB achieves.

Its intent is to avoid "ReadConflictError"s.

 > 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).

 > ....
 > So, if I were Dieter, I'd rename the patch from "ReadCommitted" to 
 > "GracefulDirtyRead", or even "NoMoreReadConflicts" :-)

I favour Jeremy's suggestion: call it "Repeatable Read".


Dieter