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

[Steve Alexander]

> Steve Alexander wrote at 2003-3-21 11:15 +0200:
> 
>> 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.

In reply, Dieter Maurer wrote:
 >
> 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.


I've just been reading the paper Shane gave a link to. (Thanks Shane.)

http://mail.zope.org/pipermail/zodb-dev/2003-March/004684.html

The reason that a Phantom Read doesn't really make sense in terms of the 
ZODB is given in section "2.3 Locking" of that paper.

   A Read (respectively Write) Predicate Lock on a set of data items
   determined by a given <search condition> is effectively a lock on
   all data items satisfying the <search condition>. This may be an
   infinite set, as it includes data present in the database and also
   all *phantom data items* not currently in the database but that
   *would* satisfy the predicate if they were inserted or if current
   data items were updated to satisfy the <search condition>.


What I meant by "I'm not sure how this applies to the ZODB" in my 
original email was that, since there's no general way to reason about 
the ZODB equivalent of a "seach condition" and a "query", and there is 
no way of working out whether a changed or added data item *would* 
satisfy a ZODB query, there is no reasonable way for the ZODB to avoid 
Phantom Reads. (Short of entirely serializing access to the database by 
only allowing one transaction at a time.)

I didn't express very well what I meant, though :)

I think what Dieter meant in his reply was "Of course you can have 
Phantom Reads in the ZODB. Here's an example.".


Thinking about this some more, if we carefully define "search condition" 
and "query" to be in the scope of particular classes of object, then it 
should be feasible to prevent phantom reads in just those cases.
For example, a BTree object could be "locked" during a transaction that 
reads it, so that writes by other transactions are *entirely* forbidden. 
It could also be locked in a more selective way, so that if the reading 
transaction is interested in the set of BTree items where the key is 
between 200 and 400, the BTree would be 'guarded' against inserts, 
deletions and modifications of data where the key is between 200 and 400.

--
Steve Alexander