Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Life cycle Restore view state information storing  RSS feed

 
indra sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
James McCluskey
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Ryan Lubke
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
James McCluskey
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
indra sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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....
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!