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!!! -- 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 )
