Why does JSF need to save the state of UI components on the server side ?
Because HTTP is stateless and JSF is stateful. The JSF component tree is subject to dynamic (programmatic) changes. JSF simply needs to know the exact state as it was when the form had been displayed to the enduser, so that it can successfully process the whole JSF lifecycle based on the information provided by the original JSF component tree when the form has been submitted back to the server. The component tree provides information about the request parameter names, the necessary converters/validators, the bound managed bean properties and action methods.
Until what point in time does JSF save the state of UI components on the server side and when exactly is the UI component's state information removed from the server memory?
Those two questions seem to boil down to the same. Anyway, this is implementation specific and also dependent on whether the state is saved on server or client. A bit decent implementation will remove it when it has been expired or when the queue is full. Mojarra for example has a default limit of 15 logical views when state saving is set to session. This is configureable with the following context param in web.xml
:
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>15</param-value>
</context-param>
See also Mojarra FAQ for other Mojarra-specific params and this related answer com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews
As a logged-in user on the application navigates though pages, will the state of components keep on accumulating on the server?
Technically, that depends on the implementation. If you're talking about page-to-page navigation (just GET requests) then Mojarra won't save anything in session. If they are however POST requests (forms with commandlinks/buttons), then Mojarra will save state of each form in session until the max limit. This enables the enduser to open multiple forms in different browser tabs in the same session.
Or, when the state saving is set to client, then JSF won't store anything in session. You can do that by the following context param in web.xml
:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
It will then be serialized to an encrypted string in a hidden input field with the name javax.faces.ViewState
of the form.
I dont understand what the benefit of keeping the UI component's state on the server side is. Isn't directly passing the validated/converted data to managed beans enough? Can/should I try to avoid it?
That's not enough to ensure the integrity and robustness of JSF. JSF is a dynamic framework with a single entry point of control. Without a state management, one would be able spoof/hack HTTP requests in a certain way (e.g. manipulating disabled
, readonly
and rendered
attributes), to let JSF do different -and potentially hazardful- things. It would even be prone to CSRF attacks and phishing.
And won't that consume too much memory on the server side, if there are thousands of concurrent user sessions? I have an application where users can post blogs on certain topics. This blogs are quite large in size. When there will be post back or request for viewing the blogs, the large blogs will be saved as a part of the state of components. This would consume too much memory. Isn't this a concern?
Memory is particularly cheap. Just give the appserver enough memory. Or if network bandwidth is cheaper to you, just switch state saving to client side. To find the best match, just stresstest and profile your webapp with expected max amount of concurrent users and then give the appserver 125% ~ 150% of maximum measured memory.
Note that JSF 2.0 has improved a lot in state management. It's possible to save partial state (e.g. only the <h:form>
will be saved instead of the whole stuff from <html>
all the way to the end). Mojarra for example does that. An average form with 10 input fields (each with a label and message) and 2 buttons would take no more than 1KB. With 15 views in session, that should be no more than 15KB per session. With ~1000 concurrent user sessions, that should be no more than 15MB.
Your concern should be more focused on the real objects (managed beans and/or even DB entities) in session or application scope. I've seen lot of codes and projects which unnecessarily duplicates the entire database table into Java's memory in flavor of a session scoped bean where Java is been used instead of SQL to filter/group/arrange the records. With ~1000 records, that would easily go over 10MB per user session.
Best Answer
Adding to the previous answer, ever since JSF 2.0 something called
partial state saving
is used by default.The default view description language in JSF (Facelets) creates the whole component tree from the original Facelet after every request and initializes the components from their corresponding tag attributes. It then marks the state.
Every subsequent state change is then remembered as a delta change, and it's this state that is actually being saved. It might just well turn out that there simply are no such changes, and then the view state is empty (because of a bug, the state was never truly empty, but that has been recently fixed. See http://java.net/jira/browse/JAVASERVERFACES-2203 for details)
So the big question is, what's actually in this state then when it's non-empty?
As BalusC already remarked, this could hold dynamic changes to the component tree. Those changes can either be initiated from backing beans, or from within static components. A simple example of the kind of component that does this dynamic changing is a table component that creates child column components based on the actual number of columns in a data set.
Another important usage for the view state is remembering values that have been changed inside components, but have not been pushed into the model. This can be such things as flicking a switch in a switch component, moving a slider in a dial component etc.
One particular example is the
viewParam
component, which remembers the request parameter (query string parameter for GET or non-faces POST parameter) with which it was initialized. See this for some more info about that: http://arjan-tijms.omnifaces.org/2011/07/stateless-vs-stateful-jsf-view.htmlThere is also a strong relation with stateful components remembering UI state and conversion or validation that fails. In this case, the UI components will remember the values entered by the user, and will remember that there was a conversion/validation error.
Yet another usage for the state is optimization. Some components calculate values that they deem to be expensive to calculate and store these in the view state. For instance, UIInput components do this after the first post-back:
After this
validateEmptyFields
is stored in the view state so it doesn't have to be calculated again upon the following form submits. An improvement would be if users can choose between re-calculating or storing (the well know time-space optimization).The very concept of state is what has plagued web application development since its early conception. Everyone wants to have interactions that are essentially stateful, yet almost nobody wants to handle it or even think about it.
JSF has been trying to provide an answer here, but it's obviously not perfect and there's room for improvement. JSF's insistence on being able to restore view state (even empty view state) can be troublesome, although as was mentioned in another answer it does provide an implicit protection against CSRF. JSF 2.2 will get more explicit CSRF protection (see e.g. http://arjan-tijms.omnifaces.org/p/jsf-22.html#869), so maybe we will see some change here in the future.
Having an option to turn off state per component and having an easy hook to restore state incase the framework can't (as in ASP.NET) might also be helpful.