[Zope] sessions in the presence of conflicts

[David H]

Dennis Allison wrote:

>Zope 2.8.4, ZODB 3.4.2
>
>I am still trying to resolve a "session variables in the presence of
>conflicts" problem.  The observed symptom is that suddenly either some
>session variables disappear or all session variables disappear.  In both
>cases, Zope has raised a KeyError exception for the a particular session
>variable because it is not present and an attempt was being made to access
>it from the session.
>
>The cause appears to be related to the presence of a conflict error and a
>botched recovery, but the exact mechanism remains a mystery.
>
>Zope equates a session object with a TransientObject.  For our instance,
>that's fine, since our only TransientObject is a session.  For the general
>case, I would have thought a SessionObject inheriting from TransiendObject
>would have been used so that conflict resolution for sessions could be
>easily specialized.
>
>The conflict resolution for a TransientObject (that is, a Session Object)
>is clearly suboptimal.  In the next paragraphs I'll review what is 
>currently done and then propose a different approach which I am about to 
>implement for our systems.  Comments, corrections,  and suggestions much 
>appreciated.
>
>_p_resolveConflict(self, oldState, savedState, newState) 
>
>returns the state of the object after resolving different changes.  The 
>arguments are:
>
>   oldState   -- state of the object at the beginning of the current 
>	         transaction (mutable)
>   savedState -- state currently stored in the database.  This state 
>                 was written after oldState and reflect changes made
>                 by a transaction that committed before the current
>                 transaction (immutable)
>   newState   -- state after changes made by the current transaction 
>	         (immutable)
>
>The standard conflict resolution for a TransientObject resolves according
>to the following rules:
>
>   1.  if any of the states are invalid (that is, has a key '_invalid')
>       return the invalid state.
>
>   2.  if any any of the attributes ['token','id','_created'] differ then 
>       there is a conflict, raise the conflict exception.
>
>   3.  choose the state most recently modified, if possible.
>
>   4.  otherwise, choose the state most recently accessed.
>
>It seems to me that we can do much better for sessions because we know a
>bit about the semantics of sessions.  A session object is a
>dictionary-like object mapping key-value pairs.  Adding or deleting keys
>or changing the value associated with a key are independent operations and
>do not conflict unless the keys are duplicated in both the transactions.  
>Any conflict resolution mechanism needs to be able to manage multiple keys
>independently since the session object is modified as a unit.   In 
>addition, new keys may be added and old keys deleted; any conflict 
>resolution mechanism at the key level needs to be comprehend those 
>operations.
>
>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.
>
>
>
>
>  
>
Dennis,
Im only curious and this is no recommendation ... and I asked this on 
the list maybe a year ago (and got zero reponses)

Have you given "HappySession" a try?  Has anyone? I've never had a 
problem with it, but then its never been under much load and is no 
longer actively supported (least last time I checked).

I converted back and forth between Zope SESSION and HappySession (for 
reasons of  legacy code).  Their interfaces have just few differences, 
e.g., HappySession['this'] returns None (if 'this' is not a key) and 
SESSION raises an exception.  That type of thing.

HappySession  does not read/write to zodb (if I recall it stores session 
data in RAM (session) cookies).  I just do not know if its otherwise up 
to your requirements.

All best,
David