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 _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
