[Seaside] Multiple Browser Tabs on Same Application

sebastian sebastian at flowingconcept.com
Thu Dec 3 19:43:37 UTC 2009

I use the ping. Easy to implement and the extra requests aren't an  
interesting issue to dramatize about
A bit of url stuff plus cookies won't hurt

On 03/12/2009, at 17:32, Ken Treis <ken at miriamtech.com> wrote:

> 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) 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the seaside mailing list