Thanks Simon & Renzo for explaining this feature! Renzo Tomaselli wrote: > > > > > > > > > Hi, > I recently had bad experiences while using t:saveState > with > client-side state, using Myfaces + Trinidad. > In this case Trinidad uses a numeric token in the page, while real > state contents are saved on the server without any serialization. > Although not explicitely set, I guess that SERIALIZE_STATE_IN_SESSION > was set to false, since I got exactly the behavior described here. > The problem occurs when objects are saved/restored and modified across > multiple requests. In such cases, the object remains the same unless > recreated. This means that any modification will be retrieved when > refreshing the page or retrieving an older one by push-back. > This in turn might lead to inconsistencies against other saved objects. > The symptom is that all works fine while navigating forwards, while > disasters appear while refreshing or pushing back to old views. > The simple workaround is to clone any saved object upon its setter call > in the bean - which occurs first during restoreView. This approach > ensures that future modifications will not be retrofitted to older > views. > The same holds true for any transient component, such as bound > components or linked beans: clean all them upon the first setter call > of the saved object, like the constructor would do. > Hope this helps, > > -- Renzo > > simon wrote: > > On Wed, 2008-05-21 at 10:02 -0700, hbMailingList wrote: > > > Hello, I was reading the performance wiki page, and it is suggesting > that > SERIALIZE_STATE_IN_SESSION should be set to false. > > I had 2 questions: > 1. What does this flag actually do? Does this mean the view and its > component tree is not saved in the session? What 'state' is it refering > it? > 2. Why doesn't this flag apply to client side state management? > > Thanks in advance > > > > When state is saved client-side, the tree state is turned into a byte > array, then base64-encoded, and that byte array is then embedded in a > hidden field in each form. > > When state is saved server-side, the normal behaviour is to first turn > it into a byte array, then save that byte array in the session. > > When the SERIALIZE_STATE_IN_SESSION flag is set to false, then the tree > state is not turned into a byte array; instead just a reference to the > tree root is stored in the http session. This is faster (all the work of > turning the tree into a byte-array is saved, and restore-view just > retrieves the original reference). It also allows objects in the view > tree which do not implement StateHolder or java.io.Seriaolizable. But > this can affect the behaviour of components if they are assuming that > saveState/restoreState are called. And it means that if you later enable > webapp clustering or client-side-state then you can get some nasty > surprises if some objects in the session are not actually serializable. > And it might take more memory (not sure about that). > > Regards, > Simon > > > > > > > >
-- View this message in context: http://www.nabble.com/what-is-SERIALIZE_STATE_IN_SESSION-tp17364366p17406675.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
