[Seaside-dev] Handling of session expiration

[Dale Henrichs]

Esteban,

In GemStone, since we are oriented towards multiple vms sharing session 
state, we've moved the session expiration logic into a separate vm (our 
maintenance vm) that expires sessions about once a minute. By persisting 
session state we also avoid the load on the in-memory vm garbage 
collector, of course we just move the load to the repository garbage 
collector, but that only needs to be run on the order of hours to keep 
garbage manageable.

I understand that folks use Seaside in production have a couple of 
different schemes for managing session state (non-Gemstone instances), 
first of which is to spread the session state load across multiple vms 
(using session affinity) so that no one vm's garbage colector is slammed 
to the wall. Secondly, they leave the session expiry at a low value (say 
ten minutes) and then use a browser-based thread that keeps the session 
alive as long as the page is visible in the browser.

If you do look at WaRegistry>>shouldCollectHandlers you'll notice that 
sessions are expired only when the registry grows .... that logic could 
be adjusted to expire sessions when the vm is under memory pressure as 
well, so that aged sessions can be expired after a period of intense 
activity.

Dale

Lukas Renggli wrote:

>>If I place a background process cleaning all the handlers every 30
>>seconds, the image runs very well, with no unnecesary continuations,
>>nor nothing undesired.
>>
>>[[Processor sleep: 30000. WARegistry clearAllHandlers. true ] repeat]
>>forkAt: Processor userBackgroundPriority .
>>    
>>
>
>You will also loose all your active sessions every 30 seconds. Most
>certainly you don't want this.
>
>  
>
>>How do you handle the "cleaning" of undesired/expired
>>WARequestHandler's? (and all of its subclasses).
>>    
>>
>
>Seaside clears up old sessions every now and then wenn a new session
>is created. Have a look at #shouldCollectHandlers and friends. This is
>also the reason why sessions do not just disappear if not used. You
>will always have a couple of sessions and associated objects lingering
>around, even if none of them are active at the moment.
>
>  
>
>>I've run the same test against Seaside on Squeak, and evaluating
>>"Continuation allSubinstances" answer a very large list of instances
>>too, so I believe this issue is not Dolphin-only.
>>    
>>
>
>Usually this is not a problem.
>
>Lukas
>
>  
>