DISCUSSION: Is there a way for a Transaction to indicate success/failure from __exit__

[dhermes]

From #336.

Currently, there is no way to determine if this occurs. It's unclear what a way forward would look like but in ndb transactions have retries and can create Future objects which know about the success or failure.

[tseaver]

The transaction package has a concept of a "doomed" transaction: one which is in a hosed state, from which it can never be committed. Having our code fail inside __exit__ would be something like that with two sharp edges:

• Failing while committing is actually more reasonable: the back-end might actually barf here.
• Failing while aborting is a real problem: which exception should surface?

FWIW, the Zope transaction's "two-phase commit" tries to deal with the problems of the first, by breaking up the "commit" into slices, for distribution across multiple resource managers (e.g., a database and a mail-sender). For each of the following methods, the transaction calls each resource manager in turn):

• tpc_begin (can we commit?)
• commit(do the work, but don't finalize)
• tpc_vote (were there problems? last chance to back out)
• tpc_finish (finalize; this must never fail: if it does, we've lost consistency)
• tpc_abort (called if any RM raises from tpc_vote: must never fail).

[dhermes]

For the most part the backend handles this.

It seems a concept of "doomed" would be nice since it would make it so that.

txn = Transaction()
with txn:
    entity.save()
    ...

# This fails since txn has already been used, hence is doomed.
with txn:
    new_entity.save()

I was thinking something simple along the lines of

>>> txn.in_progress
False
>>> txn.succeeded
True
>>> txn.finished
True

There seem to be less than 8 states (implied by 3 bools) but more than 4, so maybe there is a better way to get the information to answer the questions:

• txn is in progress or not?
• txn has already been "used"?
• txn finished in commit (success) or rollback (failure)

[elibixby]

You also need some way to get auto allocated keys back from the transaction right? Could this be incorporated into the method which indicates failure or success?