myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Brökelmann <mbroekelm...@googlemail.com>
Subject Re: Session Scope Bean does NOT require serialization. Myfaces bug?
Date Tue, 20 Dec 2005 08:37:26 GMT
Simon is right (as always!). But the new serialization stuff is not
available in 1.1.1 only in current nightly (where it is waiting for
the next release ;))

2005/12/20, Simon Kitching <skitching@obsidium.com>:
> 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:skitching@obsidium.com]
> > 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
> >
> >
> >
>
>


--
Mathias

Mime
View raw message