JMSリソース・アダプタは、例外リスナーおよびJMS操作を通じて接続障害を検出します。WebLogic Serverインスタンス障害が検出されると、対応する接続およびセッションはクローズされ、新しい接続およびセッションが作成されます。障害が発生した接続は、再利用されるのを防ぐために接続プールからパージされます。
注意:
障害が発生したWebLogic Serverインスタンスが再起動されたり、新しいサーバー・インスタンスがクラスタに参加した場合、リソース・アダプタは、プール内の既存の接続を新しいサーバーまたは再起動されたインスタンスにロード・バランシングしません。
WebLogic Server分散宛先メンバーに障害が発生すると、JMSリソース・アダプタのインバウンドMDBコンテナは、既存の接続およびセッションをすべて閉じて、使用可能なクラスタ・メンバーへの新しい接続およびセッションを開きます。
障害が発生したクラスタ・メンバーがリストアされたり、新しいメンバーが追加された場合、JMSリソース・アダプタは、メッセージがすべての分散宛先メンバーに均等に分散されるように、ワークロードをリバランスします。JMSリソース・アダプタは、リバランスを実行するために、宛先メンバーのUP
およびDOWN
イベントをリスニングします。この動作を取得するには、サーバー・アフィニティを無効にしてロード・バランシングを有効にする必要があります。詳細は、Oracle WebLogic Serverクラスタの管理のJMSのロード・バランシングを参照してください。
すぐにリカバリできない障害については、アダプタはその障害をログに記録し、定期的に再試行します。
次の各項では、トランザクションが完了する前に、外部アプリケーション・サーバーまたはWebLogic Serverが使用不可能になった場合のトランザクション・リカバリ・プロセスについて説明します。
この項では、WebLogic Serverインスタンスが使用不可能な場合の、外部トランザクション・マネージャによって指示されたトランザクションの処理方法について説明します。
準備前の障害
トランザクションが準備される前に、サード・パーティ・トランザクション・マネージャによって指示されたトランザクションに参加するWebLogic Serverインスタンスが使用不可能になった場合、トランザクションは失われます。
準備後の障害
トランザクションが準備された後に、外部トランザクション・マネージャによって指示されたトランザクションに参加するWebLogic Serverインスタンスが使用不可能になった場合、結果はインダウト・トランザクションになります。
次のいずれかの状態になるまで、外部トランザクション・マネージャは定期的にトランザクションの再試行を続けます。
トランザクションがタイムアウトになり、リソースがリカバリされる。
元のWebLogic Serverインスタンスが使用可能になり、トランザクションが解決される。
WebLogic Server環境でクラスタ全体のリカバリがサポートされている場合、別のクラスタ・メンバー上の適切な介在トランザクション・マネージャ(ITM)に転送されると、トランザクションが解決される。
詳細は、Oracle WebLogic Server JTAアプリケーションの開発のクラスタ全体のリカバリおよびOracle WebLogic Server Java APIリファレンスのInterposedTransactionManager
を参照してください。
外部トランザクション・マネージャが、同じXAResource
を使用してトランザクションを完了する場合、JMSリソース・アダプタXAResource
ラッパーは、再試行されるたびに、ITMスタブをルックアップします。外部トランザクション・マネージャが、異なるXAResource
を使用してトランザクションを完了する場合、ライブ・インスタンス上のITMは、XAコールをターゲット・インスタンスに透過的に転送します。どちらの場合も、障害が発生したITMが再起動または移行のいずれかによってリストアされた後にのみ、トランザクションが完了します。
外部サーバーが再起動されると、リカバリ・プロセスが始まります。クラスタ全体のリカバリが有効な場合、影響を受けたクラスタ化されたWebLogic ServerのITMは、recover
メソッドがコールされた際に発生したすべてのインダウト・トランザクションを返します。各ITMは、それ自身でまたは責任のあるITMに転送することによって、すべてのインダウト・トランザクションに対してXAResource
のcommitおよびrollbackコールを処理します。
詳細は、Oracle WebLogic Server JTAアプリケーションの開発のクラスタ全体のリカバリを参照してください。
注意:
リカバリ・プロセスが成功するには、クラスタ内のすべてのITMをポーリングしてインダウト・トランザクションの完全なリストがコンパイルされるため、クラスタ内の個々のITMすべてが使用可能である必要があります。
外部トランザクション・マネージャは、JMSリソース・アダプタによって提供されるXAResource
ラッパーと対話します。XAResource
ラッパーはXAコールをITMスタブに引き継ぎます。JMSリソース・アダプタは、標準のJMS APIと固有のWebLogic JMS拡張APIをクライアント・インタフェースとして使用します。外部サーバー内で実行されるアプリケーション(EJBやサーブレットなど)は、JMSリソース・アダプタ・ラッパーを通じてJMSリソース・アダプタおよびWebLogic JMSと対話します。JMS操作のWebLogic Serverクライアント・オブジェクトへの引き継ぎの他に、JMSリソース・アダプタ・ラッパーは、適切なJMSコールを捕捉することによって、遅延登録およびトランザクション・ブランチの終了も行います。
次のトピックでは、WebLogic Serverサービスの移行中のJMSリソース・アダプタの動作に関する情報を提供します。
WebLogic JMSサーバーが移行可能なターゲットを使用するように構成されている場合、サービスの移行が完了すると、JMSリソース・アダプタ・インスタンスは移行後のWebLogic JMSサービスに再接続します。
注意:
WebLogic JMSサービスの移行では、JMSサービスの高可用性が提供されますが、ロード・バランシングは提供されません。
詳細は、Oracle WebLogic Serverクラスタの管理の移行可能なサービスを参照してください。
JMSサービスの移行中のJMSリソース・アダプタによるインバウンドとアウトバウンドの通信の処理方法の詳細について次に注意してください。
インバウンド通信
JMSサービスの移行中に、JMSリソース・アダプタは既存のWebLogic JMSの接続とセッションをクローズします。JMSサーバーとその分散宛先メンバーの移行が行われたWebLogic Serverインスタンスを指すように、新しい接続およびセッションが作成されます。
アウトバウンド通信
JMSサービスの移行中に、障害が発生したWebLogic Serverインスタンスの分散宛先メンバーは、使用可能なWebLogic Serverインスタンスに移行されます。JMSリソース・アダプタに関連付けられているWebLogic JMSクライアントは移行を検出し、JMS操作を移行後の新しい宛先メンバーにリダイレクトします。