8 messages in org.apache.myfaces.devRe: [core] Enhancements to State Savi...| From | Sent On | Attachments |
|---|---|---|
| Leonardo Uribe | May 10, 2011 7:48 pm | |
| Gerhard Petracek | May 10, 2011 11:10 pm | |
| Werner Punz | May 11, 2011 9:05 am | |
| Gerhard Petracek | May 11, 2011 9:23 am | |
| Leonardo Uribe | May 11, 2011 12:41 pm | |
| Gerhard Petracek | May 11, 2011 4:56 pm | |
| Leonardo Uribe | May 13, 2011 6:26 pm | |
| Jakob Korherr | May 14, 2011 3:20 am |
| Subject: | Re: [core] Enhancements to State Saving Caching Algorithm | |
|---|---|---|
| From: | Gerhard Petracek (gerh...@gmail.com) | |
| Date: | May 11, 2011 9:23:31 am | |
| List: | org.apache.myfaces.dev | |
hi werner,
it's the other way round - a jsf impl is able to do way more in a portable way (as soon as it is in the spec) than codi. what we should prototype (imo): - window-id - request token
regards, gerhard
Your JSF powerhouse - JSF Consulting, Development and Courses in English and German
Professional Support for Apache MyFaces
2011/5/11 Werner Punz <wern...@gmail.com>
Hi why not introduce a url param as view window/tag token and then basically hook the map history in the session onto this token if given. We could use codi window id for that token. If present we can handle multiple maps per session if not then we run within the old scheme. Outside of codi you simply have to duplicate the window param id one way or the other.
Unless we have a different way to identify different maps depending on their window. The viewstate history param then would map to number of views per window and if no window id is given we basically run in the old scheme just with one indirection more in accessing the viewroot from the session point of view. I dont think any of those changes would break the spec.
Werner
Am 11.05.11 04:49, schrieb Leonardo Uribe:
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