[ZODB-Dev] Re: self.length._p_deactivate() and MVCC

[Casey Duncan]

On Fri, 30 Apr 2004 11:40:11 -0400
Jeremy Hylton <jeremy at alum.mit.edu> wrote:

> On Fri, 2004-04-30 at 09:15, Casey Duncan wrote:
> > > I think the person who wrote the comment believed that the old
> > > value of length would be loaded again if MVCC was enabled.  The
> > > Length object has an _p_independent() method, however.  The return
> > > value of that method tells ZODB whether it is okay to read a
> > > revision of the object that is inconsistent with other objects. 
> > > Length's_p_independent() always returns 1, so ZODB will always
> > > read the most current revision.
> > 
> > I wrote the comment based on speculative semantics for MVCC. It
> > looks like it will still work as intended with MVCC as it is now
> > implemented, so I will remove the comment.
> 
> Fair enough.  I don't think I had any idea how _p_independent() would
> work until I was actually writing the code, so your guess was as good
> as any.  In hindsight, I think the semantics are right, because
> _p_independent() would be basically useless if non-current versions
> took priority; that is, the _p_independent() hook would never actually
> get called.

I agree, it is good to be able to explicitly say that dirty reads are ok
for an object even in the face of MVCC. A possible downside though is
that Length() objects used to cache the length of another object (their
primary usage AFAIK) may return a value inconsistent with the state of
that object. (This has always been the case, however).

I have always wondered about this. _p_independent says that an object's
state does not depend on the state of any other persistent object.
However, Length() objects are primary used as fast length caches, which
by definition rely on the state of the btree they cache the length for.

Granted this may not be a practical problem, but it probably bears some
thought and documentation to make sure people understand the using
Length() caches could cause inconsistencies and that its value may not
always match the actual length at the time of the transaction (instead
it may be the length of the most recent state).

One possible solution to this might be to drop _p_independent for
Length, or create a variant that does not use it. With MVCC, presumably
the only thing you would need to handle is write conflicts, and theses
are already taken care of in Length.

Anyone care to poke holes in that idea?

-Casey