What is the usefulness of statelessness in JSF?

Question

According to this blog JSF is going stateless . Isn't the whole point of using JSF is that it makes saving and restoring state a chore . What is the point of JSF becoming stateless ? Can you please provide an example where this can be useful .

Answer 1

First of all, I would like to clarify that JSF isn't exactly "going stateless" at its whole own. JSF just adds a new feature enabling the developers to create stateless views/forms on demand.

State saving is particularly helpful in dynamically manipulated forms with e.g. conditionally ajax-rendered parts. It remembers the state of the form across ajax based postbacks. In other words, it are those forms where you absolutely need a view scoped managed bean instead of a request scoped managed bean. In case of static forms tied to a request scoped bean, the state could easily be recreated on a per-request basis based on the view file and hence doesn't necessarily need to be saved.

State saving has in case of server side state saving management however a cost in terms of server memory and session creation. Also, it has the additional disadvantage that a ViewExpiredException would occur during a postback while the session has expired. All of this can be solved by setting the state saving management to client side. But this has in turn a cost in terms of network bandwidth and lower performance due to serialization.

For example, in case of large websites covering a "public" and "restricted" section, you'd like to postpone session creation until the user has actually logged in. However, if you have a JSF login form on the public part, then the session would still be created by just accessing that page. This is an unnecessary cost if the form has basically no dynamic state at its own and is tied to a request scoped bean.

True, this cost is negligible if you have state of the art hardware, but it's not negligible if you have relatively a lot of visitors and/or relatively poor hardware. In that case, measuring is knowing. Also, it is not always possible to go fully stateless, you'd lose the benefit and experience of having dynamically manipulated views/forms. You could however theoretically maintain the state on a per-request basis by fiddling with hidden input fields and/or custom request parameters.

Noted should be that statelessness has an additional disadvantage that it's theoretically more easy to perform a CSRF attack if there's an open XSS hole. Fortunately, with JSF2/Facelets it's already very hard to have a XSS hole. The only way to get that is to use a <h:outputText escape="false"> to redisplay user-controlled data.

See also:

• Why JSF saves the state of UI components on server?
• Am I under risk of CSRF attacks in a POST form that doesn't require the user to be logged in?
• CSRF, XSS and SQL Injection attack prevention in JSF
• How does different phases of JSF lifecycle behave in a stateless view containing a form

Answer 2

The point is only to maintain state when there is real state to maintain.

One of the big issues with JSF has been scaling out.

You basically have had two choices with JSF:

• store state on server - pros: faster response time; cons: you need boot loads of memory to handle more than about 2-300 users "just browsing" eg before they login or add anything to the shopping cart

• store state on client - pros: removes the memory limit; cons: increases the server bandwidth as the component tree has to be sent to the client each time

Stateless is supposed to ensure that JSF can be used to serve content efficiently while the user has no state required to be maintained.

There are additional refinements, such as allowing the component tree to be reused where it makes sense, but the idea is to let the app scale better.