[Seaside] Multiple Browser Tabs on Same Application

[Philippe Marschall]

2009/12/3 Ken Treis <ken at miriamtech.com>:
> 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.

The basic problem is this:
Seaside only keeps a fixed amount of continuations for each session.
The amount of continuations determines the number of steps you can go
back into the browser. Clicking a link in the old tab is basically the
same has hitting the back button until your in that state and then
clicking the link.

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

I don't think this solves your problem. Keep in mind that the ping
works together with the session timeout. If you session timeout is 30
min you should ping about every 25min or so. More frequently doesn't
change anything.

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

I would rather increase the session timeout and the cache size so that
it matches the behavior of your users. On the other hand Dale might be
looking for testers for his one-gem-per-session pony ;-)

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

IMHO this gives away one of the biggest advantages of Seaside, not
having to care about the URL.

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

Seaside 3.0 uses fewer continuations so the same cache size should get
out farther.

Cheers
Philippe