Server-state serialization in a session

On the server side, the state can be stored as a shallow copy or as a deep copy. In a shallow copy, the state is not serialized in the session (JSF stores only pointers to the state in a session and only the container deals with serialization stuff), which requires less memory and allows you to inject EJBs in the view scoped beans (use this technique carefully, since the changes that affect objects in one copy will be reflected in the rest of the copies). The deep copy represents a full serialization of the state in a session, which requires more memory and doesn't allow injecting EJBs.

Note By default, JSF Mojarra uses shallow copy, while JSF MyFaces uses deep copy. Anyway, perform a quick test to be sure which is the default.

We can easily alter the default behavior by explicitly setting the javax.faces.SERIALIZE_SERVER_STATE context parameter in web.xml. This context parameter was introduced starting with JSF 2.2 and represents the standard context parameter for setting the server state serialization in Mojarra and MyFaces. You can indicate that the shallow copy should be used as follows:

<context-param>

<param-name>javax.faces.SERIALIZE_SERVER_STATE</param-name>

<param-value>false</param-value>

</context-param>

Note In order to avoid exceptions of type, java.io.NotSerializableException (and warnings of type Setting non-serializable attribute value ...), keep in mind that serializing the state in a session implies serializable backing beans. (They import java.io.Serializable and their properties are serializable. Special attention to nested beans, EJBs, streams, JPA entities, connections, and so on.) This is also true when you are storing the view state in the client since the entire state should be serializable. When a bean property should not (or cannot) be serialized, just declare it transient and do not forget that it will be null at deserialization.

In addition to the preceding note, a common case implies java.io.NotSerializableException, when the state is saved on the client. But when switching the state on the server, this exception miraculously disappears on Mojarra, while it is still present in MyFaces. This can be confusing, but is perfectly normal if you are using Mojarra implementation, the state should be fully serializable while saving it on the client (and it is not, since this exception occurred), while this is not true on the server, where Mojarra by default doesn't serialize the state in a session. On the other hand, MyFaces defaults to serialize the state; therefore, the exception persists.

Note Sometimes, you may optimize memory usage and save server resources by redesigning the application state, which contains view or session or application backing beans (don't cache the data that can be queried from a database and try to reduce the number of such beans). Besides managing the view state, this is also an important aspect that reflects directly in performance. When more memory is needed, the container may choose to serialize the parts of the application state, which means that you have to pay the price of deserialization also. While the price of saving in the session is represented by memory, the price of serialization/deserialization is represented by the time and insignificant disk space (at least it should be insignificant).

You also may be interested in:

Detecting stateless views programmatically

JSF saving the view state

JSF logical and physical views

JSF 2.2 is stateless

JSF 2.2 - The view scoped beans and thestateless feature