Pluto and Webapps and Session

["Glenn R. Golden" <gg...@umich.edu>]

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

Re: Pluto and Webapps and Session

[Serge Huber <sh...@jahia.com>]

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.

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

Re: Pluto and Webapps and Session

[Stefan Hepper <st...@hursley.ibm.com>]

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