[Seaside-dev] Handling of session expiration

[Esteban A. Maringolo]

Hi Dale,

On Nov 7, 2007 2:36 PM, Dale Henrichs <dale.henrichs at gemstone.com> wrote:
> 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.

Let me see if I understand... when you say "persisting session state"
you mean doing it explicitly or just because of the persistent nature
of GemStone?

Do you have any number of the peak usage before running the GC?
I mean... how much garbage does Seaside usage generate? Or how long do
that garbage lives?

> 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.

We're considering that option too, to scale the more linearly as
possible, but we want to be able to handle the most number of
concurrent session per image as possible. Dolphin proved to be very
stable under heavy load, with almost the maximum number of objects it
can handle. I just discovered that it's not equally stable with a huge
number of processes.

> 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.

How is this browser based thread?

> 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.

That's another option. But unless a better approach appears, we'll
have a background process doing the cleanup. Anyway, I'm trying to not
have to do that cleanup et al.

Best regards,

-- 
Esteban A. Maringolo
eMaringolo at gmail.com