dev@javaserverfaces.java.net

Re: [REVIEW/632] Server-side state saving sensitive to model changes

From: Michael Youngstrom <youngm_at_gmail.com>
Date: Fri, 7 Sep 2007 11:52:15 -0600

I think rather than the special case of serializing UIViewRoot to
solve the Seam specific case I would prefer to try throwing this
specific issue back at Seam and force Seam to perhaps do a serialize
clone of it's "PAGE" scoped components at some safe time in the
lifecycle perhaps???

Regardless, I guess my greater fear is with all the other
components/frameworks that are using the view under the assumption
that the values will be preserved/isolated with the view instance it
was stored in? (e.g. tomahawk:saveState, several Gravel components,
perhaps many more?).

Mike

On 9/7/07, Adam Winer <adam.winer_at_oracle.com> wrote:
> It sounds like the issue here is restricted to UIViewRoot
> attributes, as Seam is using the UIViewRoot as a bonus
> scope, right?
>
> What if UIViewRoot's saveState() implementation
> ran serialization on the results of its super.saveState()
> call, and we left alone the rest of the page's state?
>
> -- Adam
>
>
> Michael Youngstrom said the following on 9/7/07 9:40 AM PT:
> > It's looking like Serialization by default is going to lose. :)
> >
> > I just want to quickly make sure everyone is fully aware of the
> > problem this is solving. If I'm using server side state saving and
> > store an object in the view and in a later view modify that object
> > then all of the past views will be changed as well potentially causing
> > any number of hard to detect problems. Generally where immutable
> > stuff is stored in the view this is not a problem but with projects
> > like Seam using the view as an optional Scope this basically breaks
> > the scope's back button functionality which is the main reason why
> > someone would choose the PAGE scope over CONVERSATION scope in Seam.
> >
> > I personally can go either way on this issue because it is a rather
> > irregular issue and would cause significant performance problems if
> > turned on but I just want to make sure everyone is aware that this
> > issue is not just about parity between client and server state saving
> > but it's also about the correct behavior of data stored in the view.
> >
> > I agree though that some actual benchmark data would be useful.
> >
> > Mike
> >
> > On 9/7/07, Ed Burns <ed.burns_at_sun.com> wrote:
> >>>>>>> On Fri, 07 Sep 2007 11:32:22 +0200, "Jesse Alexander (KSFH 323)" <alexander.jesse_at_credit-suisse.com> said:
> >> JA> +1 from me too on not making the serialization default. Serialization is
> >> JA> way too costly.
> >>
> >> I cast my lot with Herr Jesse and Mr. Winer. I too would like to see a
> >> quantitative rationale, other than parity with the client side model.
> >>
> >> Also, Herr Jesse, don't say "+1 for not making..." It would be more
> >> clear to say "-1". Being an unrepentant email skimmer, when I see "+1"
> >> on a thread, I assume you agree with the proposal.
> >>
> >> Thanks,
> >>
> >> Ed
> >>
> >>
> >> --
> >> | 156 Business Days until JavaOne 2008
> >> | ed.burns_at_sun.com | office: 408 884 9519 OR x31640
> >> | homepage: | http://purl.oclc.org/NET/edburns/
> >> | aim: edburns0sunw | iim: ed.burns_at_sun.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> >> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> > For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>