http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtTopicFile.jsf_apps%7Cadfcreate%7Caf_astatesaving~html/ refer the above link for more information.
It says that - " Client-side state saving with ADF Faces uses tokens and does not require writing to a huge, hidden field that is sent between the client and the server with each request. A simple token instead is stored on the client, which identifies a block of state stored back on the HttpSession." ~madhav On 1/31/07, Madhav Bhargava <[EMAIL PROTECTED]> wrote:
ADF client side state saving is faster and ligther. You can give that a shot. On 1/31/07, Gattu, Praveen <[EMAIL PROTECTED] > wrote: > > Ok I tried using the compression flag with the client side save state > and it cut down the page size by 2/3. That satisfies my needs for now. > However is there a compression ratio parameter that I could tweak. I > couldn't find any from the documentation. > Also I was reading some blogs from Jacob Hookom, about stateless JSF > session, does anyone know whats the status of this. > http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html > > > -Praveen > > -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 30, 2007 11:16 AM > To: MyFaces Discussion > Subject: Re: Jsf_tree_64 > > Gattu, Praveen wrote: > > Hi Folks - We are using the myfaces(1.1.5 snapshot). I got couple of > > questions regarding the state save. So far we were using the server > > side save state to reduce the page size of our pages, but noticed that > > > with this approach, our app cannot work behind a load balancer. We are > > using Tomcat as webserver, and we donot intend to use tomcat > > clustering. In order to avoid this we switched to client side save > > state. Although this solved the load balancing issue, we saw the page > > sizes increase by 10-15x. A page with server side save state with a > > size of 18kb, now measures ~300kbyes with client side save state. > > > > I noticed that the framework is using "jsf_tree_64" hidden field for > > all the command links, to store some form of data. What is this field > > used for in the framework? > > Saving the current component tree. It needs to be stored somewhere, and > if you don't want it in the http session ("server-side state") then it has > to be stored in the form ("client-side state"). > > > Is there a way to avoid this hidden field, without > > using the server side save state? > > Nope. > > Are there any other approaches I > > should be looking to solve both load balancing and low page size? > > Perhaps a "sticky load balancer", ie one that is http-session-aware and > therefore directs all requests for a specific session to a single tomcat > instance? > > I can't see any other alternatives, if you're opposed to clustering; the > tomcat instance that handles the submit must have the component tree data > available, and the only options are (a) in the http session, or (b) embedded > in the posted data. > > Regards, > > Simon > -- When I tell the truth, it is not for the sake of convincing those who do not know it, but for the sake of defending those that do
-- When I tell the truth, it is not for the sake of convincing those who do not know it, but for the sake of defending those that do
