AFAIK only t:savestate may be an issue if you use a bean which
maintains a state for a view. this state would be shared among the
views if a user opens a new browser window. If the state of this bean
is changed for one window it will also change (same state) for the
other window which still has the old state. The next request for the
window will probably fail because the state of the bean has been
changed in meantime.

But I think there is a solution for this problem. Your bean could
provide a getter method which returns an object with the state (like
an object array containing the field values of the bean):

public Object getState()
{
 Object[] state = new Object[2];
 state[0] = field1;
 state[1] = field2;
 return state;
}

and a setter method which writes the state back to the bean:

public void setState(Object value)
{
 Object[] state = (Object[])value;
 field1 = state[0];
 field2 = state[1];
}

you can then use <t:savestate value="#{bean.state}"/> in your view. Of
course if your fields are mutable objects you have to make sure either
these objects are never modified or you save the state of these
objects too.

This will probably the most effective way since serializing through
ObjectOutputStream/ObjectInputStream is definitely a performance
killer.

One more thing. I have removed the gzipping of the serialized stream
if server side state is used. This might have caused some additional
performance problems. Would it be possible to take the next nightly
(20051103) and test it again with
org.apache.myfaces.SERIALIZE_STATE_IN_SESSION=true to check this?

>  We are using t:saveStates in our application, and I'm not sure if
> SERIALIZE_STATE_IN_SESSION had effect when I tried to update-operation of
> same pojo (pojo moved between pages with t:saveState) in two different
> views, sometimes hibernate gave nicely announcement (with later update
> operation) that data is stale and sometimes not, but it could also be some
> caching issue or something - must be checked later..
>  Can you please give me an example when I can expect some issues with
> SERIALIZE_STATE_IN_SESSION=false ?

--
Mathias

Reply via email to