myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Date Thu, 22 May 2008 12:31:28 GMT
Yes, Trinidad implemented this optimization early..  I think JSF1.2's 
implementation of this feature was actually taken from the Trinidad 
requirements and proposed by Adam.

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  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 raw message