Madhav Bhargava wrote:
http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtTopicFile.jsf_apps%7Cadfcreate%7Caf_astatesaving~html/
<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|."
Yep, so in other words it's the same as server-side state saving, except
that there is also a single client-side field that indicates which
server-side state block it is associated with. No savings there in
memory, though it may help keep things in order when people use
back/forward buttons etc. Actually, normal MyFaces behaviour is to
render a counter into the client when using server-side state saving for
exactly this same purpose.
There are some proposals around to reduce the amount of JSF state that
needs to be maintained, but AFAIK all these cause changes in JSF
behaviour, ie would not be compliant with the current JSF spec.
