Stupid question about session expiration handling..
Locked
Stupid question about session expiration handling..
 
|
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? MTIA! _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Stupid question about session expiration handling..
|
|
> 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? > > MTIA! 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 http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Stupid question about session expiration handling..
|
|
-----Mensaje original----- De: [hidden email] [mailto:[hidden email]] En nombre de Ramon Leon Enviado el: Viernes, 09 de Febrero de 2007 20:13 Para: 'The Squeak Enterprise Aubergines Server - general discussion.' Asunto: RE: [Seaside] Stupid question about session expiration handling.. > 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? > > MTIA! 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 http://onsmalltalk.com Regarding to that background process for production, could you tell more about it? What exactly does and how often? I can imagine something like WARegistry clearAllHandlers followed by some deep garbagecollect, but I like to hear that from someone with production experience, Thanks Sebastian _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Stupid question about session expiration handling..
|
|
In reply to this post by Ramon Leon-5
> 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. Just as a side remark: Even tough this sounds interesting, I don't know of any productive application that does this. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Stupid question about session expiration handling..
|
|
In reply to this post by Rick Flower
Same here, we didn't do anything like this, normal expiry seems to work just fine and our db sessions are pooled so there's little pressure to rid of sessions as soon as they expire. And if there's a lot of activity, the current mechanism will kick in anyway, cleaning up when no one is on will make little difference as I see it at the moment. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Stupid question about session expiration handling..
|
|
In reply to this post by Lukas Renggli
Lukas Renggli wrote:
>> 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. > > Just as a side remark: Even tough this sounds interesting, I don't > know of any productive application that does this. > > Cheers, > Lukas > Nevin _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Stupid question about session expiration handling..
|
|
In reply to this post by Boris Popov, DeepCove Labs (SNN)
> Same here, we didn't do anything like this, normal expiry
> seems to work just fine and our db sessions are pooled so > there's little pressure to rid of sessions as soon as they > expire. And if there's a lot of activity, the current > mechanism will kick in anyway, cleaning up when no one is on > will make little difference as I see it at the moment. > > Cheers! > > -Boris > (Sent from a BlackBerry) > > > Just as a side remark: Even tough this sounds interesting, I > don't know of any productive application that does this. > > Cheers, > Lukas > OK, well maybe others aren't doing it. I know someone is, because running a background reaper wasn't my idea, I took it from someone on this list. What it does do, is avoid stalling that person who happens to be the 10th connection and kicks off a session expiration. If you look back in the history of this list a bit, you'll find a few complaints about that. I run a background service that does this every 30 seconds ... (WADispatcher default entryPoints select: [:app | app respondsTo: #unregisterExpiredHandlers]) do: [:app | app unregisterExpiredHandlers] Sessions can take up a lot of memory, depending on what you do, and when running a public web site, I want to ensure memory is released as soon as possible. Ramon Leon http://onsmalltalk.com _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |