| Oracle Containers for J2EEリソース・アダプタ管理者ガイド 10g（10.1.3.5.0） B56028-01 |
|
 戻る |
 次へ |
この章では、EISがアプリケーション・サーバー内のメッセージ・エンドポイント、具体的にはメッセージドリブンBean（MDB）への通信を開始できるようにするためのリソース・アダプタの使用の概念および構成について説明します。ここでは次の内容について説明します。
続く項においてはインバウンド通信用のリソース・アダプタの使用における最初の概念を説明します。
この章では、特定の作業を実行するためにEISがJ2EEアプリケーション・コンポーネントとの通信を開始する必要がある状況を考察します。このようなシナリオは、EISとの通信手段としてのリソース・アダプタ、（たとえば）JMSなどのメッセージ・システムのオプションでの使用、および通信メッセージを受信するJ2EEコンポーネントとしてのMDBを必要とします。MDBは順々に、エンティティBeanやセッションBeanを起動し、他のリソースを使用して作業を行います。
このようなシナリオは、「リソース・アダプタを介したアウトバウンド通信とインバウンド通信の比較」で説明したJ2CAのインバウンド通信モデルによって実現できます。インバウンド通信をサポートするために、J2CAのメッセージ・インフロー規約はリソース・アダプタからMDBを起動するメカニズムを提供します。この規約および他の関連する規約は、「インバウンド通信用の関連する規約の概要」で簡単に紹介されています。
この章では次のものに関連する構成、および他の関連するアクションについて説明します。
リソース・アダプタに必要な構成
MDBのデプロイおよび構成とMDBのリソース・アダプタへの関連付け
メッセージ配信のライフサイクル、すなわちMDBのアクティブ化（MDBがリソース・アダプタに対して受信を希望するメッセージのタイプを知らせるプロセス）、MDBへのメッセージ配信、およびMDBの非アクティブ化（MDBがリソース・アダプタに対してこれ以上メッセージを受信しないことを知らせるプロセス）
メッセージ配信における特別な条件、すなわち同時配信、MDBからの例外、およびトランザクション内での配信中の障害
EJB 2.0仕様においては、OC4JのようなJ2EEコンテナだけがMDB用のメッセージ・リスナーとして機能することができ、MDBはjavax.jms.MessageListenerインタフェースの実装を必要としました。EJB 2.1仕様においては、リソース・アダプタがMDB用のメッセージ・リスナーとして機能することができ、MDBはどのようなメッセージ・リスナー・インタフェースも実装できます。
リソース・アダプタはいかなるタイプのリスナーもサポートしており、MDBとリソース・アダプタが同じタイプのリスナーをサポートしていれば、どのMDBがどのリソース・アダプタに関連付けられることも可能です。これによりJ2EEコンテナは、無制限の数のメッセージ・リスナー・タイプをサポートする必要がなくなりました。このように、メッセージ・リスナーの能力はコンテナを越えてポータブルなものになりました。
Oracle Application Server 10g（10.1.3.5.0）では、JMSのメッセージ機能の実装をサポートするため、OC4JへのJMSプロバイダの組込み用に推奨される汎用JMSリソース・アダプタが提供されています。この一般的なアダプタは、（次の項、「インバウンド通信用の関連する規約の概要」で説明する）インバウンド通信をサポートしますが、MessageListenerインタフェースを実装するMDBとだけ協調して作業します。
一般的なJMSアダプタの詳細は、「OracleのJMSサポートおよび一般的なJMSリソース・アダプタの概要」を参照してください。
この項では、リソース・アダプタのMDB用メッセージ・リスナーとしての使用と関連するいくつかのJ2CA規約について簡単に説明します。
メッセージ・インフロー規約
トランザクション・インフロー規約
ワーク管理規約
メッセージ・インフロー規約とトランザクション・インフロー規約の詳細はこのドキュメントの現在のリリースでは説明されていませんが、OC4Jは単に標準的なものを実装します。ワーク管理規約と主要なAPIの説明は、「ワーク管理規約の概略」にありますが、詳細は説明されていません。これらの規約の詳細情報は、J2EE Connector Architecture Specificationのバージョン1.5を参照してください。
J2CAのメッセージ・インフロー規約は、リソース・アダプタとMDBの両方がJ2EEコンテナ内で実行する場合にリソース・アダプタを通したMDBへのメッセージ配信を可能にするための、J2EEコンテナとリソース・アダプタとの間の規約を説明するものです。MDBは受信を希望するメッセージのタイプを指定して構成される必要があり、リソース・アダプタはこれらのタイプのメッセージをサポート（シーク、検索およびリレー）できるかを指定して構成される必要があります。
メッセージ配信は一般に非同期ですが、MDBは個々のメッセージ・システムに特有なAPIを通してメッセージの送受信を同期的に行うこともできます。
多くの状況において、メッセージ・プロバイダはメッセージ配信のためにトランザクションを作成し、そのトランザクション内でリソース・アダプタにメッセージを送信します。このような状況でリソース・アダプタは、トランザクションをインポートして同じトランザクション内でMDBへのメッセージのリレーを試行します。この交換のためのリソース・アダプタの具体的なアクションはJ2CAのトランザクション・インフロー規約によります。
J2EEコンテナとリソース・アダプタの間のこの規約により、作業がインポート済のトランザクションの一部としてそこで実行されるように、リソース・アダプタはトランザクションをJ2EEのコンテナに伝播できます。またその規約によって、リソース・アダプタはEISによって開始されたトランザクションの完了およびリカバリのコールを受け入れることができ、それによってトランザクションのACIDプロパティが保持されます。（ACIDプロパティについては、「トランザクションの特徴と有効範囲」を参照してください。）
インポート済のトランザクションのコンテキスト内でメッセージが配信される場合は、アプリケーション・サーバーはトランザクション境界を処理する際にそのことを考慮する必要があります。
外部のトランザクション・マネージャによって開始されたトランザクションがリソース・アダプタによってインポートされるとき、リソース・アダプタはJ2CAのワーク管理規約を使用してJ2EEコンテナに、トランザクション用の識別情報を含む実行コンテキスト・オブジェクトを導入します。その後J2EEコンテナは、同じ制御のスレッド内で実行している他のコンポーネントに見えるトランザクションのコンテキストを内部的に設定する必要があります。
J2EEコンテナとリソース・アダプタの間にあるワーク管理規約の目的は、実行のために作業ユニットをJ2EEコンテナに発行することによって作業を行うメカニズムをリソース・アダプタに提供することです。規約によりリソース・アダプタは、MDBへのメッセージ配信などの作業がコンテナ管理のスレッドによって実行されるようにスケジュールできます。
MDBのかわりにリソース・アダプタをメッセージ・リスナーとして使用するためには次のものが必要になります。
OC4Jと同様に、J2EE Connector Architecture Specificationのバージョン1.5をサポートするJ2EE準拠のアプリケーション・サーバー
アプリケーション・サーバーにデプロイされ、一般的なメッセージ配信が可能であり、MDBが特に受信を希望するメッセージ・タイプをサポートするリソース・アダプタ
アプリケーション・サーバーへのMDBのデプロイ
|
注意:
|
この項の残りでは次の項目を説明します。
MDBのメッセージ・リスナーをサポートするために、OC4JはMDBが使用するメッセージ・リスナー・タイプとメッセージ・システムをサポートするデプロイ済のリソース・アダプタを持つ必要があります。リソース・アダプタは多くの場合、以前にデプロイ済のスタンドアロンのアダプタですが、（同じEARファイル内の）MDBと同じアプリケーションとともにデプロイされることも可能です。
MDBをサポートするリソース・アダプタの構成は、リソース・アダプタがサポートするメッセージ・リスナー・タイプを一覧表示する標準のra.xmlファイル内に含まれています。それぞれのリスナー・タイプは、実装されるメッセージ・リスナー・インタフェースを示す完全修飾されたJavaのタイプとして指定されます。
MDBのサポートはインバウンドのリソース・アダプタを必要とするため、リソース・アダプタは<inbound-resourceadapter>要素において構成されます。これには<messageadapter>サブ要素と、<messageadapter>の複数の<messagelistener>サブ要素（リソース・アダプタによってサポートされるメッセージ・リスナーのそれぞれのタイプ用に1つ）、および<messagelistener>の次のサブ要素が関連します。
<messagelistener-type>サブ要素は使用されるメッセージ・リスナーのタイプを示しており、MDBが構成されているejb-jar.xmlファイルの<messaging-type>要素に指定されるように、MDBによって実装されるメッセージ・リスナー・タイプと一致する必要があります。
<activationspec>サブ要素は、実行時にMDBをアクティブ化するためにOC4Jが持つ必要がある次の情報を指定します。
それぞれのメッセージ・リスナー・タイプ用に、リソース・アダプタはSPIのActivationSpecインタフェースを実装するJavaBeanクラスを提供しており、このクラスの名前は<activationspec>の<activationspec-class>サブ要素に指定されています。このクラスのインスタンスはメッセージ・エンドポイント（MDB）用のアクティブ化情報を含んでおり、エンドポイントのアクティブ化の間にリソース・アダプタに渡されます。
アクティブ化のために設定の必要があるこのクラスのBeanプロパティは<activationspec>の<required-config-property>サブ要素の下にそれぞれの<config-property-name>要素とともに指定されています。それぞれの<config-property-name>仕様は、ejb-jar.xmlファイル内の<activation-config-property>の一致する名前/値ペアに対応します。
次の例はjavax.jms.MessageListenerリスナー・タイプを使用してJava Message Service（JMS）メッセージ・システムをサポートするリソース・アダプタ用です。リソース・アダプタのアクティブ化仕様の実装はJavaBeanのoracle.j2ee.ra.jms.generic.JMSActivationSpecで、アクティブ化のために設定される必要のあるConnectionFactoryJndiName、DestinationNameおよびDestinationTypeの3つのプロパティを持っています。
<connector ... >
...
<resourceadapter>
...
<inbound-resourceadapter>
<messageadapter>
<messagelistener>
<messagelistener-type>
javax.jms.MessageListener
</messagelistener-type>
<activationspec>
<activationspec-class>
oracle.j2ee.ra.jms.generic.JMSActivationSpec
</activationspec-class>
<required-config-property>
<config-property-name>
ConnectionFactoryJndiName
</config-property-name>
<config-property-name>
DestinationName
</config-property-name>
<config-property-name>
DestinationType
</config-property-name>
</required-config-property>
</activationspec>
</messagelistener>
...
</messageadapter>
</inbound-resourceadapter>
...
</resourceadapter>
...
</connector>
|
注意:
|
MDBの開発者やデプロイヤはejb-jar.xmlファイルにおいて<message-driven>要素および次に示すサブ要素を通してMDBを構成します。
<messaging-type>サブ要素はMDBが実装するメッセージ・リスナー・インタフェースを指定し、使用されているリソース・アダプタのra.xmlファイルの<messagelistener-type>要素に指定されているメッセージ・リスナー・タイプと一致する必要があります。
<activation-config>サブ要素とその<activation-config-property>サブ要素は使用されるメッセージ・システムに固有の構成プロパティ用であり、特に、リソース・アダプタによって提供されるアクティブ化構成JavaBeanのカスタマイズ・プロパティ設定用です。構成は<activation-config-property>のサブ要素に指定される名前/値ペアによって表されます。ここでプロパティ名はra.xmlファイルの<config-property-name>要素のプロパティ名に対応しており、少なくともra.xmlに必須と指定されているプロパティについてはデフォルト値が指定されています。（どのプロパティが個々のメッセージ・システム用であると認識されるかはJ2CA仕様またはEJB仕様の範囲外です。）
MDBの構成の詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』またはEnterprise JavaBeans Specificationのバージョン2.1を参照してください。
次の例はJMSのメッセージ・システムでのキューの使用についてです。この例においてプロパティ名とプロパティ値を理解するためにはJMSの知識が必要です。
<ejb-jar>
...
<enterprise-beans>
...
<message-driven>
<ejb-name>simpleMdb</ejb-name>
<ejb-class>oracle.j2ee.ra.jms.mqjratest.simpleMdb</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Container</transaction-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>
DestinationType
</activation-config-property-name>
<activation-config-property-value>
javax.jms.Queue
</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>
DestinationName
</activation-config-property-name>
<activation-config-property-value>
java:comp/resource/MQSeries/MQQ
</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>
MessageSelector
</activation-config-property-name>
<activation-config-property-value>
RECIPIENT='MDB'
</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>
ConnectionFactoryJndiName
</activation-config-property-name>
<activation-config-property-value>
java:comp/resource/MQSeries/MQXAQCF
</activation-config-property-value>
</activation-config-property>
</activation-config>
...
<resource-ref>
<description>connfactory for reply</description>
<res-ref-name>jms/XAQCF</res-ref-name>
<res-type>javax.jms.XAQueueConnectionFactory</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
...
<resource-env-ref>
<description>Queue to send reply to</description>
<resource-env-ref-name>jms/QUEUE1</resource-env-ref-name>
<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>
...
</message-driven>
...
</enterprise-beans>
...
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>simpleMdb</ejb-name>
<method-name>onMessage</method-name>
<method-params>
<method-param>javax.jms.Message</method-param>
</method-params>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
...
</assembly-descriptor>
...
</ejb-jar>
|
注意:
|
前の項での説明に加えてejb-jar.xmlファイルの構成は、MDBがトランザクションを使用するか、それによってメッセージ配信が処理されるかどうかについて指定します。メッセージ配信は次の状況において処理されます。
ejb-jar.xmlの<message-driven>の<transaction-type>サブ要素がContainerの値を持っており、<assembly-descriptor>要素の下の<container-transaction>の<trans-attribute>サブ要素がRequiredの値を持っている。これは前述の項、「デプロイ用MDB構成の理解」の例に示されています。
この状況においてインポート済のトランザクションがある場合、メッセージ配信と関連する作業はそのトランザクション内で実行されます。インポート済のトランザクションがない場合、OC4Jはトランザクションを作成し、メッセージ配信と関連する作業をそのトランザクション内で実行します。
ejb-jar.xmlの<message-driven>の<transaction-type>サブ要素がBeanの値を持っている。
この状況において、MDBはトランザクションを管理します。トランザクションがインポートされる場合、競合を避けるためにOC4JはMDBへのメッセージ配信メソッドのコールの前にそれを一時停止します。
ejb-jar.xmlの<message-driven>の<transaction-type>サブ要素の値がContainerであるが、<trans-attribute>要素の値がNotSupportedである場合、メッセージ配信は処理されません。この状況でインポート済のトランザクションがある場合、OC4JはMDBへのメッセージ配信メソッドのコールの前にトランザクションを一時停止します。
トランザクションの開始と完了の詳細は、「メッセージ配信のセマンティック」を参照してください。
デプロイ後にApplication Server Controlを使用して、MDB用のいかなるアクティブ化構成JavaBeanプロパティの値も変更できます。新しい設定はMDBアプリケーションが再起動されたときに有効になります。
Application Server Controlコンソールで必要に応じて次のようにします。
OC4Jのホームページの「アプリケーション」タブで目的のアプリケーションを選択します。
「アプリケーション」ホームページが表示されたら、目的のEJBモジュールを選択します。
「EJBモジュール」ページが表示されたら「EJB」タブの「メッセージドリブンBean」の下で適切なMDBを選択します。
表示された「メッセージドリブンBean」ページの「メッセージ・プロパティ」下に次のものが表示されます。
現在、MDBがリソース・アダプタにリスナーとして関連付けられているかどうか（TrueまたはFalse）
リソース・アダプタの名前（リスナーとして使用されている場合）
アクティブ化構成プロパティのリスト
アクティブ化構成プロパティのリスト（リソース・アダプタがリスナーとして使用される場合だけ該当）はデプロイ中のejb-jar.xmlファイルの設定に従ってアセンブルされた値、および変更されたデプロイ済の値を示します。
「メッセージドリブンBean」ページにおいて「メッセージ・リスナー・プロパティの構成」機能を使用して「メッセージ・リスナー・プロパティの構成」ページにアクセスし、アクティブ化構成プロパティに目的の新しい値を指定します。
変更を適用します。
新しいアクティブ化構成プロパティ値は「メッセージドリブンBean」ページに表示され、表6-1に示されるようにorion-ejb-jar.xmlファイルに反映されます。詳細はApplication Server Controlオンライン・ヘルプの「メッセージドリブンBean」ページおよび「メッセージ・リスナー・プロパティの構成」ページに関する状況依存トピックを参照してください。
表6-1 MDBアクティブ化構成プロパティ
| Application Server Controlプロパティ | 対応するXMLエンティティ | 説明 |
|---|---|---|
|
リソース・アダプタ名 |
|
このMDB用のメッセージ・リスナーとして使用されるリソース・アダプタ（読取り専用）です。同じメッセージ・リスナー・タイプをサポートする必要があります。 |
|
アクティブ化構成プロパティのリストの適切な名前およびデプロイ済の値エントリ |
|
適切な |
リソース・アダプタとMDBのデプロイと構成の間に、OC4Jは次のように設定を検証し、必要に応じて例外をスローします。
リソース・アダプタが複数のメッセージ・リスナー・タイプをサポートする場合、OC4Jはra.xmlのそれぞれの<messagelistener-type>の設定が一意であることをチェックします。
MDBとリソース・アダプタの間のそれぞれの関連付けについて、OC4JはMDBが実装するメッセージ・リスナー・タイプをリソース・アダプタがサポートすることをチェックします。
メッセージ・リスナーのアクティブ化について、OC4Jはアクティブ化構成JavaBeanが（<activationspec-class>要素に指定されているように）javax.resource.spi.ActivationSpecインタフェースを実装しており、それがJavaBeanであり、シリアライズ可能であることをチェックします。OC4Jはまた、ra.xmlの<required-config-property>要素の下に必須と表示されているすべての構成プロパティが、アクティブ化構成JavaBeanによって実際にサポートされていることをチェックします。
この項では次の項目を含むメッセージリスナーのライフサイクルの主要なフェーズと機能について説明します。
リソース・アダプタからMDB（メッセージ・エンドポイント）へのメッセージ配信を有効にするために、MDBはそれがデプロイまたは開始されたときはいつでもアクティブ化される必要があります。MDBアプリケーションがデプロイされるとき、OC4Jはシステムの停止や障害の後の自動的な再アクティブ化と同様にアクティブ化のプロセスを処理します。
基本的にアクティブ化は、リソース・アダプタに対してどのような一連のメッセージをMDBが受信するかを知らせることで成り立っています。メッセージ配信はこの情報が提供される時点から開始されます。一連のメッセージがどのように定義されるかは、JMS用のメッセージ・セレクタおよび宛先タイプに基づく定義のようにメッセージ・リスナーのタイプに依存しています。
具体的には次のことがアクティブ化の間に発生します。
OC4Jは適切なアクティブ化構成JavaBeanをインスタンス化し、適切なリソース・アダプタをそれと関連付けます。JavaBeanのプロパティ値はejb-jar.xml内の構成から取得されるか、Application Server Controlを通してその後に行われた変更に基づきます。
OC4Jは適切なリソース・アダプタ（具体的にはSPIのResourceAdapterインタフェースを実装するクラスのインスタンス）のアクティブ化メソッドをコールしてMDBをアクティブ化します。
MDBをアクティブ化するメソッド・コールの中でOC4Jは次のものを渡します。
アクティブ化構成JavaBeanインスタンス
MDBへのメッセージ配信に使用するファクトリ・オブジェクト
リソース・アダプタは、アクティブ化構成JavaBeanのプロパティ値によって、求められるメッセージのタイプ、それらを取得する場所、それらをフィルタする方法を認識します。
ファクトリ・オブジェクトは、javax.resource.spi.endpoint.MessageEndpointFactoryインタフェースを実装するクラスのインスタンスであり、OC4Jによって提供されます。メッセージ・エンドポイントのファクトリ・オブジェクトの使用方法は次の項、「メッセージ配信」を参照してください。
|
注意: OC4Jはリソース・アダプタと関連してアクティブ化構成JavaBeanのメソッドを使用してBeanのプロパティ設定の妥当性をチェックします。デプロイ中のejb-jar.xmlファイルにおいて、またはそれに続くApplication Server Controlコンソールを通した構成において無効な設定が指定された場合は失敗します。OC4Jのログ・ファイルを参照し、問題のパラメータに適切な新しい値を設定してください。 |
この項では、メッセージ配信機能の次の側面を説明します。
メッセージ配信中に、リソース・アダプタはMDBのアクティブ化の間に受信したメッセージ・エンドポイント・ファクトリのメソッドをコールしてメッセージ配信に使用されるプロキシ・オブジェクトを取得します。これらのプロキシ・オブジェクトはOC4Jによって提供されるクラスのインスタンスで、次のものを実装します。
javax.resource.spi.endpoint.MessageEndpointインタフェース
MDBが実装するメッセージ・リスナー・インタフェース
プロキシ・オブジェクトはMDBと同じリスナー・インタフェースを実装するため、リソース・アダプタはメッセージ配信のためにリスナー・インタフェースのカスタム・メソッドを使用できます。
「トランザクションをメッセージ配信で使用するための構成」で説明したように、メッセージ配信は処理されるか（すなわちメッセージがトランザクション内で配信される）、処理されないかのどちらかです。配信が処理され、リソース・アダプタがメッセージ・エンドポイントのプロキシ・オブジェクトを取得したときにXAResourceオブジェクトを渡した場合、リソース・アダプタはXAResourceインスタンスを通してトランザクションの通知を受信します。
リソース・アダプタと実際のメッセージ・エンドポイント（MDB）の間のプロキシ・オブジェクトの使用は、トランザクションを投入したりチェックを行ったりするなどの理由でOC4Jがメッセージ配信をインターセプトする場合に必要になります。
|
注意:
|
リソース・アダプタがメッセージ配信用にメソッド（使用されているメッセージ・リスナーに固有のメソッド）をコールするときに次のことが発生します。
メッセージはリソース・アダプタに返されたレスポンスとともに実際のMDBインスタンスに配信される必要があります。
「MDBリスナー・メソッドからの例外」の説明のように、メッセージ配信中の例外はOC4Jによって処理され、リソース・アダプタに伝播される必要があります。
続く記述にあるように、J2EE Connector Architecture Specificationに従ってトランザクションのセマンティクスが強制される必要があります。
次のシナリオについて考えてみます。（トランザクションの設定についての関連情報は「トランザクションをメッセージ配信で使用するための構成」を参照してください。）
インポート済のトランザクションを持たず、MDB構成にRequiredが設定されたコンテナ管理のトランザクション（CMT）境界
インポート済のトランザクションを持たず、MDB構成にNotSupportedが設定されたコンテナ管理のトランザクション境界
インポート済のトランザクションを持ち、Requiredが設定されたコンテナ管理のトランザクション境界
インポート済のトランザクションを持ち、NotSupportedが設定されたコンテナ管理のトランザクション境界
インポート済のトランザクションを持たないBean管理のトランザクション (BMT) 境界
インポート済のトランザクションを持つBean管理のトランザクション境界
さらにリソース・アダプタは、メッセージ・エンドポイントのプロキシ・オブジェクトの（MessageEndpointインタフェースに指定される）beforeDelivery()およびafterDelivery()メソッドを使用して、トランザクション境界の制御を行使することを選択できます。それはMDBのメッセージ配信メソッドをコールする前にbeforeDelivery()をコールし、その後afterDelivery()をコールできます。これをbefore/after配信オプションと呼ぶことにして、前述のシナリオそれぞれについて考察します。
これとは別にリソース・アダプタは、メッセージ・エンドポイントのプロキシ・オブジェクトを取得するときはいつでもトランザクションの通知に使用するためにXAResourceオブジェクトを渡すことを選択できます。
|
注意:
|
インポート済のトランザクションを持たず、Requiredが設定されているCMT リソース・アダプタがbefore/after配信オプションを使用しない場合は次のようになります。
OC4Jはそれぞれのメッセージ配信メソッドのコールの前に新しいトランザクションを開始します。
リソース・アダプタがXAResourceオブジェクトを提供した場合、すべてのトランザクション通知はそのオブジェクトに送信されます。
OC4Jはそれぞれのメッセージ配信メソッドのコールの後にトランザクションを完了します。
リソース・アダプタがbefore/after配信オプションを使用する場合は次のようになります。
OC4JはbeforeDelivery()がコールされるときにトランザクションを開始します。
リソース・アダプタがXAResourceオブジェクトを提供した場合、すべてのトランザクション通知はそのオブジェクトに送信されます。
OC4JはafterDelivery()がコールされるときにトランザクションを完了します。
インポート済のトランザクションを持たず、NotSupportedが設定されているCMT リソース・アダプタがbefore/after配信オプションを使用するかどうかにかかわらず次のようになります。
OC4Jはメッセージ配信メソッドのコールの前、またはbeforeDelivery()がコールされるとき（該当する場合）にトランザクションの開始を試行しません。
リソース・アダプタがXAResourceオブジェクトを提供した場合、それは無視されます。
OC4Jはメッセージ配信メソッドのコールの後、またはafterDelivery()がコールされるとき（該当する場合）にトランザクションの完了を試行しません。
インポート済のトランザクションを持ち、Requiredが設定されているCMT リソース・アダプタがbefore/after配信オプションを使用するかどうかにかかわらず次のようになります。
OC4Jはそれぞれのメッセージ配信メソッドのコールの前、またはbeforeDelivery()がコールされるとき（該当する場合）に、すでにインポート済のトランザクションが存在するのでトランザクションに関して何もしません。
リソース・アダプタがXAResourceオブジェクトを提供した場合、すべてのトランザクション通知（メッセージ配信の始めから行われた通知、またはbeforeDelivery()コールから行われた通知のうちで該当するもの）はそのオブジェクトに送信されます。
MDBによってなされたすべての作業はインポート済のトランザクションに含まれます。
OC4Jは、リソース・アダプタを通して外部のトランザクション・マネージャによって完了がトリガーされるため、それぞれのメッセージ配信メソッドのコールの後、またはafterDelivery()がコールされるとき（該当する場合）にインポート済のトランザクションの完了を試行しません。しかしOC4Jはコールの間に発生した例外に基づいてトランザクションをロールバックするようにマークする場合があります。
インポート済のトランザクションを持ち、NotSupportedが設定されているCMT リソース・アダプタがbefore/after配信オプションを使用しない場合は次のようになります。
OC4Jはそれぞれのメッセージ配信メソッドのコールの前にインポート済のトランザクションを一時停止します。
リソース・アダプタがXAResourceオブジェクトを提供した場合、それは無視されます。
OC4Jはそれぞれのメッセージ配信メソッドのコールの後にインポート済のトランザクションを再開します。
リソース・アダプタがbefore/after配信オプションを使用する場合は次のようになります。
OC4JはbeforeDelivery()がコールされるときにインポート済のトランザクションを一時停止します。
リソース・アダプタがXAResourceオブジェクトを提供した場合、それは無視されます。
OC4JはafterDelivery()がコールされるときにインポート済のトランザクションを再開します。
インポート済のトランザクションを持たないBMT リソース・アダプタがbefore/after配信オプションを使用するかどうかにかかわらず次のようになります。
OC4Jはいかなるトランザクションの開始、完了、一時停止および再開も試行しません。
リソース・アダプタがXAResourceオブジェクトを提供した場合、それは無視されます。
インポート済のトランザクションを持つBMT リソース・アダプタがbefore/after配信オプションを使用しない場合は次のようになります。
OC4Jはそれぞれのメッセージ配信メソッドのコールの前にインポート済のトランザクションを一時停止します。
リソース・アダプタがXAResourceオブジェクトを提供した場合、それは無視されます。
OC4Jはそれぞれのメッセージ配信メソッドのコールの後にトランザクションを再開します。
リソース・アダプタがbefore/after配信オプションを使用する場合は次のようになります。
OC4JはbeforeDelivery()がコールされるときにインポート済のトランザクションを一時停止します。
リソース・アダプタがXAResourceオブジェクトを提供した場合、それは無視されます。
OC4JはafterDelivery()がコールされるときにインポート済のトランザクションを再開します。
リソース・アダプタに関連付けられたMDBアプリケーションがアンデプロイまたは停止されるときなど、リソース・アダプタがMDBへのメッセージ配信を停止するときはいつでもエンドポイントの非アクティブ化が必要です。非アクティブ化はOC4Jによって処理されます。
具体的にはOC4Jは適切なリソース・アダプタ（SPIのResourceAdapterインタフェースを実装するクラスのインスタンス）の非アクティブ化メソッドをコールしてMDBを非アクティブ化します。非アクティブ化メソッドのコールにおいて、OC4JはMDBのアクティブ化に使用されたものと同じアクティブ化構成JavaBeanインスタンスおよびメッセージ・エンドポイントのファクトリ・インスタンスを渡します。
「メッセージ配信」では基本的な機能を説明しました。この項では、次に示すメッセージ配信中の特別な条件、特にエラー条件について説明します。
メッセージ配信中、1つ以上のメッセージ・エンドポイントのプロキシ・オブジェクトを取得した後、リソース・アダプタは、1つのプロキシ・オブジェクトを使用してメッセージをシリアルに配信するか、複数のプロキシ・オブジェクトを使用して異なるスレッドでメッセージを配信するかを選択できます。後者のモードは同時配信と呼ばれます。
メッセージ配信メソッドのコールとbeforeDelivery()およびafterDelivery()コール（該当する場合）はすべてメッセージ配信の1つのユニットの一部と考えられており、すべて1つのスレッドからコールされる必要があります。
OC4Jは、それぞれのスレッドで別々のプロキシ・オブジェクトが使用されているかぎり、同時配信をサポートします。しかし、エンドポイントのプロキシの作成においてOC4JはUnavailableExceptionエラーをスローしてメッセージ・エンドポイントのプロキシ・オブジェクトの同時使用の数を制限しようとする場合があります。
OC4Jは同じエンドポイントのプロキシ・オブジェクトを異なるスレッドで使用するメッセージの同時配信の試行はサポートしません。作業が1つのスレッドの特定のプロキシ・オブジェクトを使用して開始される場合、その作業が別のスレッドに渡されることはありません。異なるスレッドで同じプロキシ・オブジェクトを使用する試みは例外を発生します。
|
注意: メッセージ同時配信用にOC4JはMDBのプールを保持します。ejb-jar.xml構成ファイルのmin-instancesおよびmax-instances属性がプールのサイズを制御します。 |
この項では次のシナリオを考えながら、MDBのメッセージ・リスナー・メソッドからの例外の処理におけるOC4Jのアクションについて説明します。
トランザクションのコンテキストで実行するMDBメソッドを持つコンテナ管理のトランザクション境界（MDBにRequiredが設定されている場合）
特定されないトランザクションのコンテキストで実行するMDBメソッドを持つコンテナ管理のトランザクション境界（MDBにNotSupportedが設定されている場合）
Bean管理のトランザクション境界
MDBにRequiredが設定されているCMT アプリケーションの例外（AppException）については、OC4Jは通常トランザクションをコミットし、リソース・アダプタに例外をスローすることを試みます。しかしMDBが（OC4JのUserTransactionオブジェクトのsetRollbackOnly()メソッドを通して）唯一可能なトランザクションの結果はロールバックであると指定した場合、例外がリソース・アダプタにスローされる前にトランザクションはロールバックされます。
システムの例外についてOC4Jは次のことを行います。
エラーをログに残します。
トランザクションをロールバックします。
MDBインスタンスを破棄します（そのインスタンスのメソッドはこれ以上起動されないことを意味します）。
EJBの例外（EJBException）にラップした後、リソース・アダプタに例外をスローします。
MDBにNotSupportedが設定されているCMT アプリケーションの例外については、OC4Jはリソース・アダプタに例外をスローします。
システムの例外についてOC4Jは次のことを行います。
エラーをログに残します。
MDBインスタンスを破棄します。
EJBの例外にラップした後、リソース・アダプタに例外をスローします。
BMT アプリケーションの例外については、OC4Jはリソース・アダプタに例外をスローします。
システムの例外についてOC4Jは次のことを行います。
エラーをログに残します。
トランザクションが開始されたがまだ完了されていない場合、ロールバックするようにトランザクションをマークします。
MDBインスタンスを破棄します。
EJBの例外にラップした後、リソース・アダプタに例外をスローします。
この項では、OC4Jによって管理されるトランザクションとインポート済のトランザクションの両方について、処理されたメッセージ配信中の障害からのリカバリについて説明します。
トランザクションがOC4Jによって開始されており、処理されたメッセージ配信中にOC4Jのシステム障害が発生した場合、障害の間に処理中でありインダウトな（準備されたがコミットされていない）すべての配信の結果についてメッセージ・プロバイダに通知する機能があります。リカバリはOC4Jによって開始されます。再配信の試行が必要かどうかの決定はメッセージ・プロバイダに委ねられています。
OC4Jが再び実行すると、次のリカバリの手順が実行されます。
実行中であったリソース・アダプタのインスタンスを再起動します。
それぞれのリソース・アダプタから、それぞれのオブジェクトがリソース・マネージャを表しているXAResourceオブジェクトの配列を取得します。この配列の取得において、OC4Jはそれぞれのリソース・アダプタにアクティブ化構成JavaBeanインスタンスの配列を渡します。それぞれのアクティブ化構成JavaBeanはシステム障害のときに実行していたMDBのアプリケーションに対応しています。
XAResourceオブジェクトの配列を処理して、それぞれのオブジェクトが一意のリソース・マネージャを表すサブセットを作成します。（複数のリソース・アダプタが同じリソース・マネージャを使用する場合があるのでXAResourceオブジェクトの初期の配列は同じリソース・マネージャに対応する複数のオブジェクトを持つ場合があります。）
それぞれのXAResourceオブジェクトのメソッドをコールして、それぞれのリソース・マネージャに対し、準備されたがまだコミットされていないトランザクションのリストを問い合せ、その後、必要に応じてそのようなトランザクションをそれぞれコミットかロールバックして完了します。
J2CA仕様では、インポート済のトランザクション中の障害からのリカバリ処理に続くシナリオについて検討しています。リカバリはリソース・アダプタを通してEISによって開始されます。インポート済のトランザクションについては、OC4Jはトランザクションをリカバリできます。しかし、OC4Jはトランザクション・コーディネータではないのでトランザクションの起動側からの指示なしにトランザクションを完了できません。
EISはそのリソース・アダプタを通して、トランザクションの完了とリカバリのためにSPIのXATerminatorインタフェースのOC4J実装を使用します。このインタフェースはprepare()、commit()、rollback()およびrecover()のメソッドを含みます。
次の説明においてアクティブなトランザクションとは、まだ用意されていなかったトランザクションを意味し、インダウトなトランザクションとは、準備に成功していたがまだコミットされていなかったトランザクションを意味します。
トランザクションがアクティブな間にEISによってOC4Jの障害が発見された場合: トランザクションの作業は中断されたと推定されます。EISはOC4Jを待たず、リカバリの処理も試行しません。
トランザクションがインダウトな間にEISによってOC4Jの障害が発見された場合: EISはトランザクションの完了を試行します。このために、EISはOC4Jとのネットワークの接続性の再確立を成功するまで試みます。OC4Jがリカバリしたとき、トランザクションの状態を決定し、必要に応じてそれを完了します。
J2CA仕様に従って、次の具体的な手順がこのシナリオにおいて実行されます。
OC4Jがリカバリしたとき、それはトランザクションをインポートしたリソース・アダプタを再起動します。
リソース・アダプタはOC4JからXATerminatorオブジェクトを取得します。
リソース・アダプタはEISとの通信を再確立します。
EISはトランザクション・コーディネータとして機能しており、トランザクションがコミットするかロールバックするかについてリソース・アダプタに指示し、javax.transaction.xa.Xidインスタンスを通してトランザクションのIDを提供します。
リソース・アダプタはトランザクションのIDを渡し、XATerminatorオブジェクトのcommit()またはrollback()メソッドをコールすることによって、トランザクションをコミットするかロールバックするかについての決定をOC4Jに通知します。
OC4Jは必要に応じてトランザクションのかわりにすべての作業をコミットするかロールバックします。
トランザクションがアクティブな間にリソース・アダプタによってEISの障害が発見された場合: リソース・アダプタはそれを中断します。
トランザクションがインダウトな間にリソース・アダプタによってEISの障害が発見された場合: リソース・アダプタはEISのリカバリを待ちます。EISがリカバリしたとき、それはリソース・アダプタとのネットワーク接続を再確立し、トランザクションを完了します。
J2CA仕様に従って、次の具体的な手順がこのシナリオにおいて実行されます。
EISがリカバリしたときOC4Jは通信を再確立します。
EISはEISからOC4Jにインポートされたインダウトなトランザクションのリストを取得するようにリソース・アダプタに指示します。
リソース・アダプタはインダウトなトランザクションのID（Xidインスタンス）のリストを取得します。リソース・アダプタは以前に取得したXATerminatorオブジェクトのrecover()をコールしてこれを行います。
リソース・アダプタはトランザクションのIDのリストをEISに転送します。
EISはトランザクション・コーディネータとして機能しており、それぞれのトランザクションについてコミットするかロールバックするかを決定してリソース・アダプタにこの決定を知らせます。
それぞれのトランザクションについて、リソース・アダプタはトランザクションのIDを渡し、必要に応じてXATerminatorのcommit()またはrollback()メソッドをコールします。
OC4Jは必要に応じてトランザクションのかわりにすべての実行された作業をコミットするかロールバックします。
