You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2011/05/11 04:49:13 UTC
[core] Enhancements to State Saving Caching Algorithm
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
Re: [core] Enhancements to State Saving Caching Algorithm
Posted by Jakob Korherr <ja...@gmail.com>.
Hi Leo,
Great job!
Regards,
Jakob
2011/5/14 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> I finally committed a solution for this issue, and other cool
> optimizations in MYFACES-3117. I'll going to explain below which
> changes were done.
>
> Now there exists a class called
> org.apache.myfaces.application.StateCache<K, V>, to delegate all logic
> related to state storing/retrieving in a cleaner way. Additionally a
> factory class org.apache.myfaces.application.StateCacheFactory is
> available, to provide alternate implementations in the future.
>
> Two new params were added for server side stuff:
>
> /**
> * Only applicable if state saving method is "server" (= default).
> * Indicates the amount of views (default is not active) that
> should be stored in session between sequential
> * POST or POST-REDIRECT-GET if
> org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION is true.
> * <p>For example, if this param has value = 2 and in your custom
> webapp there is a form that is clicked 3 times, only 2 views
> * will be stored and the third one (the one stored the first
> time) will be removed from session, even if the view can
> * store more sessions
> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION. This feature becomes
> useful for multi-window applications.
> * where without this feature a window can swallow all view slots
> so the other ones will throw ViewExpiredException.</p>
> */
> @JSFWebConfigParam(since="2.0.6")
> private static final String
> NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION_PARAM =
> "org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION";
>
> /**
> * Only applicable if state saving method is "server" (= default).
> * Allow use flash scope to keep track of the views used in
> session and the previous ones,
> * so server side state saving can delete old views even if
> POST-REDIRECT-GET pattern is used.
> * The default value is false.
> */
> @JSFWebConfigParam(since="2.0.6", defaultValue="false",
> expectedValues="true, false")
> private static final String USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION
> = "org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION";
>
> Finally I founded a way to support POST-Redirect-GET pattern using flash scope.
>
> By default, these two params are disabled.
>
> Other optimizations that will reduce memory usage were done:
>
> - Don't trigger session creation if state is not written on facelets.
> - Don't use a buffer to write the state token when server side state
> saving is used, because after all it is not necessary.
>
> I think with these changes we can solve MYFACES-3117. With this code,
> we have a solid foundation to continue investigating how to solve the
> window-id problem.
>
> Suggestions are welcome.
>
> Leonardo Uribe
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] Enhancements to State Saving Caching Algorithm
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I finally committed a solution for this issue, and other cool
optimizations in MYFACES-3117. I'll going to explain below which
changes were done.
Now there exists a class called
org.apache.myfaces.application.StateCache<K, V>, to delegate all logic
related to state storing/retrieving in a cleaner way. Additionally a
factory class org.apache.myfaces.application.StateCacheFactory is
available, to provide alternate implementations in the future.
Two new params were added for server side stuff:
/**
* Only applicable if state saving method is "server" (= default).
* Indicates the amount of views (default is not active) that
should be stored in session between sequential
* POST or POST-REDIRECT-GET if
org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION is true.
* <p>For example, if this param has value = 2 and in your custom
webapp there is a form that is clicked 3 times, only 2 views
* will be stored and the third one (the one stored the first
time) will be removed from session, even if the view can
* store more sessions
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION. This feature becomes
useful for multi-window applications.
* where without this feature a window can swallow all view slots
so the other ones will throw ViewExpiredException.</p>
*/
@JSFWebConfigParam(since="2.0.6")
private static final String
NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION_PARAM =
"org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION";
/**
* Only applicable if state saving method is "server" (= default).
* Allow use flash scope to keep track of the views used in
session and the previous ones,
* so server side state saving can delete old views even if
POST-REDIRECT-GET pattern is used.
* The default value is false.
*/
@JSFWebConfigParam(since="2.0.6", defaultValue="false",
expectedValues="true, false")
private static final String USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION
= "org.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION";
Finally I founded a way to support POST-Redirect-GET pattern using flash scope.
By default, these two params are disabled.
Other optimizations that will reduce memory usage were done:
- Don't trigger session creation if state is not written on facelets.
- Don't use a buffer to write the state token when server side state
saving is used, because after all it is not necessary.
I think with these changes we can solve MYFACES-3117. With this code,
we have a solid foundation to continue investigating how to solve the
window-id problem.
Suggestions are welcome.
Leonardo Uribe
Re: [core] Enhancements to State Saving Caching Algorithm
Posted by Gerhard Petracek <ge...@gmail.com>.
hi leo,
@window-id:
we have a window(-id) concept e.g. in trinidad, icefaces, cdi (at least a
conversation-id which should be specific to a window), codi,... . so we
again have incompatibilities (esp. in case of dialogs,...) which can't be
solved by just wrapping something. -> adding the concept to the spec. is a
good idea in any case.
>furthermore, a spi would allow to implement a myfaces-core2 specific add-on
for libs like codi.
-> still +1 for prototyping it + a spi for using it for e.g. a
codi/myfaces-core2 add-on.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/5/11 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> Working on this stuff I have found a problem with our current
> ResponseStateManager implementation. The spec javadoc says this:
>
> "... ResponseStateManager is the helper class to StateManager that
> knows the specific rendering technology being used to generate the
> response. It is a singleton abstract class, vended by the RenderKit.
> This class knows the mechanics of saving state, whether it be in
> hidden fields, session, or some combination of the two. ..."
>
> For this particular problem, that means if we need a windowId using
> url/hidden fields/cookies or whatever, the standard solution could
> include a wrapper or alternative implementation of
> ResponseStateManager, setup using a RenderKitWrapper (since JSF 2.0).
> If that so, there is no need for any SPI interface, because the spec
> has already seen that.
>
> In practice, frameworks like trinidad for example just override
> ViewHandler/StateManager/ResponseStateManager, so we have never seen
> anything wrong per years in our implementation ... until now that we
> want to try a wrapper for this class.
>
> Note on the spec javadoc this subtle phrase: "... This class knows the
> mechanics of saving state ..." What that suppose to mean? It means
> that the responsibilities of ResponseStateManager are:
>
> 1. Deal with RenderKit specific state saving mechanism (use hidden
> fields, javascript, ....). (Ok, that's pretty obvious but the next one
> is not.)
>
> 2. Deal with client/server side state saving details, including
> storing/retrieving/caching operations.
>
> I deducted the second one doing the cleanup of the code. To isolate
> the storing/retrieving/caching code I created a class called
> StateCache, but after a closer examination, I saw that each time
> StateCache is called, ResponseStateManager was called too to consume
> or provide params to this class. So it has more sense to put that code
> where it really belongs, inside our ResponseStateManager
> implementation. Just for curiosity I checked if Mojarra, is doing this
> and it is, so there is no doubt.
>
> So, what does StateManager really do? this class deals with
> save/restore the component tree and delegates the remaining stuff to
> ResponseStateManager. The same is for
> javax.faces.view.StateManagementStrategy, but in this case, this class
> is more coupled with the VDL implementation.
>
> Now, for the case we are discussing, any solution for this one should
> provide its own implementation/wrapper for ResponseStateManager and
> some other classes (maybe override ExternalContext and ViewHandler to
> append windowId query param or anything you can imagine). It is
> obvious that frameworks overriding the default ResponseStateManager
> will require a custom variant, but I think is the way to go.
>
> From the spec point of view, I think we can create additional
> interfaces to deal with operations like caching and state encryption,
> but for now there are implementation details for each
> ResponseStateManager implementation.
>
> So, the plan for now is fix MyFaces ResponseStateManager
> implementation (I'll commit it soon) and add the param to limit the
> views stored with sucessive postbacks as a "partial workaround". To
> solve the window problem it is possible we need a "combined solution".
>
> Comments and suggestions are welcome.
>
> Leonardo
>
> 2011/5/11 Gerhard Petracek <ge...@gmail.com>:
> > 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
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2011/5/11 Werner Punz <we...@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
> >>>
> >>
> >>
> >
> >
>
Re: [core] Enhancements to State Saving Caching Algorithm
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Working on this stuff I have found a problem with our current
ResponseStateManager implementation. The spec javadoc says this:
"... ResponseStateManager is the helper class to StateManager that
knows the specific rendering technology being used to generate the
response. It is a singleton abstract class, vended by the RenderKit.
This class knows the mechanics of saving state, whether it be in
hidden fields, session, or some combination of the two. ..."
For this particular problem, that means if we need a windowId using
url/hidden fields/cookies or whatever, the standard solution could
include a wrapper or alternative implementation of
ResponseStateManager, setup using a RenderKitWrapper (since JSF 2.0).
If that so, there is no need for any SPI interface, because the spec
has already seen that.
In practice, frameworks like trinidad for example just override
ViewHandler/StateManager/ResponseStateManager, so we have never seen
anything wrong per years in our implementation ... until now that we
want to try a wrapper for this class.
Note on the spec javadoc this subtle phrase: "... This class knows the
mechanics of saving state ..." What that suppose to mean? It means
that the responsibilities of ResponseStateManager are:
1. Deal with RenderKit specific state saving mechanism (use hidden
fields, javascript, ....). (Ok, that's pretty obvious but the next one
is not.)
2. Deal with client/server side state saving details, including
storing/retrieving/caching operations.
I deducted the second one doing the cleanup of the code. To isolate
the storing/retrieving/caching code I created a class called
StateCache, but after a closer examination, I saw that each time
StateCache is called, ResponseStateManager was called too to consume
or provide params to this class. So it has more sense to put that code
where it really belongs, inside our ResponseStateManager
implementation. Just for curiosity I checked if Mojarra, is doing this
and it is, so there is no doubt.
So, what does StateManager really do? this class deals with
save/restore the component tree and delegates the remaining stuff to
ResponseStateManager. The same is for
javax.faces.view.StateManagementStrategy, but in this case, this class
is more coupled with the VDL implementation.
Now, for the case we are discussing, any solution for this one should
provide its own implementation/wrapper for ResponseStateManager and
some other classes (maybe override ExternalContext and ViewHandler to
append windowId query param or anything you can imagine). It is
obvious that frameworks overriding the default ResponseStateManager
will require a custom variant, but I think is the way to go.
>From the spec point of view, I think we can create additional
interfaces to deal with operations like caching and state encryption,
but for now there are implementation details for each
ResponseStateManager implementation.
So, the plan for now is fix MyFaces ResponseStateManager
implementation (I'll commit it soon) and add the param to limit the
views stored with sucessive postbacks as a "partial workaround". To
solve the window problem it is possible we need a "combined solution".
Comments and suggestions are welcome.
Leonardo
2011/5/11 Gerhard Petracek <ge...@gmail.com>:
> 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
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2011/5/11 Werner Punz <we...@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
>>>
>>
>>
>
>
Re: [core] Enhancements to State Saving Caching Algorithm
Posted by Gerhard Petracek <ge...@gmail.com>.
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
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/5/11 Werner Punz <we...@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
>>
>>
>
>
Re: [core] Enhancements to State Saving Caching Algorithm
Posted by Werner Punz <we...@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
>
Re: [core] Enhancements to State Saving Caching Algorithm
Posted by Gerhard Petracek <ge...@gmail.com>.
hi,
i talked with ed about this topic and he opened [1].
imo we should implement a solution including a spi. it would be easier to
specify the mechanism based on our implementation.
furthermore, a spi would allow to implement a myfaces-core2 specific add-on
for libs like codi.
regards,
gerhard
[1] http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-949
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/5/11 Leonardo Uribe <lu...@gmail.com>
> 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
>