[ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)

[Dieter Maurer]

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