5.5.1 Overview of the database session failover functionality

(1) Procedure for storing the session information

If you use the database session failover functionality and a session creation processing is generated by a request, the processing is extended and the session information is stored in a database.

The following figure shows the flow of storing session information.

Figure 5‒5: Flow of storing session information (the database session failover functionality)

No. corresponds to the numbers in the figure.

1. If the Web server receives a request requiring the creation of a session, from the client, a session is created on the J2EE server.

2. The session information is created for the session.

3. The session information is stored in the database.

If a failure occurs in the Web server 1 or J2EE server 1, the session information stored in the database is inherited by the web server 2 or J2EE server 2, and you can continue the operations in the state before failure.

To Page Top

(2) Flow of processing when a failure occurs on a Web server or a J2EE server

If a failure occurs on a Web server or a J2EE server, you can re-create a session on another J2EE server based on the session information stored in the database and continue the normal operations.

The following figure shows the flow of processing when a failure occurs on a Web server or a J2EE server:

Figure 5‒6: Flow of processing when a failure occurs on a Web server or a J2EE server (the database session failover functionality)

1. If a failure occurs on the Web server 1, the load balancer transfers the request to the Web server 2.

2. Because the session associated with the request does not exist when processing the request on the J2EE server at the transfer destination, it inherits the session information from the database.

3. The session is re-created.

The session is successfully inherited and you can continue operations in the state before failure.

When you restart the J2EE server 1 and Web server 1 recovering from failure, the requests are again sent to the Web server 1.

To Page Top

(3) Flow of processing when a failure occurs in a database

If a failure occurs in a database, you can continue operations by operating only the session information on the J2EE server. When the database recovers from the failure and you can access the database in session operations after that, the functionality updates the database with the session information operated on the J2EE server.

As a result, the client can continue operations without recognizing the database failure.

To Page Top

(4) Operation mode of the database session failover functionality

If multiple requests with the same session ID for the global session information that is stored in the database are concurrently sent, you can concurrently process multiple requests by default. Thus, you can control the degradation of the processing performance caused by the use of the database session failover functionality.

However, a prerequisite of this operation is that processing such as concurrently updating global session information of the same session ID from multiple replicated J2EE servers should not occur. If global session information with the same session ID is updated from multiple J2EE servers, consistency of global session information might be lost. You must enable a mode for maintaining consistency of global session information in the systems in which such cases cannot be allowed.

The mode that maintains consistency of global session information is called Integrity mode. If you enable this mode, a lock is set to the database whenever you update a global session. If multiple requests with the same session ID are concurrently sent, the requests are serially processed and the global session information does not become inconsistent. However, request processing performance might be affected because multiple requests cannot be concurrently executed and the lock set up and release processing occurs whenever global session information is stored.

As a result, when using the database session failover functionality, you need to examine the mode to perform the operations depending on the purpose and characteristics of the system.

The following table describes the main differences depending on enabling or disabling the integrity mode.

Table 5‒5: Main differences depending on enabling or disabling the integrity mode

Items to be compared	Integrity mode
	Disabled	Enabled
Characteristics of the appropriate system	Suitable for a system in which performance is highly important.	Suitable for a system in which assured inheriting of session information is required even if performance reduces.
Request processing performance	Performance is excellent because you can concurrently process multiple requests with the same session ID.	Performance degrades because it is necessary to serially process the requests.
Integrity of global session information	Integrity is not maintained if you concurrently update global session information with the same session ID.	Maintains the integrity.
Behavior when a failure occurs in the database	Uses session information on the J2EE server and continues the processing (reduced operations of the database session failover functionality).	Outputs an error message and stops the processing.

The following figure shows the flow of request processing in each mode:

Figure 5‒7: Flow of request processing when the integrity mode is disabled (default setting)

If integrity mode is disabled, a database lock is acquired and released when creating global session information in the database by extending HTTP session creation processing. However, a lock is not acquired with session acquisition processing after you commit once. The database lock acquisition processing and release processing are not executed with the subsequent update processing of global session information.

Figure 5‒8: Flow of request processing when an integrity mode is enabled

If an integrity mode is enabled, a database lock is acquired and released when creating global session information in the database by extending the HTTP session creation processing. In addition, a lock is acquired again in session acquisition processing after you commit once. Thus, even if a failure occurs on a J2EE server or in a database during execution of a Web application after creating the HTTP session, inconsistency does not occur in the database processing. With the subsequent update processing of global session information, the processing is implemented for acquiring a database lock whenever updating the global session informaiton and unlocking after the updation is complete.

For details on the operations when locking global session information, see 6.4.5(1) Result of invoking lock acquisition processing when acquiring a lock.

The functionality that you can use vary depending on whether the setting of an integrity mode is enabled or disabled.

To Page Top