[ZODB-Dev] world gone wrong after write conflict

[John Belmonte]

Hello,

I'm attempting to dust off my old high-write ZODB/ZEO app, and am having
a hard time tracking down a problem.  Something goes very wrong in the
case where I catch a write conflict, abort the transaction, and attempt
a retry.  Frequently it appears as if the abort did not restore the
objects to their state before the transaction.  (Specifically, I'm
calling transaction.abort() followed by connection.sync().)  For
example, say that in a transaction I'm deleting an item from an OOBTree
and at commit there is a write conflict.  I abort the transaction, but
then when I attempt to delete the item again, I get a KeyError on the
OOBTree.  (The symptom is not specific to OOBTree's.)

I'm getting the same problem both in ZODB 3.3a1 which I was running
originally, and in ZODB 3.6 (I'm now focusing on 3.6).  This app used to
be fine, but maybe having faster client and server machines has exposed
a bug.

I'm trying to instrument the code using the synchronizer interface, but
that isn't going well either.  As soon as any write conflict happens
(causing the problem or not), it seems like my registered synchronizers
go out of commission.  Is there something that can cause a synchronizer
to be unregistered or a new default transaction manager to be created?

Maybe not related, but with ZODB 3.6 I'm also seeing the "tid is not
None and cur_tid < tid" exception from
<http://www.zope.org/Collectors/Zope3-dev/526>.

--John