[ZODB-Dev] Re: [Zope-dev] Conflict reduced BTrees for catalogin

[Dieter Maurer]

Hi Jeremy,

Jeremy Hylton wrote at 2003-3-17 12:13 -0500:
 > ...
 > I believe this is just a terminology issue, but I better mention it in
 > case one of us is missing something.  The ANSI isolation levels don't
 > map exactly onto the optimistic scheme ZODB uses.  But I think it's safe
 > to say that ZODB supports read committed now, but does not support
 > repeatable read.  The way ZODB works, it's impossible to read
 > uncommitted data.  But it is possible to read an object by loading it
 > from the cache, and thus get an older committed version of the object
 > than if you had read it by loading it from the database.
 > 
 > The solution is to add a read state to the persistent object state
 > chart.  In the short term, you can raise a ReadConflictError when there
 > is a transition from unmodified to read and the object has been
 > invalidated.  In the long term, the read state could be used to
 > implement a database that supported serializability by storing the read
 > state in the database.

I used "ReadCommitted" in the sense of PostgreSQL (its default
isolation level):

  I read the (consistent) state as it was when the transaction started.

My main purpose is to get rid of "ReadConflictError"s as
we currently do not have a good way to cope with them
(something like the equivalent of conflict resolution).

My approach is to load the latest version with a timestamp
before or at the transaction start time.
This will work only with history enabled storages.

In order to use the existing cache machinery,
I hope, I need to load a special serial only when I would get
a "ReadConflictError" in the current implementation.
For this to be correct, 
a synchronization between transaction start times and
the data structures controlling invalidation is probably
required which may not yet exist.


Dieter