Re: Serializing server state final thoughts

From: Ryan Lubke <Ryan.Lubke_at_Sun.COM>
Date: Wed, 12 Sep 2007 10:44:18 -0700

Ed Burns wrote:
>>>>>> On Wed, 12 Sep 2007 09:10:36 -0600, Michael Youngstrom <> said:
> MY> So, the the votes are in and it looks like the decision is to not
> MY> serialize the server state. However, does this snippet from the spec
> MY> make our vote irrelevant?
> MY> Section 7.6.3: when talking about server state management says:
> MY> "The default implementation Serializes the view in both the client and
> MY> server modes. In the
> MY> server mode, this serialized view is stored in the session and a
> MY> unique key to retrieve the
> MY> view is sent down to the client. By storing the serialized view in the
> MY> session, failover may happen using the usual mechanisms provided by
> MY> the container."
> MY> It seems pretty explicit here. This is probably why Myfaces
> MY> serializes the view by default in "SERVER" mode. Does this snippet
> MY> from the spec change our decision at all? If we decide to ignore this
> MY> snippet of the spec we should probably let MyFaces know so that they
> MY> don't have to serialize the view by default.
> Ah yes, I recall now why we put that in there. It was to guarantee that
> failover would work in clustering server scenarios.
This works as it is now without serializing the data to the session, as
long as developers
are aware of the rules surrounding storing data in the HttpSession.
> I propose we modify the spec to introduce a config param that turns it
> on, but have it off by default. Should I take that to the EG?
> Ed