[ZODB-Dev] [Ann] "ReadCommitted" transaction isolation level
Steve Alexander
steve@cat-box.net
Sat, 22 Mar 2003 15:25:16 +0200
> That's not how the ZODB works.
Darn... time for me to study the ZODB more closely :-)
> However, the aim of my patch is to prevent "ReadConflictError",
> if possible.
I think that was my point: If all your patch does is to make a situation
that currently raises a ReadConflictError instead carry on successfully,
then there has been no change in ANSI isolation level.
The ANSI isolation levels are described (in the document I referenced)
in terms of constraints: "A database management system will not allow
such-and-such under the following conditions".
To stop something bad happening, you can raise an exception or you can
work around it. Both are ways of not violating the constraint. A
graceful work-around is better for the functioning of the application
than an exception.
I don't see that your patch enforces any additional constraints, so I
don't see that it leads to a change in ANSI isolation level.
> > 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.
Objects are related to other objects in arbitrary ways as determined by
the application. For example, I might have a catalog that returns paths
as the results of a query. The application traverses these paths to
return objects. I don't see how the ZODB can know how paths relate to
objects.
If I had to define "query" for the ZODB, I would do so in terms of
loading objects keyed on oid, and loading other objects that the first
object holds a reference to. I understand "objectValues" and
"searchResults" as application-level queries, so I don't see how they
are pertinent to the ZODB.
> 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.
Thanks for the explanation.
> 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).
Aha... I think I was understanding the isolation levels in a very narrow
kind of way.
--
Steve Alexander