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