[ZODB-Dev] conflict resolution for PersistentList

[Chris McDonough]

On Mon, 2004-05-24 at 15:41, Diez Roggisch wrote:
> > The fact that the conflict resolution handler is called on the parent
> > object indicates that the conflict is not happening (at least in your
> > example) as a result of concurrent mutation of the PersistentList
> > itself.  Instead it means that the conflict is happening due to two
> > threads concurrently changing/reading the state of the parent of the
> > PersistentList.
> 
> The list is the only state that is changed in my whole app - I create new 
> childs that are appended to the list, which is a member of the parent. 
> Nothing else is changed.

If the PersistentList's *parent's* _p_resolveConflict method is being
called, unless there is some sort of (as-yet-unidentified) bug in
whichever ZODB you're using, your statement about "nothing else has
changed" can't be true.

The only time that _p_resolveConflict is called is when the state of the
object *it's defined on* is changed concurrently by two transactions. 
Changes to persistent subobjects of that object "don't count" (they
wouldn't cause the conflict resolution machinery on the parent to be
invoked), although reassignment on the parent via __setattr__ of *non*
persistent suobjects do (this is a "state change" on the parent).

Maybe we can give a better name to the "parent" than "parent" so
referring to it isn't so awkward.  What kind of object is it?

> > I think this just means that the conflict isn't happening where you
> > believe it's happening.  If the conflict is happening as a result of
> > concurrent access to the parent, you'll need to write a conflict
> > resolution handler on the parent.  If you write a simple
> > _p_resolveConflict method that prints the three states and attach it to
> > the parent class, what gets shown during a conflict?
> 
> I thougt I postet that before, but it might be that I fell into the "reply" 
> instead of "reply-to-list" trap, so this is what gets passed as oldState in 
> parent's _p_resolveConflict:
> 
> >>> print oldState
> {'items': PR(1079757676 ('\x00\x00\x00\x00\x00\x00\x00\x02', <class 
> 'persistent.list.PersistentList'>)), 'name': 'father'}

Can we see the other two states?

> > Have you confirmed that your ZODB version has the "suppressed conflicts
> > prevent commit" bug fix in it as per Tim's suggestion?:
> 
> No, I currently work on the latest rc - however, from what I understood that 
> doesn't change my immediate problem - instead I get  new one at the next 
> read. But I will check that anyhow.

That would be kind, in case we find ourselves trying to fix a bug that's
already potentially been fixed.

- C