State Saving

The purpose of state saving in JSF is to persist the component tree and the state of those components so that they can be easily retrieved and, if possible, re-used as the user navigates between the various views in the application. In JSF, state saving is always active. By default, state saving is performed on the server, where the information is stored in the session. But JSF also provides the option of client-side state saving where the serialized state is sent to the client in each response and returned, if available, with each request. ICEfaces now fully supports server-side state saving. Client-side state saving is not supported and will throw an error if configured.

Server-side state saving is also necessary in a failover environment where the component structure and state are saved in the session, which is duplicated across the cluster nodes. The actual mechanism for this is specific to the application server that you are using and strategies that it provides. The state is restored, rather than freshly constructed, on a new node if failover occurs between user requests. ICEfaces provides different strategies for state saving depending on your requirements. The specifics of the different available state saving options are discussed in the sections that follow.

With this strategy, ICEfaces simply relies on the built-in state saving provided by the JSF implementation being used. From a memory perspective, this is potentially the least efficient solution depending on how the JSF implementation handles state saving.

For example, in the JSF reference implementation, state information is currently stored in a map of logical views with each logical view associated with a map of actual views. The maximum size of these maps is 15, which means that a total of 225 views can potentially be stored at any one time. The map sizes are configurable using context parameters. You can refer to the JSF reference implementation documentation for further details.

This behavior is not optimal for ICEfaces and is not recommended. Because ICEfaces does not support the operation of the browser's back button, the map of actual views is unnecessary and the use of a pool of maps for the views is also unnecessary. Hence, we have created the following implementations:

With ICEfaces, the ViewRootStateManagerImpl state manager implementation is the default implementation. It is automatically configured in icefaces.jar/META-INF/faces-config.xml so there is no need to adjust the configuration of your application. It is the recommended state saving strategy for all ICEfaces applications that are not configured for a failover environment. With this implementation, rather than iterate through the component tree to save state, the view root reference is simply kept in between responses and restored on the next request. It is the most performant and memory efficient option. Instances of UIComponent are not serializable, however, and this solution is not adaptable to an environment where session duplication is configured.

Note: Prior to the ICEfaces v1.8 release, ICEfaces used a context parameter, doJSFStateManagement, to turn state saving on and off. This only enabled a pseudo version of real state saving for the purpose of supporting the Seam framework. The real state saving was always a derivative of the view root state saving implementation. As of ICEfaces v1.8, state saving is now always considered to be "on" and only the implementation varies, so doJSFStateManagement is no longer supported.

ICEfaces includes a custom state manager implementation called SingleCopyStateManagerImpl that stores component states in the same way as the default implementation in the reference implementation. The difference is that it only ever stores a single copy of the state per view rather than a large map of maps. Because it uses the same state saving logic, it is highly compatible and, because it only saves a single copy, uses less memory than the default implementation. This is the recommended state saving strategy to use for applications that are configured for session persistence and failover. While we do not yet support seamless POST operations through failover, this setting will eventually be necessary for that feature.

You can configure your application to use this state manager implementation by adding the following to your application's faces-config.xml file: