[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
best
sebastian
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