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

[Tim Peters]

[Tim, on magically getting a new transaction when commit() fails]
> 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.

So what do people think about this for 3.3?  It's still in beta, so it's
still *possible* to change 3.3's default TransactionManager to one that
doesn't magically dump you into a new transaction if the current
transaction's commit() fails.  People who know far more about Zope than I do
(like Chris and Shane) consistently say they want that.  I know a number of
ZODB tests would fail, but I don't care about that -- they're not *relying*
on the current behavior, they're testing to make sure it stays broken
<wink>.

There's no way I can justify such a change in the "maintenance only" 3.2 or
3.1 lines, but if it's what we want, better to bite the incompatibility
bullet ASAP with 3.3 final (Zopes 2.8 and 3).  Of course a
TransactionManager with current behavior could also be supplied, but I
personally would like to make the safer manager the default, for the sake of
future generations' sanity.

It would mean that you could no longer do:

    try:
        transaction.commit()
    except:
        suppress the exception

    transaction.commit()

and see the second commit succeed if the first commit in fact had an
exception suppressed.  The second (and subsequent) commit would also raise
an exception, until an abort() or begin() were done on the transaction or
transaction manager (respectively).  It's unclear *which* exception the
second (etc) commit would raise; it would probably be helpful if it passed
on some exception information from the failing (first) commit.  If someone
has a strong idea about what they'd like to see there, speak up.