DualCacheConflictResolution

Purpose: To take advantage of the power of Connection Caches of objects to assist in resolving DB Conflicts at commit time.

Assumption: A simple/useful/possible way exists to identify the "containing object" of a Persistent collection. This could be as simple as adding a registerContainer(obj) method to PersistentMapping? to take advantage of this resolution mechanism.

Proposal: Add a "_p_resolveConflict" method that is given an object reference to a new Connection cache object that represents this object in the ZODB that has already been committed.

_p_resolveConflict(self, savedObject)

Modify self, and object navigable from self, to resolve differences with savedObject in DB or throw exception.

Arguments:

savedObject

An object from a new Connection Cache that represents this same object as stored in the database. This object reflects changes made by a transaction that committed before the current transaction.

The method is permitted to modify this value, and any navigable from it - all object from this Cache will be thrown away after this commit activity.

The "_p_resolveConflict" method has the additional ability to modify all objects that are navigable from "self", and to use "savedObject" to navigate to the current object, not just dictionary of state, in the DB.

The "_p_resoveConflict" method will be called for every conflicted version without ordering. It is up to the resolution code to make sure that a conflict is not "corrected" twice by navigating to and manipulating an object in the currently committing transaction cache.