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

[Tim Peters]

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