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

[Chris McDonough]

On Thu, 2004-09-09 at 16:01, Tim Peters wrote:
> [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()

Er, why would begin() be allowed?  I think I know why: because in ZODB
3.3, begin() returns a spanking-new transaction object instead of
recycling the old one, and we don't care that the old one wasn't
aborted, because it essentially disappears when the last reference to it
is released?

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

I'm not sure I care how it's implmemented (this way is fine), I really
just want the framework to save me from myself and others. ;-)

Tim has explained that the current behavior when a commit exception is
encountered is to abort all jars in the transaction and raise the
exception.  That's fine, but when the commit exception is suppressed,
the existing transaction remains in a usable state and there's no
indication that a failure ever occurred.  It's then possible for code
that assumes prior changes to persistent state in the same transaction
were performed successfully to do more changes and later commit its work
without incident.   I'd like that this wasn't the case, which is why I
say +1 to making it impossible to commit a transaction that has already
failed a commit once.

Basically, if a commit failure occurs, the transaction needs to be put
into a doomed state.  And if all you can do with a failed transaction is
call abort() or begin() on it, it's doomed, but any other way that this
goal can be reached is fine by me too.

- C