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