[Zope-dev] Re: Zope 2.X Session problems

[Kris Erickson]

We're using a shopping cart model; sessions only get created if the user 
'adds' a workshop to their cart.
Unless there's anything I'm missing in Plone... the _ZopeId cookie 
doesn't seem to start up a session (lazy data container?) until a script 
actually creates says session['key'] = value... or am I missing the boat 
here?
There is a bot floating around for the univ. search engine, but i still 
don't think that's it. Again, my guess is the bad looping (i.e. trying 
to set session values from form values ASSUMING that form values exist). 
This seems in line with my case: a rapidly developed admin interface 
with buttons existing for cases that haven't been flushed out yet.

Anyway thanks--it hasn't recurred since I cleaned up those loose ends; 
however, I'm still concerned that the log msg didn't give a clear pic of 
the root of the problem.

cheers,
k


Tres Seaver wrote:
> Michael Dunstan wrote:
> 
>> On 7/05/2004, at 5:15 AM, Kris Erickson wrote:
>>
>>> No, that's not the problem;
>>> in THEORY that's what is happening, but in reality there is no way 
>>> that this is the case;
>>> We just unrolled a registration system with participation rates at or 
>>> around 100 to 200 participants per month;
>>> At any given time, monitoring the session data container, there are 
>>> *at most* 1 or 2 items in the transient object container--EXCEPT when 
>>> it spikes...
>>
>>
>>
>> I have seen such spikes occur (in a corner case) where some breads of 
>> web robots were aggressively hitting a page that used sessions. These 
>> robots did not bother to return the cookie handed out by the server. 
>> Each page hit effectively constructs a new session.
>>
>> Have a look through your access logs to see if can see signs of 
>> something similar happening.
>>
>> Not all web robots are created equal. I ended up sniffing for the user 
>> agent and returning a page that does not use sessions for the 
>> offending robots. (From memory, robots.txt was not useful for this 
>> bread.) Alternatively you can set the 
>> maximum-number-of-session-objects to something a lot higher and see if 
>> you can just live through the bot invasion.
> 
> 
> Even better, avoid writing to the session on each request!  Your 
> application will be *much* happier if you write to the session only when 
> the human makes a gesture;  neither bots nor casually-browsing humans 
> will consume sessions, but only session keys (which are cheap).
> 
> Tres.