Caching JSF dynamic content

I have a quick question about dynamic content caching and View States. Say I have a page containing a data table and command links. When this page is generated the resulting HTML contains a javax.faces.ViewState hidden field to enable JSF to recreate the view on submission. If the value of the ViewState is stored in a client's session how can the page be effectively cached using something like OSCache's CacheFilter? When the content is returned to another client they'll get a javax.faces.application.ViewExpiredException on submission.

Obviously I can get round this problem by using client side view state saving, but then I incur a penalty with dramatically increased page size.

On the issue of caching dynamically generated content I've seen people argue the case that it's not necessary in JSF as you can use application scoped managed beans. But this still requires the content to needlessly regenerated for each request and doesn't provide you with an invalidation mechanism when the underlying data changes.

We discourage "bumping". The JavaRanch gets enough traffic that if you don't get an answer, it usually means we don't know either, unless you're simply asking a question that indicates you were too lazy to do basic homework. Or using a display name that blatantly violated our rules.

In my case, I really couldn't quite understand what you wanted. I'll make a stab, though.

There's no such thing as a "client's session" on the client's computer. HTTP doesn't work that way. About the closest thing to a "session" is cookies. Anything else is just what's on the request that the client sends to the server and it gets destroyed as soon as the request was sent. In the case of AJAX, the client has effectively opened a temporary, invisible new browser window, made the request from there, receiver the response there, and then proceeds to patch the recieved data into the DOM of the currently-displayed page. AJAX muddies up some of the rules.

The JSF page state can either be passed back and forth as part of this process, or it can be maintained on the server, according to which option you set in web.xml. However, since the page is destroyed when you click "submit" and a new response arrives, there's no way to "cache" this on the client.

Server-side caching is another matter. But since JSF pages are primarily dynamic content, it's not all that likely that any messing around in the internals will be worth the trouble. Plus, if the framework providers do optimize the process in future, that's the kind of code that gets broken first and hardest.

An IDE is no substitute for an Intelligent Developer.

J J Wright
Ranch Hand

Joined: Jul 02, 2008
Posts: 254

posted May 21, 2009 10:43:17

0

Hi Tim

Thanks for taking the time to reply, and apologies for "bumping".

There's no such thing as a "client's session" on the client's computer.

The term client was probably a bit ambiguous here. I was using it in the sense of a user. The client's session was therefore meant to equate to the user's HttpSession on the server.

The JSF page state can either be passed back and forth as part of this process, or it can be maintained on the server, according to which option you set in web.xml. However, since the page is destroyed when you click "submit" and a new response arrives, there's no way to "cache" this on the client.

This is the basis of my question. If I have a dynamically generated page that changes very infrequently I obviously want to cache the dynamic content instead of going through the process invoking business objects, possibly querying a database, and finally, regenerating the HTML for every request.

If I maintain page state on the server it's stored in the user's HttpSession. This poses a big problem if you want to cache the HTML generated by JSF because the first person to be served the cached HTML won't have the page's state stored in their HttpSession. As you say, the alternative is to pass page state back and forth with every request but then you incur a penalty, either by compressing the content or increasing the page size. Under heavy load this is going to make a difference.

My question, therefore, is are there any solutions to this problem? Am I correct in assuming that the requirement to maintain page state makes serving cached JSF generated HTML problematic? Are there any solutions to the problem of having to pass page state back and forth for every request? If the answer is no, then JSF probably isn't the right framework for my problem. There just seems to be very little information on the topic.