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