Re: what is SERIALIZE_STATE_IN_SESSION

[Renzo Tomaselli]

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