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

[Toby Dickenson]

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.

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.

(All from theory - I ve not tested this)


-- 
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson