[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.
David
More information about the Seaside
mailing list