portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Pruitt" <apru...@coghillcapital.com>
Subject RE: Pluto and Webapps and Session
Date Tue, 07 Oct 2003 13:42:43 GMT
> 
> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: 
> jetspeed-dev-help@jakarta.apache.org
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> 
> - -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- - 
www.jahia.org : A collaborative source CMS and Portal Server



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message