Migrating HTTP sessions

Note that In Version 5 default write frequency mode is TIME_BASED_WRITES, which is different from Version 4.0 and 3.5 default mode of END_OF_SERVICE.

Migrating from Version 4.0

No programmatic changes are required to migrate from version 4.0 to version 5.

Migrating from Version 3.5

If you have Version 3.5 applications running in Servlet 2.1 mode, some of the following Version 5 differences might influence how you choose to track and manage sessions.

  1. During application development, modify session-related APIs as needed.

    Some API changes are required in order to redeploy existing applications on Version 5. These include changes to the HttpSession API itself as well as issues associated with moving to support for the Servlet 2.3 specification. Certain Servlet 2.1 API methods have been deprecated in Servlet 2.3 API . These deprecated APIs still work in V5, but they may be removed in a future version of the API. Changes are summarized in the following list...

    • Replace instances of getValue() with getAttribute()

    • Replace instances of getValueNames() with getAttributeNames()

    • Replace instances of removeValue() with removeAttribute()

    • Replace instances of putValue() with setAttribute()

  2. During application development, modify web application (.war) behavior as needed.

    In accordance with the Servlet 2.3 specification, HttpSession objects must be scoped within a single web application (.war) context; they may not be shared between contexts. This means that a session can no longer span web application (.war)s. Objects added to a session by a servlet or JSP in one web application (.war) cannot be accessed from another Webapplication. The same session ID may be shared (because the same cookie is in use), but each web application (.war) will have a unique session associated with the session ID. Version 5 provides a feature that can be used to extend scope of a session to enterprise application.

  3. Use administrative tools to configure Session Manager security settings as needed.Relative to session security, the default Session Manager setting for Integrate Security is now false. This is different from the default setting in some earlier releases.

  4. Use administrative tools to configure the JSP enabler and application server as needed.

    In Version 3.5 of the product, JSP files that contained the usebean tag with scope set to session did not always work properly when session persistence was enabled. Specifically, the JSP writer needed to write a scriplet to explicitly set the attribute (that is, to call setAttribute()) if it was changed as part of JSP processing.

    Two new features in Version 5.0 help address this problem:

    • Set dosetattribute to true on the JSP InitParameter.

    • Set the Write Contents option to Write all.

    The differences between the two solutions are summarized in the following table:

    Applies to Configured at Action
    dosetattribute set to true JSP JSP enabler Assures that JSP session-scoped beans always call setAttribute()
    Write Contents option set to Write all servlet or JSP appserver All session data (changed or unchanged) is written to the external location

    If session persistence is enabled and a class reload for the web application (.war) occurs, the sessions associated with the Webapplication are maintained in the persistent store and will be available after the reload.

 

See Also

Assembling so that session data can be shared