JSF State in database

It’s a fact that JSF saves too much to be stateful. When statesaving is set to client, you can see the big javax.faces.ViewState hidden field with the encoded state. For users with low bandwith or mobile users this is an issue because of the size of the state written on the client. In case the state is kept on the server side, it solves the bandwith issues but allocates memory on httpsession.

I’ve written a custom experimental DBStateManager that keeps the state in the database. The token sent to the client is the identifier of the current state. The advantage is the gain of bandwitdh(a page’s size went from 140Kb to 26Kb) and no memory is allocated in httpsession, the drawback is the db hit (can be improved by caching). Btw it’s easy to plug-in your own implementation for state manager by;


I’m one of the many that’s waiting for the state management enhancements in JSF 2.0. Saving only the delta changes
in the component state instead of the complete state of a component is a major improvement I’m looking forward to.


4 Responses to JSF State in database

  1. Pingback: JSF State in Database « Cagatay Civici’s Weblog

  2. John says:

    JSF is relevant for intranet apps with minimal concurrent users. Anything more and i guess the project lead’s head is in the line when scalability issues arise.

  3. Rafael Ponte says:

    Pretty good Cagatay,

    The Myfaces Trinidad makes something similar using tokens on client-side (org.apache.myfaces.trinidad.CLIENT_STATE_METHOD), but it unfortunately continues using http session, hence it improves the bandwidth issue (mainly for AJAX requests) but allocates memory on the server.

    Well, don’t you think it would be better to persist the state in the disk instead of database?

    Could you show your DBStateManager implementation?

  4. JD says:

    I’m looking at doing something similar, except not using a DB. I was wondering if you had some example code I could reuse.

%d bloggers like this: