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

[Steve Alexander]

> 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