Stefan H. Holek wrote at 2007-7-7 12:42 +0200:
>BTrees.Length is used in many places to maintain the length of  
>BTrees. Just the other day it was added to  
>While I am happy about the speed improvements, I am concerned about  
>the fact that BTrees.Length declares itself _p_independent.

Your concern may or may not be justified -- depending on how
you use the "Length" object.

  "_p_independent" allows the object to deviate from snapshop
  isolation and to see changes which happened after the
  transaction has begun.

  *THUS*, the observed value of a "Length" object is *NOT* guaranteed
  to correspond to the length of the tree -- even when
  update the "Length" object whenever you change the length
  of the tree.

  This may or may not be fatal for your application.
  If you use the length only for presentation, it will not matter.

  However, if you base decisions on the value of the "Length"
  object (in the form "if len(obj) == 1: <something> else: <else>"),
  then this may be fatal.

  If you do not do that, then
  "Length"s conflict resolution will ensure that the deviation
  is not permanent -- you will not get long term inconsistencies
  between the "Length" and the number of objects in the tree.

Note however, that such decisions may be fatal even without "_p_independent".

  Zope transaction isolation is "snapshop", not "serialized".

  Transaction conflicts (defined via "serialized" isolation)
  are recognized only when they affect the same object.
  Therefore, it is in general unsafe to base decisions about
  changes to one object on another object not changed
  in the same transaction (or when their changes are resolved
  by conflict resolution).

  Thus, you should never base logic (affecting the
  persistent state of another object) on the value of a "Length" object --
  whether or not it it "_p_indentent".

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to