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

[michael]

On 11/03/2004, at 11:48 AM, Chris McDonough wrote:

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

On closer inspection I have another small detail - I'm only seeing 
these KeyError's for sessions that have had a chance to expire and when 
trying to access the session from standard_error_message.

Also I'm seeing behaviour that suggests my first guess is not right. In 
other words - I'm seeing some healthy behaviour when a conflict error 
is thrown while attempting to render the standard_error_message.

Michael