[ZODB-Dev] conflict resolution for PersistentList
Diez Roggisch
d.roggisch at ehotel.de
Mon May 24 15:41:59 EDT 2004
> 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
More information about the ZODB-Dev
mailing list