Toby Dickenson wrote at 2003-4-4 15:54 +0100: > .... > Access to the doomed state at the end of the transaction is what zope 2 gives > us today.
This is not the case. Zope 2 as it is now performs error handling in a separate transaction. However, the error handling transaction is not committed/aborted explicitely. It is aborted implicitly later in a different request (as you pointed out correctly: in the "transaction.begin()" that [re]uses the implicitly created transaction.). But this abort may affect connections that are meanwhile used by different requests causing non-deterministic invalidation and aborts. That needs to be fixed, either as your suggest by delaying the abort for the original transaction until error handling finished (making error handling part of the original transaction) or by performing error handling in its own explicit transaction (as I suggest). > ... > It is important that the objects passed from one transaction to the next are > non-persistent, otherwise bad zodb-level things can happen. Does Zope 3 guard > against this? I do not see this. Caches routinely pass persistent objects from one transaction to the next. And think of a non-Zope ZODB application. This application is likely to have references to persistent objects in its variables and on its stack and will probably use it across transactions. At transaction boundaries the state of some of these objects is invalidated and reloaded transparently in the following transaction, if necessary. Sure, when the object was deleted, a POSKeyError will result. This is what should happen. Dieter _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )