[
https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774397#comment-13774397
]
Leonardo Uribe commented on MYFACES-3779:
-----------------------------------------
In JSF 2.2, ViewScoped beans are stored in session, no matter if client side or
server side state saving is used.
The code we have right now in MyFaces Core is good enough to be extended. The
problem is there is no clarity about the usefulness of the strategy proposed,
because with the new JSF 2.0 partial state saving algorithm, the ammount of
memory required to store views into session has been reduced to its minimal
expression.
In this article:
http://content.jsfcentral.com/c/journal/view_article_content?cmd=view&groupId=35702&articleId=73398&version=1.8#.UkAArj9Kvb0
At the end there is a graph showing how the state evolves for a client in a
simple application. Other frameworks like Grails and Tapestry that are supposed
to be "stateless" uses almost the same or more session space that MyFaces Core.
The focus used to solve the problem until now has been to reduce the size
required to store views into the state. In this context, it is questionable if
the technique can be useful from performance perspective.
In other words, it is required more information about the usefulness of the
change proposed from performance perspective. I think it is better to try to
solve this at spec level and live for now with a hack outside MyFaces Core
code. It is clear that the hack proposed aims to solve some situations where a
ViewExpiredException should not be thrown.
> Mixed mode(Server+client) for state saving
> ------------------------------------------
>
> Key: MYFACES-3779
> URL: https://issues.apache.org/jira/browse/MYFACES-3779
> Project: MyFaces Core
> Issue Type: New Feature
> Reporter: Ertio Lew
>
> How about having a mixed mode for state saving whereby state is initially
> kept on server for a configurable amount of time (so that fast frequent
> requests are served without transferring the state from client to server
> several times, the drawback with client side saving) & after that period of
> time if the page is still alive in browser but it is idle, a javascript
> request is triggered which asks the server for that state data & now it will
> be kept on client side, now the client & the server both know that state for
> this session is there on client. If the page has died & no request has been
> sent to server asking for state data till that period of time, then state
> data would be removed from server.
> A further enhancement could be that you could set a fixed amount out of all
> memory on server that you want to allocate for state saving of all sessions.
> Till the time that quota remains, state is kept on server using that quota.
> But when that quota is over all the state information for further sessions is
> kept using client side state saving. Also a mixed mode.
> Such mixed modes would be very helpful in improving performance, & better
> utilization of the server resources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
