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