5.6.1 Inhibiting the session failover functionality

If you enable the session failover functionality and receive requests for which an HTTP session is acquired, processing such as accessing a database, and serializing the HTTP session are executed. If the same session ID as the request for which an HTTP session is acquired is sent even for the requests related to the static contents or contents that do not require an HTTP session, the session failover functionality operates and performs unnecessary processing such as accessing a database or an EADs server or serializing the HTTP sessions.

If you set a URl pattern that inhibits the session failover functionality in a URI or an extension, the processing of the session failover functionality for the requests of the set URL patterns is inhibited. Hence, unnecessary processing does not occur and processing performance improves. Thus, if you have set the session failover functionality, the functionality which inhibits the session failover only for the specific URL patterns is called session failover inhibitionion functionality.

The following figure shows the differences in the executed processing when a session failover inhibitionion functionality is enabled or disabled with an example of the database session failover functionality.

Figure 5‒9: Differences in the processing when the session failover inhibition functionality is enabled or disabled (the database session failover functionality)

You can use the session failover inhibitionion functionality not only for improving performance but also for the following purposes:

The database session failover functionality when you enable the integrity mode, executes the exclusive processing for requests of the same session ID. For example, if you invoke a servlet or JSP, for which the processing continues for a long time, such as the servlet or JSP that you must make resident for performing the PUSH delivery, from one of the HTML frames, all the requests sent from the same frame are not executed until processing of that servlet or JSP is complete. This happens because all the requests sent from one frame are the requests that send the same session ID.

For preventing such situations, you must inhibit the session failover functionality for particular requests that do not use the HTTP session.

The following figure shows the differences in processing executed when you enable or disable the session failover inhibitionion functionality when using the database session failover functionality by enabling the integrity mode. Note that the request 1 and request 2 in the figure send the same session ID.

Figure 5‒10: Differences in the processing when the session failover inhibitionion functionality is enabled or disabled (the database session failover functionality)

You can set enabling or disabling of the session failover inhibitionion functionality in the J2EE server unit or Web application unit.

• Notes

  This subsection describes the precautions to be taken when using the session failover inhibitionion functionality.

  • If you invoke the getSession() method or getSession(boolean create) method in the javax.servlet.http.HttpServletRequest interface during a request processing for which the session failover inhibitionion functionality has disabled the session failover functionality, the com.hitachi.software.web.dbsfo.SessionOperationException exception is thrown. As a result, you cannot apply the session failover inhibition functionality for the requests that invoke this method.

    For details on the com.hitachi.software.web.dbsfo.SessionOperationException exception, see 3.1 Exception classes in the uCosminexus Application Server API Reference Guide.

  • As the requests for which the session failover inhibitionion functionality has disabled the session failover functionality are not the requests that use an HTTP session, the access time of the HTTP session is not updated. Impacts of the functionality are:

    The getLastAccessedTime() method in the javax.servlet.http.HttpSession interface returns the time of executing the request that used the previous HTTP session.

    If the difference between the current time and the access time of an HTTP session exceeds the timeout time, the HTTP session times out. As a result, after creating an HTTP session, if you continue sending only the requests for which the session failover functionality is disabled, the HTTP session might time out.

  • With JSP, an HTTP session is implicitly created by default. As a result, when applying the session failover inhibitionion functionality to JSP for which an HTTP session is not required, you must explicitly use session attributes of the page directive and set such that the HTTP session is not created.

  • If you use the FORM authentication as a login authentication functionality provided by the Web container, an HTTP session is implicitly created. If you use the FORM authentication in the requests for which the session failover inhibitionion functionality has disabled the session failover functionality, you cannot create an HTTP session. As a result, com.hitachi.software.web.dbsfo.SessionOperationException exception occurs and authentication is not performed. However, if you have already created a session, exception does not occur and authentication is performed even for a request for which the session failover inhibitionion functionality has disabled the session failover functionality.

To Page Top