On Wed, 2004-03-10 at 15:20, Dieter Maurer wrote:
> michael wrote at 2004-3-10 15:22 +1300:
> > ...
> >I have been trying on and off to recreate this error via brute force
> >loading of the simplest possible site that uses sessions. I failed to
> >see this particular KeyError *until* I tried reading a session variable
> >from standard_error_message. Now I can recreate these quite frequently.
> This is a well known problem in Zope, lengthy discussed
> but apparently still not yet fixed...
> The problem is that error handling starts after the main
> transaction has been aborted. Aborting or committing
> a transaction implicitely starts a new transaction.
> If error handling causes objects to be registered
> in the transaction (because it writes some objects
> and this can happen for session variables even when they
> are only read), this transaction is tainted.
> As the transaction is not aborted after error handling,
> the transaction and the modified cache are spilled
> (independently!) into a later request.
> As the connection/cache may later end up in a different thread,
> objects can be invalidated asynchronously. This is disastrous.
> Zope *MUST* abort (or commit) the transaction after error handling!!!
I think the transaction in which the error code operates in should be
aborted. There is no other sane thing to do. I think this might be as
easy as adding a few strategic get_transaction().abort() calls to
various cases in Zope/App/startup.py's zpublisher_exception_hook. I
don't have the time to untangle that mess at the moment, but I will
enter a collector issue in.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -