[Chris McDonough]
Note that changing the transientobject conflict resolution algorithm won't get rid of all write conflict errors, because the BTree-based indexes in the transient object container will still conflict during a "bucket split" and other situations that I can't exactly recall (they're documented in the BTrees source code).
A more readable account is here: http://www.zope.org/Wikis/ZODB/BTreeConflictResolution BTrees are mappings too, and looks like Dennis is trying to apply "similar" conflict-resolution rules to session mapping objects.
Conflict resolution algorithms are difficult and any algorithm will have DWIM-y tradeoffs, so it's useful to keep it as simple as possible.
Or no more complex as is actually helpful ;-)
...
[Dennis Allison]
I have yet to figure out how to map a TransientObject "state" back to the object it represents, but it clearly is possible.
I didn't see a response to that bit yet, so: "the state" of an object P is whatever P.__getstate__() returns. Given such a return value `state`, and some object Q of the same type as P, Q.__setstate__(state) gives Q the same state P had. What state "means" is entirely up to the type's __setstate__() and __getstate__() implementations (if any). Objects deriving from Persistent inherit (by default) implementations that retrieve and update an instance's __dict__. BTrees.Length is a good example of a class that overrides these methods, using an integer as "the state".