Re: conflict resolution for PersistentList

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

>
> 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'}



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

> If they are simple dictionaries, a conflict error will be raised
> (regardless of the three states).

I wanted to use common dict syntax to describe what I had in mind - of course 
the actual used implementation would be either PersistentMapping or one of 
the *Trees

> Various "BTrees" data structures also provide mapping-like features, and
> they provide a bit of built-in conflict resolution, which is based on a
> hardcoded policy.  But what actually would happen if these items were
> BTree-variant objects depends on the state stored in the database when
> these two transactions commit simultaneously (I couldn't tell you what I
> think the actual effect would be without seeing the original database
> state).  In any case, a set of rules will be consulted.  These are
> documented in the BTrees code, and also outlined by Tim at
> http://mail.zope.org/pipermail/zodb-dev/2004-February/006768.html .  I
> think he also added this to some set of semi-official ZODB docs
> someplace, but I can't find that at the moment.

I'll check these and the CVS-Vorsien in two days, when I'm back at work.

Thanks for your efforts so far,

Dies

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@xxxxxxxx
http://mail.zope.org/mailman/listinfo/zodb-dev