[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

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

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to