You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by hbMailingList <hb...@gmail.com> on 2008/05/21 19:02:46 UTC
what is SERIALIZE_STATE_IN_SESSION
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
--
View this message in context: http://www.nabble.com/what-is-SERIALIZE_STATE_IN_SESSION-tp17364366p17364366.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: what is SERIALIZE_STATE_IN_SESSION
Posted by hbMailingList <hb...@gmail.com>.
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.
Re: [Tomahawk][Myfaces] how to prevent scattered js/css file references
and loading
Posted by Renzo Tomaselli <re...@tecnotp.it>.
Scott, yes I know. But Trinidad is less important in this context, since
it manages to bundle its own stuff in two files, one for js and another
for css.
Tomahawk is a disaster: those two components I mentioned below include
*nine* single files in the page header.
-- Renzo
Scott O'Bryan wrote:
> I don't know about Tomahawk, but you will not be able to wire Trinidad
> in with jawr. Here is the thread where we discussed this.
> http://www.mail-archive.com/users@myfaces.apache.org/msg48242.html
>
> Renzo Tomaselli wrote:
>> Hi all, I'm trying to concentrate js/css references on pages through
>> jawr (https://jawr.dev.java.net/), to improve loading performance.
>> I use almost Trinidad components, plus t:inputDate (more appealing
>> than Trinidad) and t:jscookMenu (the only dropdown menu component
>> around) from Tomahawk.
>> While Trinidad collects its own js/css files together, Tomahawk
>> components include scattered references to both js and css files from
>> the page head, as a kind of rendering postprocessing.
>> I wonder if anybody can suggest a way to avoid this effect by cutting
>> those lines, so that I could include all needed files in jawr
>> bundles, loading them in a single shot.
>> Thanks,
>>
>> -- Renzo
>>
>
>
Re: [Tomahawk][Myfaces] how to prevent scattered js/css file references
and loading
Posted by Scott O'Bryan <da...@gmail.com>.
I don't know about Tomahawk, but you will not be able to wire Trinidad
in with jawr. Here is the thread where we discussed this.
http://www.mail-archive.com/users@myfaces.apache.org/msg48242.html
Renzo Tomaselli wrote:
> Hi all, I'm trying to concentrate js/css references on pages through
> jawr (https://jawr.dev.java.net/), to improve loading performance.
> I use almost Trinidad components, plus t:inputDate (more appealing
> than Trinidad) and t:jscookMenu (the only dropdown menu component
> around) from Tomahawk.
> While Trinidad collects its own js/css files together, Tomahawk
> components include scattered references to both js and css files from
> the page head, as a kind of rendering postprocessing.
> I wonder if anybody can suggest a way to avoid this effect by cutting
> those lines, so that I could include all needed files in jawr bundles,
> loading them in a single shot.
> Thanks,
>
> -- Renzo
>
[Tomahawk][Myfaces] how to prevent scattered js/css file references
and loading
Posted by Renzo Tomaselli <re...@tecnotp.it>.
Hi all, I'm trying to concentrate js/css references on pages through
jawr (https://jawr.dev.java.net/), to improve loading performance.
I use almost Trinidad components, plus t:inputDate (more appealing than
Trinidad) and t:jscookMenu (the only dropdown menu component around)
from Tomahawk.
While Trinidad collects its own js/css files together, Tomahawk
components include scattered references to both js and css files from
the page head, as a kind of rendering postprocessing.
I wonder if anybody can suggest a way to avoid this effect by cutting
those lines, so that I could include all needed files in jawr bundles,
loading them in a single shot.
Thanks,
-- Renzo
Re: what is SERIALIZE_STATE_IN_SESSION
Posted by Scott O'Bryan <da...@gmail.com>.
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
>>
>>
>>
Re: what is SERIALIZE_STATE_IN_SESSION
Posted by simon <si...@chello.at>.
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