6.4.5 Locking global session information (when integrity mode is enabled)
This subsection describes locking of global session information executed only when integrity mode is enabled. The operation is not executed when integrity mode is disabled.
With a system in which a J2EE server is replicated, requests having the same session ID might be concurrently sent to a different J2EE server. For example, if you access a page of frame structure or a page containing multiple images (image tag), browser functionality sends requests to the servers with multi-threads.
If information of the same global session is updated on different J2EE servers, the integrity of global session information is lost. As a result, with the database session failover functionality, acquire and control the exclusion of records, in which global session information under updating are stored, so that the records cannot be used on another server. This processing of acquiring exclusion is called locking of global session information. The processing of releasing the exclusion is called releasing lock.
The following figure shows locking of global session information by performing record exclusion.
|
|
![[Figure]](GRAPHICS/ZU060300.GIF)
This subsection describes the processing executed when locking global session information by performing record exclusion. Sr. No. corresponds to the numbers in the figure.
-
On receiving a request from the client, global session information in the database is locked.
-
Web application processing is executed after locking.
-
Global session information is unlocked when the processing of a Web application is complete.
Thus, the global session information in the database is locked during the Web application operation and this assures that requests having the same session ID in the system do not process concurrently.
When a request is sent to a J2EE server, global session information is locked irrespective of whether the HTTP session is to be used in the Web application. However, global session information is not locked for the following requests:
-
Requests for which an HTTP session is not created
-
Requests having URL containing extensions or URIs that have inhibited the database session failover functionality
By default, txt, htm, html, jpg, gif, and js are the extensions targeted for inhibiting. There are no URIs to be inhibited by default. For details on inhibiting the database session failover functionality, see 5.6.1 Inhibiting the session failover functionality.
With the database session failover functionality, the lock of global session is enabled also between the threads sent to one J2EE server and not to different J2EE servers. If you send multiple requests having the same session ID to one J2EE server, requests are processed one by one in the order of receiving. Processing of a request received later starts after waiting for completion of processing of the request sent earlier.
- Important note
-
A Web client might send multiple requests having the same session ID because contents that use frames and combine multiple dynamic pages that use HTTP sessions are updated. In this case, requests are processed one by one in the order of receiving. As a result, processing performance might degrade compared with the case of not using the database session failover functionality.
- Organization of this subsection
(1) Result of invoking lock acquisition processing when acquiring a lock
The result of invoking lock acquisition processing varies depending on the state of global session information in the database. The following table describes the relation between global session information state and the result of invoking lock acquisition processing.
|
Sr. No. |
State of global session information in the database |
Result of invoking lock acquisition processing |
Output message |
|---|---|---|---|
|
1 |
Exists and not locked (in normal cases). |
Global session information in the database is locked (ends successfully). |
Not output |
|
2 |
Does not exist. |
It is determined that a session disabled due to timeout or a session having invalid session ID is targeted. Hence, HTTP session in the J2EE server is deleted. As a result, a Web application is executed in the state of not having an HTTP session. |
KDJE34315-W |
|
3 |
Session exists, but it is updated on another J2EE server and is newer than the information of the HTTP session on the J2EE server. |
It is determined that it is global session information used on another J2EE server. Hence, the contents of global session information in the database are inherited (inheriting a session#1 occurs). |
KDJE34322-I#2 |
|
4 |
Exists and locked because it is being used. |
Waiting for lock #3 occurs. A lock is acquired after processing of the request that uses an HTTP session ends and the Web application starts. |
Not output |
- #1
-
For details on inheriting a session, see 6.4.2 (4) Inheriting session information that uses global session information.
- #2
-
Output at Warning level.
- #3
-
For details on waiting for lock, see (2) Waiting for lock.
(2) Waiting for lock
If you receive a request that uses an HTTP session in a global session that is targeted for locking, you must wait for acquiring the lock. The state of waiting for acquiring a lock is called waiting for lock in global session information. The timeout that results because of waiting for a lock is called a lock timeout.
The following table describes the relation between global session information states after waiting for a lock occurs and as a result of invoking lock acquisition processing.
|
Sr. No. |
State of global session information after waiting for lock occurs |
Result of invoking lock acquisition processing after waiting for lock occurs |
Output message |
|---|---|---|---|
|
1 |
Request processing, which was using the session earlier, ends and the lock is released. |
Global session information in the database is locked (ends successfully). |
Not output |
|
2 |
Timeout time elapsed, but the lock is not released (lock timeout occurred)#1. |
When session acquisition processing is executed in a Web application, com.hitachi.software.web.dbsfo.DatabaseAccessException#2 is thrown. |
KDJE34312-W |
|
3 |
A failure occurred in the database while waiting for lock and lock is not released. (lock timeout occurred). |
When session acquisition processing is executed in a Web application, com.hitachi.software.web.dbsfo.DatabaseAccessException#2 is thrown. |
KDJE34312-W |
- #1
-
This state includes the case when an SQL statement used for locking is sent to the database and a timeout occurs due to a failure in the communication path.
- #2
-
The DatabaseAccessException class inherits the java.lang.IllegalStateException class. For details on the DatabaseAccessException class, see 3.1 Exception classes in the uCosminexus Application Server API Reference Guide.
(3) Locking global session information when a failure occurs on a J2EE server
If an OS hangs or a network failure occurs on a J2EE server, on which a Web application is running, the global session information, which is locked in the database, might be temporarily locked.
For recovering the session information from the locked state, you need to take one of the following measures:
-
Perform settings in the database for monitoring connections from a client and recovering by detecting disconnection.
If you perform these settings, the database functionality detects disconnection from a J2EE server and automatically releases the lock after a certain period of time. Also, the state is returned to the state before acquiring the lock when a disconnection is detected. If you use HiRDB, set the functionality for monitoring UAP processing time. For details on the functionality for monitoring UAP processing time, see the HiRDB UAP Development Guide.
-
Perform regular maintenance of the database.
For details on setup and operation of a database, see the manual of the database used.