aspose file tools*
The moose likes JSF and the fly likes Caching JSF dynamic content Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Caching JSF dynamic content" Watch "Caching JSF dynamic content" New topic
Author

Caching JSF dynamic content

J J Wright
Ranch Hand

Joined: Jul 02, 2008
Posts: 254
Hi,

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.

Am I missing something or are there any solutions to this problem?

Regards Jonathan


SCJP, SCWCD, SCBCD, SCEA 5
J J Wright
Ranch Hand

Joined: Jul 02, 2008
Posts: 254
Bump.

Does anyone have an opinion on this?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15639
    
  15

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.

Pure (basic) JSF doesn't include AJAX, however, so the above wouldn't apply to pages containing neither AJAX-capable JSF tags (like RichFaces/IceFaces) nor user-written JavaScript code. In pure JSF, the whole page gets handled for each request/response cycle.

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
J J Wright
Ranch Hand

Joined: Jul 02, 2008
Posts: 254
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.

Regards,

Jonathan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Caching JSF dynamic content
 
Similar Threads
WAF or JSF in SCEA 5 Part 2
Enabling Dynacache in Websphere v6 Cluster
JSF PrettyFaces Dynamic content?
HTML page comes BLANK in web Brwoser
How do JSPs control client content caching?