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

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to