[Seaside] Multiple Browser Tabs on Same Application

Ken Treis ken at miriamtech.com
Thu Dec 3 19:32:03 UTC 2009


We've had some users complain of "session timeouts" on our GLASS application. After looking into it, I see that their sessions aren't timing out, but they are being pushed to the root component due to (what looks like) continuation cache expiration.

The users who complained all had the same mode of operation. At some point, they opened a new browser tab within the same session, navigated around in the new tab for a while, and then returned to the old tab. They click a link on the old tab, and instead of seeing what they expected -- they get kicked out to the root. Apparently the continuation for the old page has been removed from the cache.

What's the best solution for this? I confess that my knowledge of the continuation internals is sketchy, but some ideas are:

1. Use the Ramon/Lukas Ajax "ping" [1] to keep the page alive. We're already doing this to keep sessions alive, but we could ramp up its frequency. Downside is a lot of extra chatter between the browser and the server over the life of the session.

2. Simply don't expire things from the cache (we're on Seaside 2.8, but I could replace the WALRUCache with a custom, Dictionary-like object that doesn't do expiry). We're on GemStone, so we could store continuations forever and use long session timeouts. Downside is the extra repository space required, since we're still on the 4GB free version of GemStone. And the engineer in me is turned off by the idea of storing all of that when it's mostly garbage.

3. Use bookmarkable URLs everywhere, so a request that's handled via unknownRequest: still gets the job done. The downside here is the extra work for that (updateUrl: in components, extraPath: in all links, etc). Maybe I've been spoiled by using Seaside too long -- I don't want to name my URLs if I don't have to!

I might be able to blend these approaches; maybe ramp up the frequency of the Ajax ping slightly, increase the size of the cache, and use bookmarkable URLs for a few of the higher-level components so at least if you get "kicked out" you're somewhere close to where you wanted to be.

* Any other/better options?
* Is the situation similar/better in Seaside 3.0?

Thanks,

--
Ken Treis
Miriam Technologies, Inc.

[1] html script: (html request every: (self preferenceAt: #sessionExpirySeconds) - 60)


More information about the seaside mailing list