Regards,
StefanSerge Huber wrote:
Yes I agree that this would be much better. Actually Pluto already has a servlet that it adds to each webapp, so it could just be added to this one in order to update the session timers.
Regards, Serge Huber.
At 08:42 AM 10/7/2003 -0500, you wrote:
> > Well one way to do it is for the portlet container to > regularly call the > doView() method of all the portlets, which will renew the > session counters. > It might be a bit tricky but it could just do the trick.
This could easily lead to some unexpected behavior; for example, we keep a list of recently viewed items.
It may be more natural to have a Pluto heartbeat servlet in each portal app, that would be a no-op servlet whose sole purpose would be to keep the session alive. One request per portal app would also be more efficient than 1 per portlet.
> > Regards, > Serge Huber. > > At 12:26 PM 10/7/2003 +0200, you wrote: > >Hi Glenn, > >this is not pluto specific, but results from the portlet > specification > >that requires that each portlet application is a seperate > web application. > >You're right that this will cause some user experience > problems with the > >session timeouts. This is something that needs to be > addressed on the > >servlet level to allow some kind of parent relationship > between sessions. > > > >Regards, > > Stefan > > > >Glenn R. Golden wrote: > >>I have a concern about how Pluto is designed to use > separate webapps > >>for > >>the portal + Pluto, and for sets of portlets. The http > session is scoped > >>at the webapp (servlet context) level; if a user is > interacting with many > >>different webapps, the user has many different session objects. > >>This has many advantages; the larger scoping of portlet > session objects > >>is by webapp (not portal), separate webapps are protected > from each other, etc. > >>But, here's the problem. If a user logs into a portal, and > does some > >>things here and there, establishing many sessions as the user moves > >>around; and if the portlets the user is interacting with > are keeping > >>state in the session, which is the proper place for this, > and the user > >>stays on for a while, it's likely that some of the http > sessions that > >>represent this single portal session with this user will time out. > >>The session the user appears to have is with the portal, > and that will > >>stay fresh, but if the user doesn't come back to a > particular portlet for > >>a while, but does come back later, while in the same portal > session, that > >>portlet's webapp's session which has not seen any activity > from this user > >>for a while could time out and the user could be back at > the starting > >>state in that portlet. > >>I consider this a problem, since from the user's > perspective that user > >>has remained active, and then discovers that she has "lost > work" since > >>the state in a portlet has been cleared by the timeout. > >>I expect that this issue came up to the Pluto designers; I > wonder what > >>the thinking on this was, and if there's anything special > in Pluto to > >>avoid this problem, or if this was in fact considered a > problem and not a > >>further "feature". > >>Thanks. > >>- Glenn > >> > >>------------------------------------------------------------ > --------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > - -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- - www.jahia.org : A collaborative source CMS and Portal Server
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- - www.jahia.org : A collaborative source CMS and Portal Server
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
