You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Hawk Newton <hn...@cobaltgroup.com> on 2009/11/19 23:15:01 UTC
Session Invalidation Options
Hello Wicket folx.
First and foremost I want to commend you on an excellent job putting together a truly impressive best-in-class framework.
I'm in the process of evaluating Wicket for a large-scale ajax-heavy enterprise application.
I've got a business requirement that session invalidation must not be a disruptive event (no "expired session" warning or anything similar).
Some of the most obvious options:
1. Get rid of session requirements all together by using client-side models instead of server side models so we don't have the session invalidation issue. This seems to be in line with "The next version of Wicket will support client-side models for zero-state scalability" line item on the features page. After searching the list archives I've not seen much traction on this front. Are there any potential designs being considered or other resources I could use to educate myself?
2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back to the target page instead of the "expired session" error page. This approach has the drawback that the model will be reset which will cause the page to revert to default values. Ultimately, initializing the page using values from a cookie or some other stateful store that is not tied to the user's session would be ideal, if possible.
3. Use an external store instead of the J2EE session (like a RDBMS) with a data-retention policy so high the chance of a ajax request being issued against a page which has expired is practically nil. We'd also probably need to implement our own encoder to ensure the session id is placed on every link to survive J2EE session invalidation.
We are most-interested in contributing any substantial work back to the community so pointers to style guidelines or other contribution-centric resources are greatly appreciated.
Thank you very much.
-- Hawk Newton
Enterprise Architect
Cobalt Group, Inc.
Re: Session Invalidation Options
Posted by Hawk Newton <hn...@cobaltgroup.com>.
On Nov 19, 2009, at 2:24 PM, Igor Vaynberg wrote:
> On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hn...@cobaltgroup.com> wrote:
>> 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back to the target page instead of the "expired session" error page. This approach has the drawback that the model will be reset which will cause the page to revert to default values. Ultimately, initializing the page using values from a cookie or some other stateful store that is not tied to the user's session would be ideal, if possible.
>
> unless you encode the page class into every url there is no way to
> know what page was being accessed once the session is expired.
I got this working today provided each page is mounted as bookmarkable. I might be missing some of the long-reaching implications, but here's the code if anyone is interested in it:
// In my WicketApplication class:
public RequestCycle newRequestCycle(Request request, Response response) {
return new WebRequestCycle(this, (WebRequest)request, (WebResponse)response) {
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
if(e instanceof PageExpiredException) {
IRequestCycleProcessor processor = WicketApplication.this.getRequestCycleProcessor();
RequestParameters params = request.getRequestParameters();
// We're just looking for the original page, not a component on that page.
String interfaceName = params.getInterfaceName();
// Strip the interfaceName from the request so we can get the original target
params.setInterfaceName(null);
IRequestTarget target = processor.resolve(this, params);
params.setInterfaceName(interfaceName);
if(target != null && target instanceof BookmarkablePageRequestTarget) {
Class<? extends Page> pageClass = ((BookmarkablePageRequestTarget)target).getPageClass();
RequestCycle.get(); // I'm not 100% on why I need this.
CharSequence path = processor.getRequestCodingStrategy().pathForTarget(
new BookmarkablePageRequestTarget(pageClass));
if(path != null) {
// This is a bookmarkable page, so lets send the user to the bookmark
RequestCycle.get().setRedirect(true);
throw new RestartResponseException(pageClass);
}
}
}
return null;
}
};
}
>
>> 3. Use an external store instead of the J2EE session (like a RDBMS) with a data-retention policy so high the chance of a ajax request being issued against a page which has expired is practically nil. We'd also probably need to implement our own encoder to ensure the session id is placed on every link to survive J2EE session invalidation.
>
> or simply set the j2ee session timeout to a high value. servlet
> containers these days can swap inactive sessions to disk to keep the
> memory overhead low. same effect and no need to deal with a database.
>
> -igor
Thank you, with a high enough session timeout and a disk-backed session overflow we should be good.
-- Hawk
Re: Session Invalidation Options
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Nov 19, 2009 at 2:15 PM, Hawk Newton <hn...@cobaltgroup.com> wrote:
> Hello Wicket folx.
>
> First and foremost I want to commend you on an excellent job putting together a truly impressive best-in-class framework.
>
> I'm in the process of evaluating Wicket for a large-scale ajax-heavy enterprise application.
>
> I've got a business requirement that session invalidation must not be a disruptive event (no "expired session" warning or anything similar).
if this is a hard requirement you may be best served by a client-side
framework like gwt or extjs.
> Some of the most obvious options:
>
> 1. Get rid of session requirements all together by using client-side models instead of server side models so we don't have the session invalidation issue. This seems to be in line with "The next version of Wicket will support client-side models for zero-state scalability" line item on the features page. After searching the list archives I've not seen much traction on this front. Are there any potential designs being considered or other resources I could use to educate myself?
no, we have evaluated this option and decided not to pursue it
further. the discussions are on the list if you want to search, but
the agreement was that ram is cheap, disks are even cheaper, and the
overhead of pushing all relevant state to the client is too high. we
have built support for stateless pages, but there is no support for
stateless ajax, and in order to keep a stateless page stateless you
are limited to a subset of components offered by wicket which are
themselves stateless.
> 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back to the target page instead of the "expired session" error page. This approach has the drawback that the model will be reset which will cause the page to revert to default values. Ultimately, initializing the page using values from a cookie or some other stateful store that is not tied to the user's session would be ideal, if possible.
unless you encode the page class into every url there is no way to
know what page was being accessed once the session is expired.
> 3. Use an external store instead of the J2EE session (like a RDBMS) with a data-retention policy so high the chance of a ajax request being issued against a page which has expired is practically nil. We'd also probably need to implement our own encoder to ensure the session id is placed on every link to survive J2EE session invalidation.
or simply set the j2ee session timeout to a high value. servlet
containers these days can swap inactive sessions to disk to keep the
memory overhead low. same effect and no need to deal with a database.
-igor
> We are most-interested in contributing any substantial work back to the community so pointers to style guidelines or other contribution-centric resources are greatly appreciated.
>
> Thank you very much.
>
> -- Hawk Newton
> Enterprise Architect
> Cobalt Group, Inc.
Re: Session Invalidation Options
Posted by Johan Compagner <jc...@gmail.com>.
if you never want sessions to invalidate then just have an ajax timer
that polls the server just before your container time out like 29
minutes if the time out is 30
On 19/11/2009, Hawk Newton <hn...@cobaltgroup.com>i wrote:
> Hello Wicket folx.
>
> First and foremost I want to commend you on an excellent job putting
> together a truly impressive best-in-class framework.
>
> I'm in the process of evaluating Wicket for a large-scale ajax-heavy
> enterprise application.
>
> I've got a business requirement that session invalidation must not be a
> disruptive event (no "expired session" warning or anything similar).
>
> Some of the most obvious options:
>
> 1. Get rid of session requirements all together by using client-side models
> instead of server side models so we don't have the session invalidation
> issue. This seems to be in line with "The next version of Wicket will
> support client-side models for zero-state scalability" line item on the
> features page. After searching the list archives I've not seen much
> traction on this front. Are there any potential designs being considered or
> other resources I could use to educate myself?
>
> 2. Extend WebRequestCycle.onRuntimeException() to redirect the browser back
> to the target page instead of the "expired session" error page. This
> approach has the drawback that the model will be reset which will cause the
> page to revert to default values. Ultimately, initializing the page using
> values from a cookie or some other stateful store that is not tied to the
> user's session would be ideal, if possible.
>
> 3. Use an external store instead of the J2EE session (like a RDBMS) with a
> data-retention policy so high the chance of a ajax request being issued
> against a page which has expired is practically nil. We'd also probably
> need to implement our own encoder to ensure the session id is placed on
> every link to survive J2EE session invalidation.
>
> We are most-interested in contributing any substantial work back to the
> community so pointers to style guidelines or other contribution-centric
> resources are greatly appreciated.
>
> Thank you very much.
>
> -- Hawk Newton
> Enterprise Architect
> Cobalt Group, Inc.
Re: Session Invalidation Options
Posted by nino martinez wael <ni...@gmail.com>.
Hehe, nice one. Never thought of that.
regards Nino
2009/11/20 Michael Mosmann <mi...@mosmann.de>
> Hi,
>
> > I've got a business requirement that session invalidation must not be a
> disruptive event (no "expired session" warning or anything similar).
>
> Is session invalidation an requirement? Put a container into your
> session and throw it away if you want to invalidate the "user session".
>
> mm:)
>
>
Re: Session Invalidation Options
Posted by Erik van Oosten <e....@grons.nl>.
Thanks Michael.
Erik.
Michael Mosmann wrote:
> Hope this code will make something clear.
>
> mm:)
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com/
Re: Session Invalidation Options
Posted by Michael Mosmann <mi...@mosmann.de>.
Am Sonntag, den 29.11.2009, 20:15 +0100 schrieb Erik van Oosten:
> Michael,
>
> What kind of container are you referring to?
public class MyUserSession implements Serializable
{
/* hold user relevant stuff */
}
public class MyWicketSession extends WebSession
{
MyUserSession _container=new MyUserSession();
public void invalidateUserSessionAndNotWicketSession()
{
_container=new MyUserSession();
}
}
> And which session, the
> servlet session or the Wicket session?
The Wicket session.
Hope this code will make something clear.
mm:)
Re: Session Invalidation Options
Posted by Erik van Oosten <e....@grons.nl>.
Michael,
What kind of container are you referring to? And which session, the
servlet session or the Wicket session?
Regards,
Erik.
Michael Mosmann wrote:
> Hi,
>
>
>> I've got a business requirement that session invalidation must not be a disruptive event (no "expired session" warning or anything similar).
>>
>
> Is session invalidation an requirement? Put a container into your
> session and throw it away if you want to invalidate the "user session".
>
> mm:)
>
>
--
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/
Re: Session Invalidation Options
Posted by Michael Mosmann <mi...@mosmann.de>.
Hi,
> I've got a business requirement that session invalidation must not be a disruptive event (no "expired session" warning or anything similar).
Is session invalidation an requirement? Put a container into your
session and throw it away if you want to invalidate the "user session".
mm:)