Re: Serializing server state final thoughts

From: Norbert Truchsess <>
Date: Fri, 14 Sep 2007 00:19:38 +0200

Ed Burns schrieb:
>>>>>> 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.
> 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
The view could be serialized 'on demand' by storing an unserialized
reference into the session but override 'writeObject()' and
'readObject()' in such way that regular serialization would make use of
'saveState()' and 'restoreState()' in case the container chooses to
serialize the view. (Which would happen in clustered scenario and if the
container supports swapping sessions to persistend storage for later
reuse). This way there would be no need for a config-parameter to
support cluster-failover.

Of course the spec would also have to be modified to allow this behavior.

- Norbert