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 zope.app.container.btree.
>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 - ZODB-Dev@zope.org