[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Tim Peters]

[Dieter Maurer]
> I do not understand why you want to keep the transaction the commit of
> which has failed. The only thing, you can do with it is to abort it.

It not that it's the only thing you can do with it, it's that you *must*
explicitly abort() or begin() before another commit() will succeed.  If some
code swallows an exception from commit() now, and you don't know about that,
you have no way to ever know it.  The changes you thought you made (before
the hypothetical code that swallowed an exception from commit()) vanished,
and if you do a commit() again you have no clue that anything went wrong.

> Relational databases behave in the same way: when the commit fails
> (usually due to lock contention/dealock avoidance), the transaction is
> implicitly aborted (to get the blocked resources freed).

Good for them <wink>.

> I can see only one reason why to keep the failed transaction in tact: in
> order to analyse it (which objects have been registered). But, up to now,
> I did not yet meet any occasion where I really had wanted that.

It's not trying to keep the transaction intact, it's trying to prevent
another commit() from succeeding, until the code trying to do that next
commit() explicitly acknowledges that a prior commit() failed (via invoking
abort() or begin(), which unambiguously ask for a new transaction).

Maybe nobody *really* wants that.  Three people +1'ed the idea before your
response, so my best guess is that they do want that.  I don't know what
Shane wants (AFAICT, he kept asking for behavior that ZODB already
implements -- it's already the case that ZODB will not allow a transaction
to commit if that transaction suffered a ReadConflictError).