[Seaside] Stupid question about session expiration handling..

Ramon Leon ramon.leon at allresnet.com
Fri Feb 9 22:13:12 UTC 2007

> I think I may have some poor preconceived notions of what 
> Seaside is doing behind my back with expired sessions and am 
> hoping someone can shed some light on what I'm wrong about.. 
> I guess I was under the impression that if I set the session 
> timeout in my Seaside app's config page to something like 60 
> seconds (just for fun) and then hit "New Session" a bunch of 
> times to get a bunch of new WASession objects (actually my 
> subclassed object instead) that after 60 seconds, those would 
> get house-cleaned away along with any resources they held on to..
> I've tried this experiment and it doesn't appear to work that 
> way.. It seems more like the case that when I press "New 
> Session" (or any link for that matter) on an expired page, it 
> expires the page and redraws a new page ala the 
> ExpiredSession handler class.. However.. it seems like the 
> session that was expired goes and sits in a cache of some 
> sort that will get purged when I call "WARegistry 
> clearAllHandlers" and then let a garbage collection take place..
> Is this what is more or less going on or am I a bit off-base? 
>  What I want to happen more or less is that when a session 
> expires (however long that takes), that my entire session 
> class (subclass of WASession) is garbage collected along with 
> any database connections that are part of it.
> So.. Is one of these not too far off or is there door #3?

It's like garbage collection, just because a session expires in 60, doesn't
mean it'll be done, it just means it becomes invalid after that.  Sessions
are clean, by incoming requests, every 10th one I think.  Most of us who run
real sites run a background process to continually expire old sessions so
that we don't pause an incoming request to do it.

Ramon Leon

More information about the Seaside mailing list