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

[Tim Peters]

[Dieter Maurer]
>>> 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).

I should note that *much* the same would apply here:  the current
transaction would be aborted, wrt all changes it made and wrt holding on to
resources, but the current Transaction *object* would be marked in such a
way that you would need to explicitly begin() or abort() before you could
successfully commit() again.

Maybe the key difference is that we *expect* ZODB transaction commit() to
fail at times, regardless of what the user does, at least because of write
conflicts.  Code that does, e.g.,

    ...
    commit(True)
    ...
    commit(True)
    ...
    commit(True)  # in a routine that suppresses an exception
    ...
    commit(True)
    ...
    commit()

is hosed now, and part of the reason is that the failing subtransaction
commit implicitly starts a new transaction.

OK, staring at the code, a failing subtransaction commit is so complicated
now I'm not sure what it actually does in all respects, or what it intends
to do.  It does at least run around calling abort() and abort_sub() and
tpc_abort() on all participants.  In 3.3 it doesn't cause a new Transaction
to be created (but a top-level failing commit() does), but leaves the
current Transaction object intact and still current; enough so that, in the
scenario above, it acts "as if" a new transaction had begun (i.e., the
changes at and before the failing commit(True) are lost, and the changes
after are retained).

[Shane Hathaway]
> Not quite: In PostgreSQL, some (maybe most?) errors force you to
> explicitly roll back before you can do much of anything again.  The one
> case I know of is that if you try to access a nonexistent table,
> PostgreSQL refuses queries until you roll back.  It apparently assumes
> that the program is broken and deserves to lose, which I find reasonable.
> I don't know any more details since I happily complied right away. :-)

I couldn't find any details from staring at PostgreSQL docs either.  From
what I did stare at, there and elsewhere, I doubt there's any real
consistency across RDB systems.  Most docs I saw didn't even admit the
possibility that a COMMIT *could* fail, let alone say what happens then.

...

> What I want is for transactions to be completely explicit.  I want one
> piece of code to govern transactions while the rest of the program is
> subject to the code that controls transactions.  If transactions begin
> implicitly, the transaction control code doesn't have the power it should
> have and knowledge of transactions spreads all over the place.  "except
> ConflictError:" clauses are the most visible manifestation of this fault.

Then we need to define "completely explicit" <wink>.  Is it, e.g., CE if a
successful commit() starts a new transaction as a consequence?  I believe
you'd say "no", but I want to be sure.  Certainly if commit()fails,
implicitly starting a new transaction isn't CE.

Maybe what you want is as easily defined as saying a transaction starts with
begin(), and doesn't end until:

A) An abort().
B) Another begin() (which implies an abort() of the current transaction).
C) A successful commit() (successful == doesn't raise an exception).
or
D) Death (system, process, whatever; then there's an implied abort()).

No implication that "easily defined" is "easily implemented".