[Chris Withers] > If I abort a transaction (and bear in mind this might well happen after > a ConflictError has been caught)
Shouldn't matter whether an exception occurred, or, if one did occur, which particular exception it was. > do I need to do a sync() or some such to bring all the objects back > to the state before the transaction began or is the abort() enough > on its own? The latter: abort() is enough on its own ... although it doesn't "bring back" anything itself. It invalidates modified objects in cache, so that their states will get re-fetched the next time (if any) they're referenced. That's not necessarily the state they had before the transaction began! For example, in time order: 1. transaction T1a in process (or thread) A modifies object O 2. transaction T1b in process (or thread) B modifies object O 3. T1b successfully commits 4. T1a aborts 5. new transaction T2a starts in A If T2a then references O, it will see the state committed by T1b in step #3, not the state T1a saw when it first fetched O in step #1. So the answer to your literal question is "no, there's in general nothing you can do to get back the state of the objects before the transaction began", but the answer to the question you intended to ask <wink> is "yes, abort() discards all modifications to persistent objects made by the aborted transaction". > Does this behaviour differ between Zope 2.7 and Zope 2.8? The semantics of abort() should not differ. _______________________________________________ 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
