JSF State Saving: Best of Both Worlds
June 27, 2006 2 Comments
When the state saving method of a JSF application is set to server by the javax.faces.STATE_SAVING_METHOD context parameter, state of the each page is saved in session map. The viewid of each page which corresponds to the pagename is used as the key in session. Although this method has performance advantages compared to the client state saving, nobody is perfect. The thing is that, if you have memory issues saving each page’s state in session does not seem to be a good choice.
Following is the output of FacesTrace tool visualizing the situation, there are 3 pages visited, each view of the page is hold in session by the page name and there is also a list in session holding the list of the view ids.
When the state saving is set to client, the state is sent to the browser as a hidden variable and then restored when a post occurs. This means there is only one view each request is aware of, this is also possible with the server side state saving,(with a little manual tuning of course). The best place to intersect the navigation and clean the view which is navigated from is a navigation handler. Here is one for this job;
This example works for the Sun’s RI implementation, I remember once there is a context parameter to tune the number of views in session in MyFaces but I cannot see it in the latest builds. Anyway this method takes the both side’s advantages in the state saving business. There is only one view the session allowed and the overhead caused by restoring the encoded state in client mode is escaped.