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". -- Dieter _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
