[
https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776055#comment-13776055
]
Ertio Lew commented on MYFACES-3779:
------------------------------------
For doing this customization just two configurable parameters are needed, each
of which may be set in the web.xml only. First is, ofcourse specifying the
state saving as 'Mixedmode' (or anything similar). Second parameter, would be
the time interval for which state be kept on server & after which server would
remove that state (The client may request for this state, until this time
interval, to be transferred to client incase it is still alive but idle).
Incase we also support the 2nd enhancement that I suggested, to limit the
memory quota for server state saving & after which client saving would be used,
a 3rd param may be put in the web.xml specify the memory quota for server state
saving. All parameters may be put in the web.xml itself without maintaining a
separate config file.
It is not that we are choosing between server/client saving depending on which
view it is, but infact it is about how long has that view been idle so that
it's state should be transferred to client or how much quota has been exhausted
by all view state data stored on server so that for further views state is
saved on client. It is like we are using controlled server state saving for all
views & when we are out of quota or view is inactive for a long time we switch
to client state saving for that view.
The problem we are trying to solve here is both better performance & avoid
ViewExpiredExceptions.
> 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
