10 障害の管理の理解

この章では、JMS RAがWebLogic Serverおよび外部アプリケーション・サーバーの障害に対応する方法ついて説明します。

この章の内容は次のとおりです。

• WebLogic Serverの障害

• WebLogic分散宛先メンバーの障害

• トランザクション・リカバリ

WebLogic Serverの障害

JMS RAは、例外リスナーおよびJMS操作を通じて接続障害を検出します。WebLogicインスタンス障害が検出されると、対応する接続およびセッションはクローズされ、新しい接続およびセッションが作成されます。障害が発生した接続は、再利用されるのを防ぐために接続プールからパージされます。

注意: 障害が発生したWebLogic Serverインスタンスが再起動されたり、新しいサーバー・インスタンスがクラスタに参加した場合、リソース・アダプタは、プール内の既存の接続を新しいサーバーまたは再起動されたインスタンスにロード・バランシングしません。

WebLogic分散宛先メンバーの障害

WebLogic分散宛先メンバーに障害が発生すると、JMS RAのインバウンドMDBコンテナは、既存の接続およびセッションをすべて閉じて、使用可能なメンバーへの新しい接続およびセッションを開きます。

• 障害が発生したメンバーがリストアされたり、新しいメンバーが追加された場合、JMS RAは、メッセージがすべての分散宛先メンバーに均等に分散されるように、ワークロードをリバランスします。JMSリソース・アダプタは、リバランスを実行するために、宛先メンバーのUPまたはDOWNイベントをリスニングします。Server Affinity=fasleおよびLoadBalancing=trueが必要です。

• すぐにリカバリできない障害については、アダプタはその障害をログに記録し、定期的に再試行します。

トランザクション・リカバリ

次の項では、トランザクションが完了する前に、外部アプリケーション・サーバーまたはWebLogic Serverが使用不可能になった場合のトランザクション・リカバリ・プロセスついて説明します。

• WebLogic Serverが使用不可能になった場合のトランザクション・リカバリ

• 外部サーバーが使用不可能になった場合のトランザクション・リカバリ

WebLogic Serverが使用不可能になった場合のトランザクション・リカバリ

次の項では、WebLogic Serverインスタンスが使用不可能な場合の、外部トランザクション・マネージャによって指示されたトランザクションの処理方法について説明します。

準備前の障害

トランザクションが準備される前に、サード・パーティ・トランザクション・マネージャによって指示されたトランザクションに参加するWebLogic Serverインスタンスが使用不可能になった場合、トランザクションは失われます。

準備後の障害

トランザクションが準備された後に、外部トランザクション・マネージャによって指示されたトランザクションに参加するWebLogic Serverインスタンスが使用不可能になった場合、結果はインダウト・トランザクションになります。

次のいずれかの状態になるまで、外部トランザクション・マネージャは定期的にトランザクションの再試行を続けます。

• トランザクションがタイムアウトになり、リソースがリカバリされる。

• 元のWebLogic Serverインスタンスが使用可能になり、トランザクションが解決される。

• WebLogic環境でクラスタ全体のリカバリがサポートされている場合、別のクラスタ・メンバー上の適切な介在トランザクション・マネージャ(ITM)に転送されると、トランザクションが解決される。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のクラスタ全体のリカバリに関する項およびOracle WebLogic Server Java APIリファレンスの介在トランザクション・マネージャに関する項を参照してください。

  外部トランザクション・マネージャが、同じXAResourceを使用してトランザクションを完了する場合、JMS RA XAResourceラッパーは、再試行されるたびに、ITMスタブをルックアップします。外部トランザクション・マネージャが、異なるXAResourceを使用してトランザクションを完了する場合、ライブ・インスタンス上のITMは、XAコールをターゲット・インスタンスに透過的に転送します。どちらの場合も、障害が発生したITMが再起動または移行のいずれかによってリストアされた場合のみ、トランザクションが完了します。

外部サーバーが使用不可能になった場合のトランザクションのリカバリ

外部サーバーが再起動されると、リカバリ・プロセスが始まります。Cluster-wide Recoveryが有効な場合、影響を受けたクラスタ化されたWebLogic ServerのITMは、recoverメソッドがコールされた際に発生したすべてのインダウト・トランザクションを戻します。各ITMは、それ自身でまたは責任のあるITMに転送することによって、すべてのインダウト・トランザクションに対してXAResourceのcommitまたはrollbackコールを処理します。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のクラスタ全体のリカバリに関する項を参照してください。

注意: リカバリ・プロセスが成功するには、クラスタ内のすべてのITMをポーリングして、インダウト・トランザクションの完全なリストをコンパイルする必要があるため、クラスタ内の個々のITMすべてが使用可能である必要があります。

外部トランザクション・マネージャは、JMS RAによって提供されるXAResourceラッパーと対話します。XAResourceラッパーはXAコールをITMスタブに引き継ぎます。JMS RAは、標準のJMS APIと固有のWebLogic JMS拡張APIをクライアント・インタフェースとして使用します。外部サーバー内で実行されるアプリケーション(EJBやサーブレットなど)は、JMS RAラッパーを通じてJMS RAおよびWebLogic JMSと対話します。JMS操作のWebLogicクライアント・オブジェクトへの引き継ぎの他に、JMS RAラッパーは、適切なJMSコールを捕捉することによって、遅延登録およびトランザクション・ブランチの終了も行います。

WebLogicサービスの移行の理解

次の項では、WebLogicサービスの移行中のJMS RAの動作に関する情報を提供します。

WebLogic JMSサーバーが移行可能なターゲットを使用するように構成されている場合、サービスの移行が完了すると、JMS RAインスタンスは移行後のWebLogic JMSサービスに再接続します。

注意: WebLogic JMSサービスの移行では、JMSサービスの高可用性が提供されますが、ロード・バランシングは提供されません。詳細は、『Oracle WebLogic Serverクラスタの管理』の移行可能なサービスに関する項を参照してください。ロード・バランシングの詳細は、次を参照してください。

次の項では、JMSサービスの移行中のJMS RAによるインバウンドとアウトバウンドの通信の処理方法について説明します。

• インバウンド通信

• アウトバウンド通信

インバウンド通信

JMSサービスの移行中に、JMS RAは既存のWebLogic JMSの接続とセッションをクローズします。JMSサーバーとその分散宛先メンバーの移行が行われたWebLogic Serverインスタンスを指すように、新しい接続およびセッションが作成されます。

アウトバウンド通信

JMSサービスの移行中に、障害が発生したWebLogic Serverインスタンスの分散宛先メンバーは、使用可能なWebLogic Serverインスタンスに移行されます。JMS RAに関連付けられているWebLogic JMSクライアントは移行を検出し、JMS操作を移行後の新しい宛先メンバーにリダイレクトします。