EJB コンテナー用ステートフル・セッション Bean のフェイルオーバー
WebSphere® Application Server を使用して、予期しないサーバー障害により制限されないステートフル・セッション Bean を使用するアプリケーションを作成できます。この製品では、データ複製サービス (DRS) およびワークロード管理 (WLM) の機能を使用して、ステートフル・セッション Bean フェイルオーバーを使用可能にすることができます。
- 1 つのアプリケーションを除いて、すべてのアプリケーションでフェイルオーバーを使用可能にしようと考えています。 そうするには、EJB コンテナー・レベルでフェイルオーバーを使用可能にし、アプリケーション・レベルで設定をオーバーライドして、1 つのアプリケーションでフェイルオーバーを使用不可にします。
- 1 つのインストール済みアプリケーションでフェイルオーバーを使用可能にしようと考えています。そうするには、 EJB コンテナー・レベルでフェイルオーバーを使用不可にし、アプリケーション・レベルで設定をオーバーライドして、 1 つのアプリケーションでフェイルオーバーを使用可能にします。
- アプリケーションの 1 つのモジュールを除いて、すべてのアプリケーションでフェイルオーバーを使用可能にしようと考えています。 そうするには、 EJB コンテナー・レベルでフェイルオーバーを使用不可にし、モジュール・アプリケーション・レベルで設定をオーバーライドして、 1 つのモジュールでフェイルオーバーを使用不可にします。
- 1 つのインストール済み EJB モジュールでフェイルオーバーを使用可能にしようと考えています。そうするには、 EJB コンテナー・レベルでフェイルオーバーを使用不可にし、EJB モジュール・レベルで設定をオーバーライドして、 1 つの EJB モジュールでフェイルオーバーを使用可能にします。
- EJB コンテナー・パネルでステートフル・セッション Bean のフェイルオーバーを使用可能または使用不可にする
- エンタープライズ・アプリケーション・パネルでステートフル・セッション Bean のフェイルオーバーを使用可能または使用不可にする
- EJB モジュール・パネルでステートフル・セッション Bean のフェイルオーバーを使用可能または使用不可にする
フェイルオーバーが使用可能な状態でのステートフル・セッション Bean 活動化ポリシー
アプリケーションのアセンブリー時にステートフル・セッション Bean のために活動化ポリシーを指定することができます。 EJB コンテナーが DRS を使用してステートフル・セッション Bean データを複製することにより、フェイルオーバーの準備を行うのは、ステートフル・セッション Bean が非活性化されているときのみであることを考慮する必要があります。 デフォルトの active once 活動化ポリシーを使用して Bean を構成する場合、Bean はステートフル・セッション Bean のフェイルオーバーで利用できるよう十分すぐに非活性化されません。このため、フェイルオーバーを使用可能にすると、EJB コンテナーは Bean に対して構成された活動化ポリシーを無視し、activate at transaction boundary 活動化ポリシーを自動的に使用します。このアクションにより、完了するトランザクションに Bean が enlist されていると、必ず、 Bean が非活性化され、Bean のデータが複製されます。

