5.5.1　データベースセッションフェイルオーバ機能の概要

(1)　セッション情報の格納の流れ

データベースセッションフェイルオーバ機能を使用すると，リクエストによるセッションの作成処理が発生したときに，処理の延長上でセッション情報がデータベースに格納されます。

セッション情報の格納の流れを次の図に示します。

図5‒5　セッション情報の格納の流れ（データベースセッションフェイルオーバ機能）

項番は図中の番号と対応しています。

1. Webサーバがクライアントからセッションの作成が必要なリクエストを受け取ると，J2EEサーバでセッションが作成されます。

2. 作成されたセッションについて，セッション情報が作成されます。

3. セッション情報がデータベースに格納されます。

Webサーバ1またはJ2EEサーバ1で障害が発生すると，データベースに格納されたセッション情報がWebサーバ2またはJ2EEサーバ2へ引き継がれ，障害発生前の状態で業務を続行できます。

ページの先頭へ

(2)　WebサーバまたはJ2EEサーバで障害が発生した場合の処理の流れ

WebサーバまたはJ2EEサーバで障害が発生した場合，データベースに格納されているセッション情報を基に，ほかのJ2EEサーバでセッションを再作成し，正常に業務を続行できます。

WebサーバまたはJ2EEサーバで障害が発生した場合の処理の流れについて，次の図に示します。

図5‒6　WebサーバまたはJ2EEサーバで障害が発生した場合の処理の流れ（データベースセッションフェイルオーバ機能）

1. Webサーバ1で障害が発生すると，負荷分散機によってWebサーバ2へリクエストが転送されます。

2. 転送先のJ2EEサーバ2でリクエストを処理するとき，リクエストに関連づけられたセッションが存在しないため，データベースからセッション情報を引き継ぎます。

3. セッションが再作成されます。

セッションが正常に引き継がれ，障害発生前の状態で業務を続行できます。

また，J2EEサーバ1を再起動しWebサーバ1が障害から回復すると，再びリクエストはWebサーバ1に送信されます。

ページの先頭へ

(3)　データベースで障害が発生した場合の処理の流れ

データベースで障害が発生すると，J2EEサーバ上のセッション情報だけを操作して業務を続行できます。データベースが障害から回復し，それ以降のセッションの操作でデータベースにアクセスできたとき，J2EEサーバ上で操作したセッション情報でデータベースを更新します。

これによって，クライアントはデータベースに障害が発生したことを意識しないで業務を続行できます。

ページの先頭へ

(4)　データベースセッションフェイルオーバ機能の運用モード

データベースに格納済みのグローバルセッション情報に対して同じセッションIDを持つリクエストが複数同時に送信された場合，デフォルトの設定では，リクエストは複数同時に処理できます。これによって，データベースセッションフェイルオーバ機能を使用することによる処理性能の低下は抑えられています。

ただし，この運用は，冗長化された複数のJ2EEサーバから同じセッションIDのグローバルセッション情報を同時に更新するような処理が発生しないことを前提とした運用です。複数のJ2EEサーバから同じセッションIDのグローバルセッション情報が同時に更新された場合は，グローバルセッション情報の整合性が失われるおそれがあります。このようなケースを許容できないシステムでは，グローバルセッション情報の整合性を確保するためのモードを有効にする必要があります。

グローバルセッション情報の整合性を保障するモードを完全性保障モードといいます。このモードを有効にした場合，グローバルセッションを更新するたびにデータベースにロックが設定されます。同じセッションIDの複数のリクエストが同時に送信された場合は，リクエストがシリアルに処理されるため，グローバルセッション情報が不整合な状態になることはありません。ただし，複数同時に実行できないこと，およびグローバルセッション情報の格納のたびにロックの設定・解除処理が発生することから，リクエスト処理性能に影響を及ぼす場合があります。

このため，データベースセッションフェイルオーバ機能を使用する場合は，システムの目的や特性に応じて，どちらのモードで運用するかを検討する必要があります。

完全性保障モードの有効・無効による主な違いを次の表に示します。

表5‒5　完全性保障モードの有効・無効による主な違い

比較項目	完全性保障モード
	無効	有効
適したシステムの特性	性能を重視するシステムに適しています。	性能が低下したとしても，確実なセッション情報の引き継ぎが必要なシステムに適しています。
リクエストの処理性能	同じセッションIDの複数のリクエストを同時に処理できるので，優れています。	リクエストをシリアルに処理する必要があるため，性能が低下します。
グローバルセッション情報の完全性	同じセッションIDのグローバルセッション情報を同時に更新した場合は，保障されません。	保障されます。
データベースに障害が発生した場合の挙動	J2EEサーバ上のセッション情報を使用して処理を継続します（データベースセッションフェイルオーバ機能の縮退運用）。	エラーメッセージを出力して処理を停止します。

それぞれのモードでのリクエスト処理の流れを次の図に示します。

図5‒7　完全性保障モードを無効にした場合のリクエスト処理の流れ（デフォルトの設定）

完全性保障モードが無効の場合，HTTPセッション作成処理の延長でデータベース上にグローバルセッション情報を作成する際にデータベースのロックが取得・解除されますが，一度コミットしたあとのセッション取得処理ではロックが取得されません。また，以降のグローバルセッション情報の更新処理では，データベースのロックの取得処理および解除処理は実施されません。

図5‒8　完全性保障モードを有効にした場合のリクエスト処理の流れ

完全性保障モードが有効の場合，HTTPセッション作成処理の延長でデータベース上にグローバルセッション情報を作成する際に，データベースのロックが取得・解除されます。さらに，一度コミットしたあとのセッション取得処理で，再度ロックが取得されます。これによって，HTTPセッション作成後，Webアプリケーション実行中にJ2EEサーバまたはデータベースで障害が発生した場合にも，データベースに不整合が発生しないことが保障されます。また，以降のグローバルセッション情報の更新処理では，更新するたびにデータベースのロックを取得し，更新したあとで解除する処理が実施されます。

グローバルセッション情報のロック時の動作については，「6.4.5(1)　ロック取得時のロック取得処理の呼び出し結果」を参照してください。

また，完全性保障モードの有効・無効の設定によって，使用できる機能が異なります。

ページの先頭へ