myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject [core] Enhancements to State Saving Caching Algorithm
Date Wed, 11 May 2011 02:49:13 GMT
Hi

There is an old, known problem related to server side state saving,
that becomes more evident in JSF 2.0 and its ajax support.

For more information about it, you can see:

https://issues.apache.org/jira/browse/MYFACES-3117
Current server state saving implementation prevents multi-window usage
https://issues.apache.org/jira/browse/MYFACES-1791
state management and multiple frames

The objective of this mail is get some information from MyFaces
community, given the difficulty involved in solve this problem.

In few words: "... There is a problem in JSF when more than one window
are opened in an application. There are only a maximum number of
NUMBER_OF_VIEWS_IN_SESSION view states saved at one moment (when
server side state saving is enabled). If 2 windows are opened and you
navigate on one of them for NUMBER_OF_VIEWS_IN_SESSION times, you will
lose the other window's state. ..."

MyFaces algorithm for cache sessions is just a Map with a limited size
that just save every view and remove the least recently used one.

The limit is configured using this web config param:

org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION

That defines the number of views per session allowable by an specific user.

To solve this issue, we must consider two valid use cases:

1. Back Button: The user press browser's back button and then do a
submit. In practice, there are some cases where press browser's back
button is valid, but others where a back button should not be allowed.
2. Double Submit: The user press twice the submit button.

Many efforts has been done in this area, for example see the this post
from Mario Ivankovits:

http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html

and in the latest times, there is some code interesting code in MyFaces Codi.

A real solution for this one should be handled at level spec, but that
does not means we can't do anything from myfaces side.

I'm thinking on make our caching strategy more smarter when it decides
which view should be removed from the map, creating a new param that
limits the number of views that can be stored from sequential POST
requests. This will limit the amount of browser back button clicks
without get an expired exception, but on the other side it will
preserve the views available for other windows doing other POST
requests. Note this will not work on applications that uses
POST-Redirect-GET pattern.

Suggestions are welcome.

Leonardo Uribe

Mime
View raw message