Are there any state saving method that would allow JSF application to intially save state data on server but after the session expire time interval , that state is transferred to client so that app is always responsive even after the session timeout on the server & memory is better managed on server?
Or any way this could be implemented? But I expect that this should be a part of the JSF specification !
Edit
After suggestion by BalusC, I'm highly impressed with the Stateless JSF principles & the current implementation for it. If anyone else here is also interested in stateless JSF being added to the JSF spec, consider having a look at or voting this issue.
Stateless JSF offers huge performance boosts for some payoffs like inability to create views dynamically (e.g. by binding, JSTL tags, etc), or modifying it.
A Stateless JSF operation mode would be incredibly useful for high-load applications and architectures:
This has previously been suggested by Jacob: http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin.html
This would help JSF ditch the stigma of "slow and memory hog," and help keep up with current tech trends (stateless architectures.)
How is that technically possible? The server can never reliably predict beforehand if the next request would create a new session and thus the response of the current request has to use client side state saving instead of server side state saving. If you ever succeed to implement it using plain JSP/Servlet, feel free to post a JSF specification enhancement request.
Just use client side state saving and make sure that partial state saving is enabled. The overhead is relatively minor as compared to full state saving.
Note that it's possible to use JSF entirely stateless. See also this blog. The only major payoff is that you can't create views dynamically (e.g. by binding, JSTL tags, etc), nor manipulate it after creation (e.g. by adding/removing component's children).
See also:
来源：https://stackoverflow.com/questions/10385340/jsf-state-saving-initially-to-server-on-session-timeout-transfer-to-client