5.4.2 Prerequisite settings
This subsection describes the prerequisite settings for using the session failover functionality.
- Organization of this subsection
(1) Common prerequisite settings of the session failover functionality
The following settings are required when using the database session failover functionality.
-
Adding a server ID to a session ID by using the server ID addition functionality of HttpSession
This functionality adds a server ID to a session ID of HTTPSession. This functionality must be enabled if you want to use the database session failover functionality (disabling integrity mode). Set different server IDs for each replicated J2EE server.
If you disable the server ID addition functionality of HttpSession, the KDJE34371-E or KDJE34404-E error message is output to the message log when starting the Web application, and the Web application fails to start. If you do not set a different server ID for each replicated J2EE server, global session information might be inherited on an unintended J2EE server and the integrity of global session information might be lost.
For details on the functionality of adding server ID to session ID of HttpSession, see 2.7.6 Adding server ID to session ID and Cookie in the uCosminexus Application Server Web Container Functionality Guide.
-
Setting sticky of an HTTP session
To use the session failover functionality in the environment used by the load balancer, you must set sticky for the HTTP session.
If you do not set sticky for the HTTP session, distribution destination of the requests that retain HTTP session is not fixed. As a result, an HTTP session is inherited every time you receive a request that retains an HTTP session, and this might result in the performance deterioration.
-
Setting the host time
For using the session failover functionality, set the same time on each host, on which the J2EE servers in the system run.
Information such as the creation time and last access time of an HTTP session is included in the session information to be stored in a database. If the time set on each host is different, the information that is different from the setting time of local host is included in the session information. As a result, if you inherit a session, problems might occur when controlling the HTTP session.
(2) Prerequisite settings of the database session failover functionality
The following settings are required when using the database session failover functionality.
-
Deleting invalid session IDs retained by the Web client
This functionality deletes the information of HTTP Cookie, which is retained in the Web client when disabling an HTTP session, and inhibits sending of a session ID to disabled HTTP sessions. For using the database session failover functionality, you must enable this functionality.
If you have disabled deletion of HTTP Cookie that indicates the session ID of an HTTP session, the KDJE34339-E error message is output to the message log when starting a Web application, and the Web application fails to start. For details on deleting HTTP Cookie that indicates the session ID of an HTTP session, see 2.7.4 Deleting invalid session IDs retained by a Web client in the uCosminexus Application Server Web Container Functionality Guide.
-
Specifying the upper limit of the number of HttpSession objects
This functionality sets the upper limit of the number of a valid HttpSession object. Set this functionality when enabling the integrity mode.
If you have set to cancel the Web application start process in the case of failure in the negotiation processing that is executed when an application starts a, you must set a valid value (1 or above) as an upper limit If you have not specified the upper limit of the number of HttpSession objects, the KDJE34303-E error message is output to the message log when starting an application, and the application fails to start.
However, if you have set to continue the Web application start process in the case of failure in the negotiation process, setting the upper limit of the number of HttpSession objects is optional. You can also specify -1 (unlimited) as the upper limit. If you set -1 (unlimited) as the upper limit of the number of HTTPSession objects or if you specify a value greater than the number of records in the session information storage table of the database, the operation performed when the number of HttpSession objects exceeds the number of records in the session information storage table is as follows:
- When an integrity mode is disabled (optional)
-
The corresponding HTTP sessions reduce and request processing continues.
- When an integrity mode is enabled
-
The KDJE34380-E error message is output to the message log and corresponding HTTP session is not created.
For details on settings of the upper limit of the number of HttpSession objects, see 2.7.5 Setting upper limit of the number of HttpSession objects in the uCosminexus Application Server Web Container Functionality Guide.
For details on negotiation processing, see 6.4.1 Processing when starting an application.
For details on integrity mode, see 5.5.1(4) Operation mode of the database session failover functionality.
For details on reduction of HTTP sessions when an integrity mode is disabled, see 5.7.3 Reducing an HTTP session.
-
Setting default pending queues and pending queues in the Web application unit, and pending queues in the URL group unit
If the functionality for controlling the number of concurrently executed threads in an Web application unit is enabled, and if vacancies in the default pending queue, pending queues in the Web application unit, and pending queues in the URL group unit become insufficient, specify whether the 503 error is to be returned to the client, in the webserver.dbsfo.thread_control_queue.enabled parameter in the Easy Setup definition file. Note that by default the 503 error is returned to the client.
If you set not to return the 503 error to client, set a sufficiently large value in the pending queue size.
If you set to return the 503 error to client, do not perform the following HTTP session updates on the error page specified in web.xml.
-
Creating an HTTP session
If the Web application creates an HTTP session, the com.hitachi.software.web.dbsfo.SessionOperationException exception is thrown at the invocation source of the getSession method in the javax.servlet.http.HttpServletRequest interface and an HTTP session is not created.
-
Changing the expiration date of an HTTP session (invoking the setMaxInactiveInterval method in the javax.servlet.http.HttpSession interface)
If the Web application changes the expiration date of an HTTP session, the expiration date of the global session on the database does not change. If the global session is inherited, the expiration date returns to the state before change.
-
Changing the attribute information of the HTTP session
If the Web application changes the HTTP session attribute information, the global session information on the database does not change. If the global session is inherited, the attribute information returns to the state before change.
-
Disabling an HTTP session (invoking the invalidate method in the javax.servlet.http.HttpSession interface)
If theWweb application invokes the invalidate method in the javax.servlet.http.HttpSession interface, the com.hitachi.software.web.dbsfo.SessionOperationException exception is thrown.
-
-
The user-specified namespace functionality
When using the database session failover functionality, the system considers that the look up of J2EE resources in optional names that are given by using the user-specified name space functionality, is already performed.
Hence, if you have specified the following parameter in the properties of the J2EE server and are using the round-robin search functionality, you cannot use the database session failover functionality.
java.naming.factory.initial=com.hitachi.software.ejb.jndi.GroupContextFactory
If you have specified this parameter, the KDJE34305-E error message is output to the message log when starting a Web application, and the Web application fails to start.
If round-robin search is required in the J2EE application to be operated on the J2EE server, do not specify the classes delegated to implement the InitialContextFactory, in the properties of the J2EE server. You must specify the classes in an argument when generating InitialContext for each application. For details on the round-robin search functionality, see2.7 Searching CORBA naming services by using round-robin policy in the uCosminexus Application Server Common Container Functionality Guide.