5 Replies Latest reply: May 9, 2012 3:52 AM by 773812 RSS

    ADF server-side state saving method

      Hi all,

      As far as I know, ADF has three view state saving methods.

      1. client - tokens
      2. client - all
      3. server

      My question is about server-side state saving.
      If I set state saving methos "server" in web.xml, view state is stored in session scope as LRU map.
      And the size of the map can be configured with below parameters in web.xml.


      However I think these parameters is offered by Mojarra (Sun's JSF RI) and any ADF guides don't mention them.
      These parameters are supported in ADF?

        • 1. Re: ADF server-side state saving method
          Hi all,
          Any comment on this?
          Any help will be much appreciated.

          • 2. Re: ADF server-side state saving method
            you can try the trinidad options which will surely work
            and I guess even the sun's param that you have provide should work if the jsf implementation is based on the same frame
            or this also
            • 3. Re: ADF server-side state saving method

              Thank you for your reply.
              I already tested the parameter you suggested "org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION", but it doesn't seem to work in my environment.

              My environment:
              WebLogic 10.3.5

              When I set state saving method "server", these sun's parameters seem to work correctly.
              However my customer needs to make sure that they are supported in ADF before adopting them because state saving method has a very huge impact for heap size setting and machine capacity planning or so.

              My customer's application opens many windows and we need to find better state saving setting to keep them alive and avoid ViewExpiredException.

              • 4. Re: ADF server-side state saving method
                Frank Nimphius-Oracle

                don't have a support statement for this but would be surprised if we don't as ADF Faces runs on top of the JSF RI.

                However, I am wondering why your customer prefers state saving being handled on the server as it doesn't allow fail over for your application setup. Also it is the recommended option


                +"Context parameter javax.faces.STATE_SAVING_METHOD: Specifies where to store the application's view state. By default this value is server, which stores the application's view state on the server. *It is recommended that you set javax.faces.STATE_SAVING_METHOD to client* when you use ADF Faces, to store the view state on the browser client. When set to client, ADF Faces then automatically uses token-based, client-side state saving. *You can specify the number of tokens to use instead of using the default number of 15*.+

                +You can specify the following state-saving context parameters:+

                +org.apache.myfaces.trinidad.CLIENT_STATE_METHOD: Specifies the type of client-side state saving to use when client-side state saving is enabled by using javax.faces.STATE_SAVING_METHOD. The values for CLIENT_STATE_METHOD are:+

                +token: (Default) Stores the page state in the session, but persists a token to the client. The simple token, which identifies a block of state stored back on the HttpSession object, is stored on the client. This enables ADF Faces to disambiguate the same page appearing multiple times. Failover is supported.+
                +all: Stores all state information on the client in a (potentially large) hidden form field. It is useful for developers who do not want to use HttpSession.+

                +*Performance Tip:*+
                +Because of the potential size of storing all state information, it is recommended that you set client-state saving to token.+

                +*org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS*: Specifies how many tokens should be stored at any one time per user, when token-based client-side state saving is enabled. The default is 15. When the number of tokens is exceeded, the state is lost for the least recently viewed pages, which affects users who actively use the Back button or who have multiple windows opened at the same time. If you are building HTML applications that rely heavily on frames, you would want to increase this value.+

                +*org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE*: Specifies whether or not to globally compress state saving on the session. Each user session can have multiple pageState objects that heavily consume live memory and thereby impact performance. This overhead can become a much bigger issue in clustering when session replication occurs. The default is off.+

                +org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE: Enables the Application View Cache (AVC), which can improve scalability by caching the state for the initial renders of the page's UI at an application scope. However, every page in the application must by analyzed for support in the AVC to avoid potential problems with debugging in an unexpected state and information leakage between users. Additionally, development is more difficult since page updates are not noticed until the server is restarted, and although initial render performance is enhanced, session size is not.+

                +The Application View Cache is not supported for this release. The feature does not work for any page where the rendering of the component tree causes the structure of the component tree to change temporarily. Since this is often the case, USE_APPLICATION_VIEW_CACHE should not be used."+

                So unless your customer has a good reason for server side state I would suggest him/her to go with best practices

                • 5. Re: ADF server-side state saving method

                  Thank you for your reply.
                  As you suggested, I know that ADF recommends "client-token" based state saving.
                  However they adopted the design using many windows, which tends to cause viewExpiredException.

                  In case where we use "client-token" method, view states are stored in session as one map object.
                  However if we use "server" state saving, they are stored per logical view (≒window) in map and managed separately.
                  So viewExpiredException unlikely to occur compared to "client-token" and they can lessen saving size that relates to heap consumption.
                  This is the reason they try to use "server" state saving.

                  Anyway I need to tell them that server-side state saving has some restrictions, for example not supporting fail over.