フェイルオーバーが使用可能な状態でのコンテナー管理の作業単位または Bean 管理の作業単位のステートフル・セッション Bean の使用
この場合、関連する作業単位は、 トランザクション およびアクティビティー・セッション です。 本製品は、コンテナー管理トランザクション (CMT)、Bean 管理トランザクション (BMT)、コンテナー管理アクティビティー・セッション (CMAS)、および Bean 管理アクティビティー・セッション (BMAS) のステートフル・セッション Bean フェイルオーバーをサポートします。ただし、コンテナー管理の場合では 、エンタープライズ Bean メソッド呼び出しの要求を送信してもサーバーに接続できない場合のみ、フェイルオーバ ーが準備されます。 また、サーバーが要求を受信し、応答した後に サーバー障害が発生すると、フェイルオーバーは発生しません。 要求または作業単位の途中で障害が発生した場合、WLM が別のサーバーに安全にフェイルオーバーするには、何らかの補正コードがアプリケーションで実行されます。この場合、アプリケーションは、Common Object Request Broker Architecture (CORBA) 例外およびマイナー・コードを受け取ります。これは、障害が作業単位の実行中に発生したため、透過的フェイルオーバーが行われなかったことを示します。 CORBA 例外とマイナー・コードのチェック、および障害の補正を行うアプリケーションを作成する必要があります。 補正コードが実行されると、アプリケーションは要求を再試行することができ、バックアップ・サーバー へのパスが存在する場合は、WLM が新しい要求をステートフル・セッション Bean の新しい 1 次サーバーへと転送します。
詳しくは、CORBA のマイナー・コードに関するトピックを参照してください。
詳しくは、z/OS® を除くすべてのプラットフォームのワークロード管理に関するトピックを参照してください。
これは、トランザクションまたはアクティビティー・セッションなどの Bean 管理の作業単位についても当てはまります。 ただし、Bean 管理の作業には新たに考慮すべき点が他にもある可能性があります。
- Bean 管理トランザクションまたはアクティビティー・セッションを使用するステートフル・セッション Bean のメソッドは、SessionContext オブジェクトから取得した UserTransaction で begin メソッドを呼び出します。 そのメソッドは始動済み作業単位で一部の処理を行いますが、メソッドの呼び出し元に戻るまでトランザクションまたはセッションを完了しません。
- メソッドの呼び出し開始後に、EJB コンテナーはメソッドが開始した作業を中断します。 これは、Bean がステートフル・セッション Bean のとき、Bean 管理の作業単位の Enterprise JavaBeans 仕様が必要とするアクションです。
- クライアントはステートフル・セッション Bean でその他の幾つかのメソッドを開始します。 各呼び出しによって、EJB コンテナーは中断していたトランザクションまたはアクティビティー・セッションを再開し、メソッド呼び出しをディスパッチして、呼び出し元に戻る前に再度作業を中断します。
- クライアントは、ステップ 1 で開始したトランザクションまたはセッションを完了するステートフル・セッション Bean でメソッドを呼び出します。
このシナリオは、スティッキー Bean 管理の作業単位を想定しています。 トランザクションまたはアクティビティー・セッションは、複数のステートフル・セッション Bean メソッドのために待機します。 アプリケーションがスティッキー BMT または BMAS を使用し、スティッキー作業単位が完了した後と、他のスティッキー作業単位が開始する前にサーバーで障害が発生すると、フェイルオーバーが成功しています。 ただし、スティッキー・トランザクションまたはアクティビティー・セッションが完了する 前に サーバーに障害が発生すると、フェイルオーバーは成功していません。 その代わり、フェイルオーバー処理がステートフル・セッション Bean 要求を新規サーバーに送付したときに、アクティブ・スティッキー・トランザクションまたはアクティビティー・セッション中に障害が発生したことを EJB コンテナーが検出します。 その時、EJB コンテナーは例外を開始します。
このプロセスは、トランザクションまたはアクティビティー・セッションが依然としてアクティブな場合、コンテナー管理および Bean 管理の作業単位のフェイルオーバーが両方とも失敗していることを意味します。 唯一の違いは、例外が Bean 管理の作業単位に対して発生することです。
アプリケーション設計に関する考慮事項
- 上記のセクションで説明した例外を回避するため、Bean 管理トランザクション (BMT) ではなくコンテナー管理トランザクション (CMT) を使用するように、アプリケーションを作成してステートフル・セッション Bean を構成することが推奨されます。
- フェイルオーバーが必要であり、ご使用のアプリケーションが HTTP セッションか、または他のステートフル・セッション Bean に参照を保管するステートフル・セッション Bean のいずれかを作成する場合、管理者は必ず HTTP セッションおよびステートフル・セッション Bean が同じデータ複製サービス (DRS) 複製ドメインを使用するよう構成する必要があります。
- 同じステートフル・セッション Bean にローカル参照とリモート参照を使用してはいけません。
通常、特定の 1 次キーを持つ ステートフル・セッション Bean インスタンスは、ある時間の特定の瞬間に単一のサーバーにのみ存在することができます。 フェイルオーバーによって、Bean があるサーバーから別のサーバーへ移動する可能性はありますが、 同時に複数のサーバーに存在することは決してありません。 ただし、同じ Bean インスタンス (同じ 1 次キー) が複数のサーバーに同 時に存在することが可能な珍しいシナリオがあります。 それが起こると、Bean のコピーのそれぞれが他の Bean の存在に気付かず、同じ 状態データを持つように 2 つのインスタンス間に同期が起こりません。 従って、アプリケーションは予測不能な結果を受け取ります。
重要: これを回避するために、フェイルオーバーが使用可能な状態では、ご使用のアプリケーションは同じステートフル・セッション Bean インスタンスに対してローカル (EJBLocalObject) 参照およびリモート (EJBObject) 参照の両方は決して取得しないように留意してください。 - ステートフル・セッション Bean で
リモート非同期メソッドを使用しないようにしてください。
非同期メソッドが呼び出されると、非同期メソッド要求がリモート・サーバーによってキューに入れられ、Future オブジェクトがクライアントに返されます。メソッド要求はステートフル・セッション Bean インスタンスがあるサーバーのキューにのみ入れられるため、Future オブジェクトはそのサーバーにバインドされ、フェイルオーバーしません。ステートフル・セッション Bean でリモートの非同期メソッドを使用する必要がある場合は、いつ Future オブジェクトへの呼び出しが失敗したかを検出し、非同期メソッドによって開始されたトランザクションが正常に完了したかどうかを判別するステートフル・セッション Bean に対する同期呼び出しを行うようアプリケーションを作成します。
-
フェイルオーバーが有効な場合、ステートフル・セッション Bean インスタンスで非パーシスタント EJB タイマーを参照しないようにします。
ステートフル・セッション Bean に、自動的、またはプログラムで作成された非パーシスタント・タイマー・インスタンスへのハンドルが含まれている場合、ステートフル・セッション Bean がフェイルオーバーした後でこのハンドルは無効になり、このハンドルが使用されると javax.ejb.NoSuchObjectLocalException 例外が発生します。 アプリケーションがステートフル・セッション Bean で非パーシスタント・タイマーを参照する必要がある場合、無効なハンドルを処理するアプリケーションを作成します。
重要: ステートフル・セッション Bean の自動的またはプログラムで作成されたパーシスタント・タイマーへのハンドルはフェイルオーバーし、ステートフル・セッション Bean のフェイルオーバー後も使用できます。
![[z/OS]](../images/ngzos.gif)
z/OS ユーザーのみ
- 複数のサーバント
- ピアの再始動およびリカバリーのセットアップ
- ステートフル・セッション Bean がデプロイする可能性があるクラスター
z/OS 製品には制御領域およびサーバント領域があり、 WebSphere Application Server Network Deployment 製品にはそのような領域がないため、 z/OS に固有のフェイルオーバー・シナリオが 1 つ考えられます。それは、1 つのサーバント領域から別のサーバント領域へのフェイルオーバー (コントローラーの損失を伴わないサーバントの損失) です。
HFS ベースの手法を z/OS で使用している場合は、その手法を続行します。
非管理対象 z/OS サーバーでは、サーバント間のステートフル・セッション Bean フェイルオーバーを使用可能にすることができます。 フェイルオーバーは、指定された非管理対象サーバーのサーバント間でのみ発生します。 非管理対象 z/OS サーバーにサーバントが 1 つしかない場合は、フェイルオーバーを使用可能にしても効果はありません。フェイルオーバーが使用可能になっている非管理対象 z/OS サーバーは、別の非管理対象 z/OS サーバーへはフェイルオーバーしません。非管理対象サーバーでフェイルオーバーを使用可能にするには、『非管理対象サーバーでのサーバントのフェイルオーバーの使用可能化』を参照してください。