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

[Dieter Maurer]

Dennis Allison wrote at 2005-12-14 12:58 -0800:
> ...
>_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)
> ...
>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).   

        "newState" is always after "savedState" ("saveState" represents
	a formerly committed state, "newState" the current state the
	commit of which failed).

>   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.

That looks doubtful: It means, if any of the transactions deletes
the key, then it should be removed. You favour deletion a bit.

>   5.  beginning with the oldest, update oldState dictionary of key-value 
>       pairs using the dictionary part of newState and savedState.  Return 
>       oldState.
> ...

-- 
Dieter