How would SERIALIZE_STATE_IN_SESSION help?

On 9/28/06, Chris Pro <[EMAIL PROTECTED]> wrote:
Thanks for the reply!

I've just found the solution. I changed the SERIALIZE_STATE_IN_SESSION to "true". Before I got that parameter to "false". However, it's working now.    In addition I set the bean scope to request and use therefore "saveState" in the page. And because of I reload the data from the database on each each request I only need one View in the Session.

        <context-param>
                <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
                <param-value>server</param-value>
        </context-param>
        <!-- disable compression of state in server -->
        <context-param>
                <param-name>org.apache.myfaces.COMPRESS_STATE_IN_SESSION</param-name>
                <param-value>true</param-value>
        </context-param>
        <!-- Very important, too, is to disable the serialization of state,
          serialization and deserialization of the component tree is a major performance hit. -->
        <context-param>
                <param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
                <param-value>true</param-value>
        </context-param>
        <!-- If you find that memory is a constraining factor, then reducing the number of views stored in the session might help -->
        <context-param>
            <param-name>org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION </param-name>
            <param-value>1</param-value>
        </context-param>


-------- Original-Nachricht --------
Datum: Wed, 27 Sep 2006 11:20:35 -0400
Von: "Kevin Galligan" < [EMAIL PROTECTED]>
An: "MyFaces Discussion" <users@myfaces.apache.org>
Betreff: Re: commandLink and back button

> I think the problem has more to do with the managed bean hanging out in
> the
> session.  In my personal experience, since the session was first
> "invented",
> way before JSF came around, the session has been a horrible place to put
> anything except the user's login info.  If you're keeping state on the
> server, it will hold onto many sequential view states, even for the same
> page.  If you're going to need a lot, consider bumping up the '
> org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION' value.
>
> state #1 - with command link A
> state #2 - without
>
> I'm guessing you've got a situation where the managed bean is in state #2,
> but you're clicking command link A from a page that looks like its in
> state
> #1.  If things are set up correctly and you're using a recent myfaces
> build,
> I *believe* the JSF view will be in the correct state, but I'm sure your
> managed bean is in a bad way because its a session variable.
>
> I would suggest the following as a possible solution.  Call t:saveState
> and
> keep your bean in the request scope.  You can explicitly control your
> bean's
> state...
>
> http://myfaces.apache.org/tomahawk/uiSaveState.html
>
> Somewhere it states you can also implement "StateHolder" interface to
> explicitly control state for the whole bean instead of simply implementing
> serializable.  However, I think currently you'd need to build tomahawk by
> hand as the fix for this was very recent.
>
> I do remember the view state on the server being pretty brittle with the
> back button when I started with JSF, and i used client state for a long
> time.  However, it seems to be handled better now.  Make sure you have a
> recent version.
>
> On 9/27/06, Jeff Bischoff <[EMAIL PROTECTED]> wrote:
> >
> > I don't think that what you are trying to do with the browser back
> > button is supported through server-side state saving and session beans.
> > The "problem" you are having actually sounds like the correct behaviour
> > for these settings. You may consider client-side state, t:saveState, or
> > some other approach. These links may get you started:
> >
> > [1] http://wiki.apache.org/myfaces/How_JSF_State_Management_Works
> > [2] http://wiki.apache.org/myfaces/SaveState
> > [3]
> >
> >
> http://bugs.sakaiproject.org/confluence/pages/viewpage.action?pageId=4981&showComments=true
> >
> > Regards,
> >
> > Jeff Bischoff
> > Kenneth L Kurz & Associates, Inc.
> >
> > Chris Pro wrote:
> > > Hi
> > >
> > > I've got a problem with the browser back button.
> > > The "detai.jsf" got several commandLinks. One of them is showing "
> > detai.jsf" again, with another product. In some case the commandLink A
> > isn't rendered. If
> > > the back button is pressed, the page before with the commandLink is
> > shown. But when I click on that commandLink the action is not invoked?
> > > I've got the same problem with the dataTable. There I was able to
> > eliminate that back button problem with preserveDataModel="true". But
> for a
> > normal
> > > commandLink (t:commandLink or h:commandLink) there isn't a method like
> > that, or?
> > >
> > > In other words:
> > > 1. detail.jsf (with commandLink A) -> detail.jsf (without commandLink
> A)
> > > 2. backButton to the first detail.jsf (with commandLink A)
> > > 3. Click on commandLink A -> nothing happens. It looks like the action
> > is disappeared!?
> > >
> > > Some more information:
> > > -STATE_SAVING_METHOD = Server
> > > -Managed-Bean = Session
> > >
> > >
> > > Could some please give me a hint to resolve that problem?
> > >
> > > Thanks a lot!
> >
> >
> >

--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Reply via email to