[Seaside] Session. Where to put DB connect/disconnect code.

David Shaffer cdshaffer at acm.org
Sun Mar 6 15:25:20 CET 2005

David Shaffer wrote:

> Dmitry,
> You might look through the mailling list archives.  I know that Avi 
> commented on this a couple times.  I put my DB disconnect code in 
> unregistered and it works pretty well.  I haven't noticed Seaside 
> being very aggressive at "unregistering" sessions but it does happen 
> eventually.  I have one app that is hardly every used :-( and it has 
> sessions whose last access time is several days ago but my more 
> heavily used apps never keep expired sessions around for very long.  I 
> don't think Seaside trys to expire sessions during page access 
> handling so an idle server is bound to have sessions hanging around.  
> I believe there is a way to fork a process to check at fixed time 
> intevals, for example, so as to be more aggressive about session 
> reclamation.  Again, Avi's previous postings my shed some light on 
> this topic.

Wow, I should have re-read that.  I meant "I think Seaside trys to 
expire...".  In looking at senders of #unregistered I see that checking 
only happens, on average, once every 10 page accesses (look at 
WARegistry>>shouldCollectHandlers).  It looks like 
WARegistry>>unregisterExpiredHandlers locks the registry so you should 
(Avi?) be able to call it at any interval you like:

[[(Delay forSeconds: 5) wait.
 WAApplication allInstancesDo: [:app | app unregisterExpiredHandlers]] 
repeat] forkAt: Processor userBackgroundPriority.

I have _absolutely_ no idea if this is a safe or wise thing to do.  I 
did test it in my development image and the image is still serving pages 
:-)  Who knows what would happen under heavy load.  I think that Seaside 
could easily be extended to support a "SessionExpirationPolicy" which 
would give you more control over how and when sessions are expired.  
Then you could do things like expire more aggressively under heavy 
memory load etc.  I don't know realistically how many viable policies 
there really are but such a refactoring would at least permit some 
experimentation which could then lead to a list of best practices.  I'd 
be happy to rough it out if anyone is interested.


More information about the Seaside mailing list