[ZODB-Dev] [Ann] "ReadCommitted" transaction isolation level
Steve Alexander
steve@cat-box.net
Tue, 25 Mar 2003 21:17:57 +0200
> 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