• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Caching JSF dynamic content

 
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bump.

Does anyone have an opinion on this?
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic