• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Life cycle Restore view state information storing

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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).
 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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....
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic