[Zope-dev] Re: [ZCM] [ZC] 869/ 5 Comment "Broken transaction handling in case of exceptions"

[Dieter Maurer]

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