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

[Chris McDonough]

On Thu, 2004-09-09 at 16:05, Tim Peters wrote:
> > Let's cast it into a slightly different picture:
> >
> >     try:
> >       try:
> >         # perform modifications on persistent state
> >       except ...
> >         # do something that does not abort the transaction
> >         # and does not raise an exception
> >       ...
> >       commit()
> >     except:
> >       abort()
> >       ...
> >
> > Should the "perform modifications" result in any exception, then the
> > exception is likely to leave the state inconsitent. Catching the
> > exception causes "commit" to be called which makes the inconsistent state
> > persistent.
> 
> OK, that's clear enough.  I suggest not writing code that way <wink>.

I don't think there's anything ZODB can do about the above case, is
there?  I'm so confused my head is spinning, to be honest. ;-)

But I *think* that it's only in the case that the exception which is
raised is a ConflictError or a commit failure does ZODB have any
responsibility whatsoever, and that's only because both are very fatal
and there's no way to prevent either from being caught inappropriately
by overeager exception handlers.  The machinery to make sure that
nothing "bad" happens to persistent state at commit time due to
inappropriately catching a ZODB-related exception is basically a hack,
isn't it?

If Python had a separate exception hierarchy for errors that a bare
except: (or C equivalent, if it exists, and hasattr too!) couldn't
catch, I think ZODB could even relinquish responsibility for doing
anything special when ReadConflictError happens.  By that time we'll all
have MVCC anyway, I guess. ;-)  But it would seem to also prevent ZODB
from needing to do anything special when a commit fails in the way we're
jawing on about in the other thread too.  It would also probably be more
efficient, because the transaction wouldn't need to hopelessly go on
doing work that is preordained to fail at commit time.

- C