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

[Tim Peters]

[Chris McDonough]
> ...
> I think it would be better to do away with the implicit abort and resync
> on commit fail due to conflict error and instead just left the existing
> transaction in an uncomittable state.  Doing an implicit abort and resync
> just seems kinda silly, doesn't it?

No, because there's no choice about that, although it's hard to keep words
precise here (the closer you look, the more complicated a commit gets):
when a conflict error occurs during the two-phase commit protocol, all jars
involved in the transaction must get their tpc_abort() called.  Otherwise
jars' changes aren't aborted.  The resync-like behavior is then just a
consequence of aborting pending changes.

The part of the design I would not have dreamed of doing this way (== the
part that resonates with "kinda silly" to me) is the business wherein the
Transaction object retains no memory of the commit failure, effectively
starting a new transaction with a clean slate.  When I said in 3.2.4c1 NEWS
that you must "commit() or abort()", that was literally true:  it doesn't
make a lick of difference whether the commit() succeeds or fails now.  Try a
commit(), and, win or lose, you effectively get a new transaction as a
result.  I would have been happier writing "you must do a successful
commit(), or an abort() [before closing a connection]".

But that's not how it works, and God only knows what would break if it got
changed.  It works that way in 3.3 too, although there you truly (not just
"effectively") get a new transaction after a commit() attempt.

>>  -- current ZODB intends never to let a
>> transaction commit if it experienced a ReadConflictError in its
>> lifetime.

> Or at least it never lets a transaction commit if that ReadConflictError
> was raised by the Connection itself.  You can raise it from app code all
> you like and it won't prevent the transaction from committing.

Sure.  Since ReadConflictError wasn't intended to be raised by app code, app
code raising it anyway can't rely on anything ZODB proper tries to guarantee
about it.  You can raise ZeroDivisionError too even if there's no division
by 0 in sight, etc.