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