Re: [ZODB-Dev] What's the deal with _p_independent?
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: 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
Re: [ZODB-Dev] What's the deal with _p_independent?
https://bugs.launchpad.net/zodb/+bug/124613 Stefan On 7. Jul 2007, at 19:18, Jim Fulton wrote: Would you mind creating a launchpad issue to that effect? -- Anything that, in happening, causes itself to happen again, happens again. --Douglas Adams ___ 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
Re: [ZODB-Dev] What's the deal with _p_independent?
On Jul 7, 2007, at 6:42 AM, Stefan H. Holek wrote: 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. I'd like some clarification about what happens in a conflict resolution situation, when the Length is _p_independent but the BTree itself is not. I *think* that with MVCC this means a read-conflict will reset the BTree, but not it's Length. All I could google up is this from 2004: http://mail.zope.org/ pipermail/zodb-dev/2004-April/007269.html Now, do we need another Length class or is BTrees.Length just fine and dandy? Thanks for bringing this up. Looking at this again, I fail to see the point of _p_independent in the presence of MVCC. The API was originally added to avoid read conflicts when we read dirty data. With MVCC we no-longer read dirty data. Unless I'm missing something, I'd like to just drop the concept altogether. Would you mind creating a launchpad issue to that effect? Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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
