Forums Register Login

Life cycle Restore view state information storing

+Pie Number of slices to send: Send
In Restore view stage of JSF lifecycle view ID is used to look up the components for the current view.
FacesContext object contains all the state information JSF needs to manage the GUI component's state for the current request in the current session.
So context keeps all the state information for the view.
So if my application has lots of pages,so faces context can be overloaded with state information ,lots of memory occupied and ultimately it can lead to server crash.
Can any body throw light on it.
Thanks in advance...
+Pie Number of slices to send: Send
The following added to your web.xml will switch the state saving strategy to client side:



It seems that the recommended approach is for client state for most applications. Of course, this will increase the amount of network traffic - I understand this can be compressed too (I've no idea how to do that but I'm sure google will come up with something).
+Pie Number of slices to send: Send
 

Originally posted by indra sen:
In Restore view stage of JSF lifecycle view ID is used to look up the components for the current view.
FacesContext object contains all the state information JSF needs to manage the GUI component's state for the current request in the current session.
So context keeps all the state information for the view.
So if my application has lots of pages,so faces context can be overloaded with state information ,lots of memory occupied and ultimately it can lead to server crash.
Can any body throw light on it.
Thanks in advance...



I wouldn't recommend client state saving unless bandwidth isn't an issue.
As for server side with the JSF RI, the state stored in the session is done so within a Map using an LRU algorithm, so the memory usage is constrained.
The 1.2 RI has two parameters to enable fine tuning of these Maps.
+Pie Number of slices to send: Send
Seems there a lot of confusion about this then - I've definitely read articles where the opposite is advised (I would fish some links out, but I'm on a slow connection right now).

As a by the way, doesn't ASP.NET use client side as its default?

What about back button problems with server side state? Has that been ironed out on JSF 1.2?
+Pie Number of slices to send: Send
Thanks for lots of good thoughs.
If state saving in client then hidden field stores lots of state info,which is passed evertime with a submit.
which is not a good design i think.
so if memory is not issue in server then we should go for it.
Thanks....
That feels good. Thanks. Here's a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 4312 times.
Similar Threads
Inject persistence unit/context in phase listner
Fundamental life cycle question
Where is FacesContextFactory instance stored ?
Vulnerability issues in JSF
Not Session Timeout, but throw javax.faces.application.ViewExpiredException
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 11:02:59.