Yee CN wrote:
Simon,
What exactly is "SERIALIZE_STATE_IN_SESSION=true/false" that is new in the
nightly then?
As far as I can tell - the 1.1.1 release was not serializing the bean I
placed in t:saveState, but it does in the nightly.
Yep, that seems right to me.
So is 1.1.1 equivalent to
SERIALIZE_STATE_IN_SESSION=false?
Yes, I believe so.
Where was the state being saved then?
In 1.1.1, when server-side saving was enabled, I believe the VIEW state
was being saved simply by storing a reference to the UIViewRoot (and
hence all its children) in the session - unserialized. As long as the
webapp didn't have clustering or hot-deploy enabled, then the UIViewRoot
object was simply kept in memory until the next access.
As described in the previous email, normal "managed beans" are not
affected by the view serialization process. However a bean referenced
from a t:saveState component does get stored in the same way as the
view. In 1.1.1, because server-side state saving simply stored by
putting a reference to the UIViewRoot into the session (ie no
serialization occurs), the bean that the t:saveState referred to wasn't
serialized. If you'd turned on client-side saving, then you would have
got the serialization failure in 1.1.1.
Now I think you can get the same effect with
SERIALIZE_STATE_IN_SESSION=false, ie "don't serialize the state".
However the new default is SERIALIZE_STATE_IN_SESSION=true, ie to run
the serialization process on the UIViewRoot, then store this serialized
data in the session instead of the original UIView component. This:
* Is more memory-efficient (though more CPU intensive)
* Makes behaviour consistent between client-side and server-side saving.
Formerly, an app that worked with server-side state might fail when
client-side was enabled because of serialization failures.
* Ensures that any app that works correctly will also be clusterable.
Formerly, an app might run on a single system but fail when clustering
was enabled.
Thanks taking time to explain - perhaps this should go to myfaces wiki?
Yes, that would be a good idea.
Note that I'm no expert in this area...
Cheers,
Simon
Regards,
Yee
-----Original Message-----
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 20 December 2005 5:40 AM
To: MyFaces Discussion
Subject: Re: Session Scope Bean does NOT require serialization. Myfaces bug?
Aleksei Valikov wrote:
Hi.
My understanding is that with R1.1.1 the session scoped beans are not
serialized (thus Myfaces cannot be used in clustered deployments with
shared
sessions between containers). Serialization of backing beans to
session is
only added in the current build - and thus my questions regarding its
performance.
Please correct me if I am wrong.
I don't get it. Once you declare your bean as session-scoped, it simply
becomes a session attribute - and managed by the servlet container. It's
servlet container's task to serialize the session (together with its
attributes), not JSF's. MyFaces can check if all of your session-scoped
beans are serializable, but performing the serialization is above its
tasks.
MyFaces state-handling/serialization applies only to the view tree (ie
UIComponent objects).
With managed beans, the MyFaces state-handling is irrelevant; JSF
doesn't try to "serialize backing beans". The beans simply go into the
servlet engine's request, session or application scope as for a non-JSF
application. Objects in the session don't need to be serializable,
though things like clustering and hot-restart won't work if they are not.
However when using t:saveState, the two worlds do meet, because that
component is a UIComponent that gets stored along with the View, but it
retains a reference to a managed bean that it serializes too. In this
case the referenced bean *must* be Serializable (or implement
StateHolder) as documented for the saveState component.
Cheers,
Simon
