The functionality for defining refer-only requests in HTTP session sets the URL patterns of the requests that are only to be referenced and not to be updated (refer-only requests), and thus deters the serialization of HTTP sessions or access to the database or EADs server, for requests of those URL patterns.

You can use this functionality when you disable the database session failover functionality and in the case of the EADs session failover functionality.

The following figure shows the flow of processing when you define refer-only requests for using the EADs session failover functionality. In the case of the database session failover functionality, the global session information storage destination in the figure changes to the session information storage table in the database.

Figure 5-14 Processing of refer-only requests (the EADs session failover functionality)

With processing of refer-only requests, a response is returned after executing a Web application that refers to the session. Processing of the global session information updation that is executed in the case of the requests that update the HTTP session, indicated by the dotted line arrows in the figure is not executed.

Note that you can use the session failover inhibition functionality in the case of the requests, which not only update but also not refer to the HTTP session. The requests corresponding to both the refer-only requests and the requests targeted for session failover inhibition functionality, processing are executed as the requests targeted for the session failover inhibitionion functionality. For details on the session failover inhibitionion functionality, see 5.6.1 Inhibiting the session failover functionality.

You can set the functionality of defining refer-only requests of an HTTP session in the J2EE server unit or Web application unit.

For details on the settings in the J2EE server unit in the case of the database session failover functionality, see 6.6 J2EE server settings.

For details on the settings in the J2EE server unit in the case of the EADs session failover functionality, see 7.5 J2EE server settings and for details on settings in the Web application unit, see 7.4 Definitions in cosminexus.xml.

Notes

This subsection describes the precautions to be taken when defining refer-only requests of an HTTP session.

• You cannot disable an HTTP session with a refer-only request. If you invoke the invalidate() method in the javax.servlet.http.HttpSession interface that disables an HTTP session with a refer-only request, com.hitachi.software.web.dbsfo.SessionOperationException exception or com.hitachi.software.web.eadssfo.SessionOperationException exception is thrown in a Web application.
• Even in the case of refer-only requests, for the first request for which an HTTP session does not exist, an HTTP session is created, updated, and deleted. At that time, the global session information in the database or on the EADs server is also updated.
  For the second and subsequent requests for which an HTTP session does not exist, the global session information in the database or on the EADs sever is not updated even if the Web application updates the HTTP session. As a result, when inheriting the global session, attribute information of the HTTP session returns to the state before update.
  
• If you change the expiration date of an HTTP session (invoking the setMaxInactiveInterval() method in the javax.servlet.http.HttpSession interface) in refer-only request processing, an expiration date of a global session does not change. As a result, when inheriting the global session, the expiration date of the session returns to the state before change.
• If you change the attribute information of an HTTP session in refer-only request processing, global session information does not change. As a result, when inheriting the global session, attribute information of the HTTP session returns to the state before change. Changes refer to the following changes in attribute information:
  
  • Registering a new attribute information in an HTTP session or replacing the registered session attributes by using the setAttribute() method or the putValue() method in the javax.servlet.http.HttpSession interface.
  • Deleting the attribute information registered in an HTTP session by using the removeAttribute() method or the removeValue() method in the javax.servlet.http.HttpSession interface.
  • Changing the contents of attribute information registered in an HTTP session.
  The following is an example of changing the contents of attribute information of a session:
  

  java.util.Hashtable table = (java.util.Hashtable)session.getAttribute("attr1"); table.put("key1", "value1");

  In this example, session is a variable that stores HttpSession objects. The java.util.Hashtable object is registered as attribute information of a session in HttpSession objects with the attr1 name in another request.