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

[Steve Alexander]

Jeremy Hylton wrote:
> Dieter,
> 
> I haven't had a chance to look at your patch, but I wanted to note
> that it would be clearer if you named it something other than "read
> committed."  As I mentioned in the earlier mail, this feature is
> really closer to repeatable read than read committed.  If we're going
> to use the standard ANSI names, we should try to match the intended
> semantics as best we can.

I just refreshed my memory:

http://www.redhat.com/docs/manuals/database/RHDB-7.1-Manual/admin_user/transaction-iso.html

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.

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.


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.

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.

(I don't mention the "Serializable" isolation level because of the 
problems I have mapping RDB concepts onto the ZODB.)


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

--
Steve Alexander