On 11/03/2004, at 11:48 AM, Chris McDonough wrote:

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.

On closer inspection I have another small detail - I'm only seeing these KeyError's for sessions that have had a chance to expire and when trying to access the session from standard_error_message.

Also I'm seeing behaviour that suggests my first guess is not right. In other words - I'm seeing some healthy behaviour when a conflict error is thrown while attempting to render the standard_error_message.


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

Reply via email to