Re: Serializing server state final thoughts

From: Adam Winer <>
Date: Thu, 13 Sep 2007 15:47:43 -0700

Norbert Truchsess said the following on 9/13/07 3:19 PM PT:
> 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.

Eh, unfortunately not. saveState() and restoreState() both
take a FacesContext, and therefore cannot be called at the time
of session failover, at least not without making significant
restrictions on what part of a FacesContext might be

-- Adam

> Of course the spec would also have to be modified to allow this behavior.
> - Norbert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: