Hitachi

Cosminexus V11 アプリケーションサーバ 機能解説 拡張編


6.4.5 グローバルセッション情報のロック(完全性保障モードが有効の場合)

ここでは,完全性保障モードが有効の場合にだけ実行されるグローバルセッション情報のロックについて説明します。完全性保障モードが無効の場合は実施されません。

J2EEサーバを冗長化したシステムでは,異なるJ2EEサーバに対して,同じセッションIDを持つリクエストが同時に送信される場合があります。例えば,フレーム構造のページや,複数の画像(imageタグ)を含むページなどへのアクセスが発生した場合,ブラウザの機能によってマルチスレッドでサーバに対してリクエストが送信されます。

異なるJ2EEサーバで同じグローバルセッションの情報が更新されると,グローバルセッション情報の完全性が失われてしまいます。そのため,データベースセッションフェイルオーバ機能では,ほかのサーバで使用できないように,更新中のグローバルセッション情報が格納されているレコードの排他を取得し,制御します。この排他の取得処理をグローバルセッション情報のロックと呼びます。また,排他を解除する処理をロックの解除と呼びます。

レコードの排他によるグローバルセッション情報のロックについて,次の図に示します。

図6‒7 レコードの排他によるグローバルセッション情報のロック

[図データ]

レコードの排他によるグローバルセッション情報のロックで実行される処理について説明します。項番は図中の番号に対応しています。

  1. クライアントからリクエストを受け取ると,データベース上のグローバルセッション情報がロックされます。

  2. ロック後に,Webアプリケーションの処理が実行されます。

  3. Webアプリケーションの処理が完了すると,グローバルセッション情報のロックが解除されます。

このように,Webアプリケーションの動作中,データベース上のグローバルセッション情報はロックされているため,システム内で同じセッションIDを持つリクエストが同時に処理されないことが保証されます。

J2EEサーバにリクエストが送信された場合,Webアプリケーション内でHTTPセッションを使用するかどうかに関係なく,グローバルセッション情報がロックされます。ただし,次のリクエストに対しては,グローバルセッション情報はロックされません。

データベースセッションフェイルオーバ機能では,異なるJ2EEサーバではなく,一つのJ2EEサーバに対して送信されるスレッド間でもグローバルセッションのロックは有効です。セッションIDが同一である複数のリクエストが一つのJ2EEサーバに送信された場合,受信したリクエストから順に一つずつ処理されます。あとで受信したリクエストは,先に受信したリクエストの処理が終わるのを待ってから,処理を開始します。

注意事項

フレームなどを使用した,HTTPセッションを使用する複数の動的ページを組み合わせたコンテンツの更新などによって,WebクライアントからセッションIDが同一である複数のリクエストが送信される場合があります。この場合,受信したリクエストから順に一つずつ処理されます。その結果,データベースセッションフェイルオーバ機能を使用しない場合に比べ,処理性能が低下するおそれがあります。

〈この項の構成〉

(1) ロック取得時のロック取得処理の呼び出し結果

データベース上のグローバルセッション情報の状態によってロック取得処理の呼び出し結果が異なります。グローバルセッション情報の状態とロック取得処理の呼び出し結果の関係を次の表に示します。

表6‒14 グローバルセッション情報の状態とロック取得処理の呼び出し結果の関係

項番

データベース上のグローバルセッション情報の状態

ロック取得処理の呼び出し結果

出力されるメッセージ

1

存在し,ロック中ではない(正常時)。

データベース上のグローバルセッション情報がロックされます(正常終了)。

出力されない

2

存在しない。

タイムアウトで無効化したセッション,または無効なセッションIDのセッションを対象にしていると判断されます。そのため,J2EEサーバ内のHTTPセッションが削除されます。

その結果,Webアプリケーションは,HTTPセッションが存在しない状態で実行されます。

KDJE34315-W

3

存在するが,ほかのJ2EEサーバで更新され,J2EEサーバ内のHTTPセッションの情報よりも新しい。

ほかのJ2EEサーバで使用されたグローバルセッション情報であると判断されます。そのため,データベース上のグローバルセッション情報の内容が引き継がれます(セッションの引き継ぎ※1発生)。

KDJE34322-I※2

4

存在し,使用されているためロック中である。

ロック待ち※3が発生します。HTTPセッション使用中のリクエストの処理が終了したあとでロックが取得され,Webアプリケーションが開始されます。

出力されない

注※1

セッションの引き継ぎについては「6.4.2(4) グローバルセッション情報を使用したセッション情報の引き継ぎ」を参照してください。

注※2

Warningレベルで出力されます。

注※3

ロック待ちについては「6.4.5(2) ロック待ち」を参照してください。

(2) ロック待ち

ロック対象となっているグローバルセッション中のHTTPセッションを使用するリクエストを受信すると,ロックの取得を待つ必要があります。ロックの取得を待っている状態を,グローバルセッション情報のロック待ちといいます。また,ロック待ちが原因で発生するタイムアウトのことを,ロックタイムアウトといいます。

ロック待ち発生後のグローバルセッション情報の状態と,ロック取得処理の呼び出し結果の関係を次の表に示します。

表6‒15 ロック待ち発生後のグローバルセッション情報の状態とロック取得処理の呼び出し結果の関係

項番

ロック待ち発生後のグローバルセッション情報の状態

ロック待ち発生後のロック取得処理の呼び出し結果

出力されるメッセージ

1

先にセッションを使用していたリクエスト処理が終了し,ロックが解除された。

データベースのグローバルセッション情報がロックされます(正常終了)。

出力されない

2

タイムアウト時間を経過したが,ロックは解除されなかった(ロックタイムアウトの発生)※1

Webアプリケーション内でセッション取得処理が実行されると,com.hitachi.software.web.dbsfo.DatabaseAccessException※2がスローされます。

KDJE34312-W

3

ロック待ちの間にデータベースで障害が発生し,ロックは解除されなかった(ロックタイムアウトの発生)。

Webアプリケーション内でセッション取得処理が実行されると,com.hitachi.software.web.dbsfo.DatabaseAccessException※2がスローされます。

KDJE34312-W

注※1

ロックをするためのSQLをデータベースに送信し,通信路の障害などによってタイムアウトが発生した場合もこの状態に含まれます。

注※2

DatabaseAccessExceptionクラスは,java.lang.IllegalStateExceptionクラスを継承したクラスです。DatabaseAccessExceptionクラスの詳細については,マニュアル「アプリケーションサーバ リファレンス API編」の「3.1 例外クラス」を参照してください。

(3) J2EEサーバでの障害発生時のグローバルセッション情報のロック

Webアプリケーション実行中のJ2EEサーバで,OSのハングアップやネットワークの障害などが発生すると,データベース上でロック中のグローバルセッション情報が一時的にロックされたままの状態となる場合があります。

ロックされたままの状態から回復するには,次のどちらかの対処が必要です。

データベースの設定,運用については使用するデータベースのマニュアルを参照してください。