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

[Jim Fulton]

Casey Duncan wrote:
> 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).

But they are intended for situations where a high-fidelity cache of the length
isn't needed.  They were originally added to support UIs that want to show
things like the number of objects in a collection.

This intention should really be documented in the length class.

Perhaps there should be different flavors of Length to support different needs.

> 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.

Yup.

Of course, this will defeat your optimization.

> Anyone care to poke holes in that idea?

Nope. In any case, the sementics and tradeoffs should be more carefully
spelled out.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org