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

[Chris McDonough]

On Wed, 2004-09-08 at 22:31, Tim Peters wrote:
> [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?

Obviously +1 from me.

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

+1 on that too.

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

I think the only apps that would routinely break are non-Zope apps that
use ZODB (and particularly, scripts that people write to access Zope
ZODB data).  Zope people are insulated by the publisher, so they don't
care (much).  I don't know who else uses ZODB, so I'm not sure what
impact it will have on them.  I'm sure they're all glued to zodb-dev so
we'll hear from them soon. ;-)

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

something like TransactionStateError that carries around some exception
information from the initial commit.  In particular, it would be nice to
have it contain a bit of traceback stack info from the initial failed
commit so that if an exception handler does prevent the initial commit
error from bubbling up, the user might stand a chance at figuring out
why it didn't bubble up by looking at the eventual transaction state
error.

- C