[Zope-dev] Re: Bare "except" dangerous to ZODB?

[Jeremy Hylton]

On Thu, 2003-02-20 at 13:33, Toby Dickenson wrote:
> On Thursday 20 February 2003 5:17 pm, Jeremy Hylton wrote:
> 
> > > There are application-level reasons to mark a transaction as doomed, and
> > > I would like to keep *that* code looking similar ;-). The transaction
> > > states approach would work in that context too, right?
> >
> > Here's a late answer:
> >
> > If an application needs to mark a transaction as doomed, it is supposed
> > to call get_transaction().abort().  If a transactional resource manager,
> > like a database connection, needs to mark a transaction as doomed, it:
> >
> >   - returns False from prepare() -- the ZODB4 spelling
> >   - raises an exception in tpc_vote() -- the ZODB3 spelling
> 
> Thanks for that idea.
> 
> Normally in the Zope context, transaction and request boundaries are 
> co-aligned. This assumption runs deep in zope. I can see problems because an 
> application calling abort wont stop the publisher calling commit at the end 
> of the request.

Good point.  One possibility is that the publisher should more
explicitly manage the relationship between transaction and request.  It
could call get_transaction() at the start of a request to get a
transaction object.  Store that object explicitly and call its abort()
or commit() method at the end of the request.

> Having application state revert mid-request to the pre-transaction state seems 
> like a bad idea. Commiting application changes made in the second half of the 
> request seems bad too.

That does seem like a bad idea, and explicitly using a single
transaction object would prevent it.

On the other hand, maybe Zope app code that detects an error should not
call abort().  Perhaps the publisher should be responsible for the
transaction and the app code should information the publisher that
something went wrong.

Jeremy