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

[Chris McDonough]

Nevermind.  http://zope.org/Collectors/Zope/789 and
http://zope.org/Collectors/Zope/786

The bug neglector is really living up to its name lately (not pointing
fingers, mea culpa).

- C



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