Migrate HTTP sessions

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

Migrate from Version 4
No programmatic changes are required to migrate from Version 4 to Version 5.

Migrate 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 Version 5, 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 behavior as needed. In accordance with the Servlet 2.3 specification, HttpSession objects must be scoped within a single Web application context; they may not be shared between contexts. This means that a session can no longer span Web applications. Objects added to a session by a servlet or JSP in one Web application cannot be accessed from another Web application. The same session ID may be shared (because the same cookie is in use), but each Web application has 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 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	application server	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 occurs, the sessions associated with the Web application are maintained in the persistent store and are available after the reload.