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. - C