[Zope-dev] Re: sessions in the presence of conflicts

Chris McDonough chrism at plope.com
Thu Dec 15 13:10:57 EST 2005


Code would be good.

Note that changing the transientobject conflict resolution algorithm  
won't get rid of all write conflict errors, because the BTree-based  
indexes in the transient object container will still conflict during  
a "bucket split" and other situations that I can't exactly recall  
(they're documented in the BTrees source code).  In fact, before you  
spend a lot of time tuning the TO conflict resolution algorithm, you  
should make sure that the majority of conflicts you're seeing do  
indeed come out of attempting to resolve conflicting transientobject  
states (as per the conflict error traceback).  Conflict resolution  
algorithms are difficult and any algorithm will have DWIM-y  
tradeoffs, so it's useful to keep it as simple as possible.

Note also that if you store your session data in a ZEO server in  
order to do *any* transience write conflict resolution, the ZEO  
server process needs to have Products.Transience on its PYTHONPATH  
(as it needs access to the resolution code).

You also still haven't told us if you've tuned any of the knobs that  
I recommended you tune, so if you haven't, do that first. ;-)

- C

On Dec 15, 2005, at 5:35 AM, Florent Guillaume wrote:

> [Using zope-dev@ instead of zope@]
>
> Dennis Allison wrote:
>> A more session-friendly conflict resolution might use:
>>    1.  if any of the states are invalid (that is, has a key  
>> '_invalid')
>>        return the invalid state.
>>    2.  if any any of the states attributes ['token','id','_created']
>>        differ then there is a conflict, raise the conflict  
>> exception.    3.  order the newState and savedState by  
>> modification time (or if that
>>        cannot be computed, by access time).      4.  any key  
>> appearing in oldState's dictionary but not appearing in         
>> both savedState and newState should be removed from all.   
>> This        corresponds to a key-value pair being deleted in one  
>> of the        transactions.  Insertions will be managed  
>> automatically by        the updates.
>>    5.  beginning with the oldest, update oldState dictionary of  
>> key-value        pairs using the dictionary part of newState and  
>> savedState.  Return        oldState.
>> This does several things.  First, it captures independent key-value
>> changes made in both potentially conflicting transactions.   
>> Second, it
>> provides a reasonable ordering for multiple (potentially conflicting)
>> key-value pair updates.  Third, it manages insertions and  
>> deletions to the
>> session variable set in the presence of conflicts.
>> Does this make sense?  I have yet to figure out how to map a
>> TransientObject "state" back to the object it represents, but it  
>> clearly
>> is possible.
>
> I certainly makes sense from a high level description, but the  
> devil is in the details. I'd be interested in looking at it if you  
> code something.
>
> Florent
>
> -- 
> Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
> +33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )
>



More information about the Zope-Dev mailing list