10g（10.1.3.1.0）
B31852-03
 目次 |
 索引 |
| Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド 10g（10.1.3.1.0） B31852-03 |
|
この章の内容は次のとおりです。
この項では、次のツールを使用したEJBアプリケーションの開発について説明します。
Oracle JDeveloperは、広範な自動化、迅速なデプロイとテストのための組込みOC4Jおよびその他多くの生産性向上機能を提供することで、Java EEアプリケーションの開発、パッケージングおよびデプロイを大幅に単純化します。次に例を示します。
JDeveloperの詳細は、http://www.oracle.com/technology/products/jdev/index.htmlを参照してください。
Eclipseは、Java EEアプリケーションの開発、パッケージングおよびデプロイを単純化する目的で広く採用されている統合開発環境です。
オラクル社では、EJB 3.0エンティティのオブジェクト・リレーショナル（O/R）マッピングの定義および編集用に拡張可能なフレームワークおよび典型的なツールをEclipseプラットフォームで開発しています。EJB 3.0 O/Rマッピング・サポートは、作成ウィザードと自動化された初期マッピング・ウィザード、および動的な問題識別などのプログラミング支援を提供することで、マッピングの複雑さを最小化することに重点を置きます。
EclipseでのEJB 3.0サポートの詳細は、http://www.eclipse.org/dali/を参照してください。
TopLink Workbenchを使用して、次のファイルを作成および構成できます。
toplink-ejb-jar.xmlおよびejb3-toplink-sessions.xmlファイル
toplink-ejb-jar.xmlファイル
ejb-jar.xmlファイル
詳細は、次を参照してください。
表2-1に、OC4Jに用意されている重要なサービスの一部をリストし、それらのサービスで使用できるEJBタイプを示します。
| OC4Jサービス | ステートフル・セッションBean | ステートレス・セッションBean | EJB 3.0エンティティ | CMPエンティティBean | BMPエンティティBean | メッセージドリブンBean |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OC4Jサービスの詳細は、表2-2に示されている適切なOC4Jマニュアルを参照してください。
この項の内容は次のとおりです。
Java EEアーキテクチャには、アプリケーションとその各種Java EEコンポーネントをパッケージ化（またはアセンブル）する様々な方法が用意されています。
Java EEアプリケーションをパッケージ化する最も効率的な方法は、JDeveloperやEclipseなどのJava EEツールを使用することです。
詳細は、次を参照してください。
Java EEアプリケーションをパッケージ化した後で、そのアプリケーションを実行し、エンド・ユーザーが使用できるようにするために、OC4Jにデプロイします。
Java EEアプリケーションをOC4Jにデプロイする最も効率的な方法は、Oracle Enterprise Manager 10g Application Server Controlを使用することです。
詳細は、次を参照してください。
OC4Jは、application.xmlデプロイメント・ディスクリプタに出現する順序でEJBモジュールをデプロイします。一般に、ロード順序はコンポーネントに固有であり、各コンポーネント・タイプの自然な順序に基づきます。
たとえば、例2-1に示すapplication.xmlファイルについて考えます。
<application>
<display-name>master-application</display-name>
<module>
<ejb>ejb1.jar</ejb>
</module>
<module>
<ejb>ejb2.jar</ejb>
</module>
<module>
<java>appclient.jar</java>
</module>
<module>
<web>
<web-uri>clientweb.war</web-uri>
<context-root>webapp</context-root>
</web>
</module>
<module>
<ejb>ejb3.jar</ejb>
</module>
このapplication.xmlファイルに基づいて、OC4Jはコンポーネントを次の順序でロードします。
このセクションでは、OC4JにデプロイされるEJBアプリケーションで使用する様々なEJBデプロイメント・ディスクリプタ・ファイルについて説明します。
表2-3に、OC4JにデプロイされるEJBアプリケーションで使用する様々なEJBデプロイメント・ディスクリプタ・ファイルをリストします。各デプロイメント・ディスクリプタ・ファイルについて、デプロイメント・ディスクリプタが適用されるEJBタイプと、使用しているEJB仕様でデプロイメント・ディスクリプタがオプション、必須、適用なしのいずれであるかを示します。
| デプロイメント・ディスクリプタ・ファイル | セッションBean | JPAエンティティ | EJB 2.1エンティティBean | メッセージドリブンBean | EJB 3.0 | EJB 2.1 |
|---|---|---|---|---|---|---|
|
|
|
|
|
オプション |
必須 |
|
|
|
1
|
|
|
オプション |
オプション |
|
|
|
|
|
|
オプション |
必須 |
|
|
|
|
|
|
オプション |
適用なし |
|
|
|
|
|
|
オプション |
適用なし |
|
|
|
|
|
|
オプション |
適用なし |
1
<entity-deployment>要素のdisable-default-persistent-unit属性のみ。 |
ejb-jar.xmlファイルは、EJBデプロイメント・ディスクリプタ・ファイルであり、使用される場合は次の内容を記述します。
必要な場合、ejb-jar.xmlファイルはJava EEアプリケーション・サーバーに適用されるEJB情報を記述します。この情報は、アプリケーション・サーバー固有のEJBデプロイメント・ディスクリプタ・ファイルによって補強される場合があります（「orion-ejb-jar.xmlファイルとは」および「toplink-ejb-jar.xmlファイルとは」を参照）。
詳細は、「ejb-jar.xmlファイルの構成」を参照してください。
EJB 3.0を使用している場合、このデプロイメント・ディスクリプタ・ファイルはオプションです。かわりにアノテーションを使用できます。このリリースでは、OC4Jで、セッションBeanおよびメッセージドリブンBeanのすべてのオプションに対してEJB 3.0アノテーションとejb-jar.xmlの両方の使用がサポートされます。ejb-jar.xmlファイルは、EJB 3.0エンティティでは使用されません。ejb-jar.xmlファイル内の構成によって、アノテーションがオーバーライドされます（「デプロイメント・ディスクリプタ・エントリによるアノテーションのオーバーライド」を参照）。
EJB 3.0エンティティの場合、アノテーションを使用するか、TopLink JPA永続性プロバイダのデプロイXMLファイル（toplink-ejb-jar.xmlおよびejb3-toplink-sessions.xml）を使用する必要があります。
詳細は、次を参照してください。
EJB 2.1を使用している場合、このデプロイメント・ディスクリプタ・ファイルは必須です。
このデプロイメント・ディスクリプタ・ファイルのXML参照は、使用しているEJBバージョンに依存します。
EJB 3.0の場合、このデプロイメント・ディスクリプタ・ファイルはhttp://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsdにあるXML Schema文書に準拠します。
EJB 2.1の場合、このデプロイメント・ディスクリプタ・ファイルはhttp://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsdにあるXML Schema文書に準拠します。
orion-ejb-jar.xmlファイルは、OC4J固有オプションをすべて含むEJBデプロイメント・ディスクリプタ・ファイルです。このファイルでは、ejb-jar.xmlファイルで指定する構成を拡張します（「ejb-jar.xmlファイルとは」を参照）。
詳細は、次を参照してください。
EJB 3.0を使用している場合、このファイルはオプションです。orion-ejb-jar.xmlファイルを使用せずにデプロイし、OC4J固有のアノテーション（@StatelessDeployment、@StatefulDeployment、@MessageDrivenDeploymentなど）またはApplication Server Controlを使用してOC4J固有オプションを設定できます。orion-ejb-jar.xmlファイルのベンダー拡張設定は、OC4J固有のアノテーションを使用した拡張設定に優先します。orion-ejb-jar.xmlファイル内の構成によって、アノテーションがオーバーライドされます（「デプロイメント・ディスクリプタ・エントリによるアノテーションのオーバーライド」を参照）。
詳細は、次を参照してください。
EJB 2.1を使用している場合、orion-ejb-jar.xmlファイルはすべてのOC4J固有オプションに対して必須です。
詳細は、「TopLink EJB 2.1永続性マネージャのカスタマイズ」を参照してください。
このデプロイメント・ディスクリプタ・ファイルは、http://www.oracle.com/technology/oracleas/schema/index.htmlにあるXML Schema文書に準拠します。
toplink-ejb-jar.xmlファイル（TopLink project.xmlファイルとも呼ぶ）は、TopLink JPAプレビュー永続性構成ディスクリプタ・ファイルであり、使用されている場合は、TopLinkディスクリプタやマッピングなどのTopLinkプロジェクトレベルのオプションを記述します（『Oracle TopLink開発者ガイド』のリレーショナル・プロジェクトの構成に関する項を参照）。
|
注意 OC4Jでは、TopLink Essentials JPA永続性プロバイダがデフォルトで使用されます。この場合、TopLink JPA拡張を使用して、TopLinkディスクリプタレベルのオプション（マッピングを含む）を構成できます（「TopLink Essentials JPA永続性を使用したTopLink APIへの実行時アクセス」を参照）。 |
詳細は、「toplink-ejb-jar.xmlファイルの構成」を参照してください。
デフォルトのTopLink Essentials JPA永続性プロバイダとともにEJB 3.0を使用している場合、このファイルは使用されません。
EJB 3.0を使用している場合、toplink-ejb-jar.xmlファイルはTopLink JPAプレビュー永続性プロバイダ構成のカスタマイズにのみ使用されます（「JPA永続性プロバイダのカスタマイズ」を参照）。このファイルを使用してTopLink永続性プロバイダをカスタマイズする場合は、ejb3-toplink-sessions.xmlファイルも使用する必要があります
（「ejb3-toplink-sessions.xmlファイルとは」を参照）。
EJB 2.1を使用している場合、toplink-ejb-jar.xmlファイルはオプションです。アプリケーションでこのファイルを省略する場合は、OC4Jで自動的に作成されるように構成できます（「デフォルトの関連性生成の構成」を参照）。または、このファイルを使用してTopLink永続性オプションを自分で構成できます（の「TopLink EJB 2.1永続性マネージャのカスタマイズ」を参照）。
toplink-ejb-jar.xmlファイルは、<OC4J_HOME>¥toplink¥config¥xsdsにあるXML Schema文書に準拠します。このファイルは手動で構成しないことをお薦めします。このファイルを作成および構成するには、TopLink Workbenchを使用します（『Oracle TopLink開発者ガイド』のTopLink Workbenchの理解に関する項を参照）。
ejb3-toplink-sessions.xmlファイルは、TopLink JPAプレビュー永続性構成ディスクリプタ・ファイルであり、TopLink JPAプレビュー永続性プロバイダとともに使用されている場合は、データソース、ログイン情報、キャッシュ・オプション、ロギングなどのTopLinkセッションレベル・オプション（『Oracle TopLink開発者ガイド』のサーバー・セッションの構成に関する項を参照）を記述します。TopLinkユーザーが使い慣れているsessions.xmlファイルと同等です。
|
注意 OC4Jでは、TopLink Essentials JPA永続性プロバイダがデフォルトで使用されます。この場合、TopLink JPA拡張を使用して、TopLinkセッションレベルのオプションを構成できます（「TopLink Essentials JPA永続性を使用したTopLink APIへの実行時アクセス」を参照）。 |
このファイルは、使用されている場合はプライマリ・プロジェクトへの参照を提供します
（「toplink-ejb-jar.xmlファイルとは」を参照）。
詳細は、「ejb3-toplink-sessions.xmlファイルの構成」を参照してください。
デフォルトのTopLink Essentials JPA永続性プロバイダとともにEJB 3.0を使用している場合、このファイルは使用されません。
EJB 3.0を使用している場合、ejb3-toplink-sessions.xmlファイルはTopLink JPAプレビュー永続性プロバイダ構成のカスタマイズにのみ使用されます（「JPA永続性プロバイダのカスタマイズ」を参照）。このファイルを使用してTopLink JPAプレビュー永続性プロバイダをカスタマイズする場合は、toplink-ejb-jar.xmlファイルも使用できます
（「toplink-ejb-jar.xmlファイルとは」を参照）。
EJB 2.1を使用している場合、ejb3-toplink-sessions.xmlファイルは使用されません。
ejb3-toplink-sessions.xmlファイルは、<OC4J_HOME>¥toplink¥config¥xsdsにあるXML Schema文書に準拠します。このファイルは手動で構成しないことをお薦めします。このファイルを作成および構成するには、TopLink Workbenchを使用します（『Oracle TopLink開発者ガイド』のTopLink Workbenchの理解に関する項を参照）。
persistence.xmlファイルは、エンティティを使用するEJB 3.0アプリケーションで1つ以上の永続性ユニットを定義するために使用する永続性ディスクリプタ・ファイルです。
このリリースでは、EJB JAR、WARまたはEARでpersistence.xmlを定義できます。
永続性ユニットでは、エンティティ・マネージャの構成を定義します。エンティティ・マネージャを取得するときに、永続性ユニットを名前で指定します（「EntityManagerの取得」を参照）。または、OC4Jのデフォルト永続性ユニットを利用できます（「OC4Jの永続性ユニットのデフォルトについて」を参照）。
永続性ユニットは、次のものを含む論理的なグループです。
特定の永続性ユニットのすべての永続管理クラスは、単一のデータベースに対するマッピングにまとめて配置する必要があります。
orm.xmlファイル（「orm.xmlファイルとは」を参照）を使用して指定できます。
詳細は、次を参照してください。
永続性ユニットの構成を単純化するために、次のOC4J機能を使用できます。
詳細は、次を参照してください。
EJBモジュール専用として、次の場合にOC4Jにデフォルトのpersistence.xmlファイルの構築を任せ、適切なデフォルト値でそのファイルを構成し、デフォルト名でデフォルトの永続性ユニットを定義できます。
persistence.xmlなしでアプリケーションをデプロイし、アプリケーションに@Entityアノテーション付きのクラスが少なくとも1つ含まれる場合
persistence.xmlとともにアプリケーションをデプロイする場合
アプリケーションで（明示的に、またはスマート・デフォルト設定を通じて）永続性ユニットを1つのみ指定する場合、エンティティ・マネージャの取得時に永続性ユニット名を指定する必要はありません。この場合、OC4Jによりデフォルトの永続性ユニット名が指定されます。
この機能を無効にするには、orion-ejb-jar.xmlファイルの属性disable-default-persistent-unitをtrueに設定します。
この機能を無効にしても、persistence.xmlファイルで空の永続性ユニットを指定する場合はOC4Jのデフォルト永続性ユニットを使用でき、その永続性ユニットの有効範囲内のエンティティ・マネージャを取得するときに、永続性ユニットを名前で指定する必要はありません。この場合、OC4Jは、固有のデフォルト永続性ユニットを使用し、永続性ユニット・ルート内のすべてのJPAエンティティ・クラスがその永続性ユニットに属していることを前提とします。このような空の永続性ユニットは、アプリケーションに1つのみ指定できます。
EJB 3.0エンティティを使用している場合、（OC4Jのデフォルト永続性ユニットを使用していないかぎり）persistence.xmlファイルは必須です。
EJB 2.1を使用している場合、persistence.xmlファイルは使用されません。
EJB 3.0の場合、このデプロイメント・ディスクリプタ・ファイルはhttp://java.sun.com/products/ejb/docs.htmlにあるEJB 3.0仕様で定義されているXML Schema文書に準拠します。
orm.xmlファイルは、オブジェクト・リレーショナル・マッピング構成の指定に使用するXMLデプロイメント・ディスクリプタです。orm.xmlファイルは、アノテーションのかわりに、またアノテーションに優先して使用できます。
複数のorm.xmlファイルを指定でき、これらのファイルはクラスパスの任意の場所に存在できます。
詳細は、次を参照してください。
EJB 3.0エンティティを使用している場合、orm.xmlファイルはオプションです。
EJB 2.1を使用している場合、orm.xmlファイルは使用されません。
EJB 3.0の場合、このデプロイメント・ディスクリプタ・ファイルはhttp://java.sun.com/products/ejb/docs.htmlにあるEJB 3.0仕様で定義されているXML Schema文書に準拠します。
一般に、Enterprise Beanはクライアントから使用します（「クライアント・アクセスについて」を参照）。
Enterprise Beanを使用して、メソッド起動フローのファイングレインな制御を実装することもできます（「EJB 3.0インターセプタについて」を参照）。
Webサービス・クライアントまたはWebサービス・エンドポイントとしてWebサービスとともにEnterprise Beanを使用することもできます（「EJBおよびWebサービスについて」を参照）。
デプロイされたEJBアプリケーションでは、Java EEアプリケーションのコンポーネントの性質を利用して、EJBのパフォーマンスおよびリソース使用率を監視および制御できます
（「EJB管理について」を参照）。
一般には、Enterprise Beanをクライアントから使用して（「使用しているクライアントのタイプ」を参照）、セッション、永続性またはメッセージ処理の管理などのアプリケーション・タスクを実行します。詳細は、第29章「クライアントからのEnterprise Beanへのアクセス」を参照してください。
インターセプタは、EJB 3.0セッションBeanのビジネス・メソッドまたはメッセージドリブンBeanのメッセージ・リスナー・メソッドに関連付けるメソッドです。クライアントがこのようなメソッドを起動すると、OC4Jは、クライアント起動の続行を許可する前にクライアントの起動をインターセプトし、インターセプタ・メソッドを起動します。
インターセプタ・メソッドおよびインターセプタ・ライフ・サイクル・コールバック・メソッドは、BeanクラスまたはBeanに関連付けられた個別のインターセプタ・クラスで定義できます。
ライフ・サイクル・コールバック以外のインターセプタは、各Beanに1つのみ定義できます。ビジネス・メソッドが起動されるたびに、OC4Jでは最初にAroundInvokeメソッドが起動されます。ライフ・サイクル・コールバック・インターセプタ・メソッドは、対応するライフ・サイクル・イベントが発生した場合にのみ起動されます。
個別のインターセプタ・クラスに定義されるインターセプタ・メソッドは、起動コンテキストを引数として使用します。コンテキストを使用することで、インターセプタ・メソッド実装では、元のセッションBeanのビジネス・メソッドまたはメッセージドリブンBeanのメッセージ・リスナー・メソッド起動の詳細にアクセスできます。
この項の内容は次のとおりです。
詳細は、次を参照してください。
インターセプタは、セッションBean（ステートレスおよびステートフル）とメッセージドリブンBeanで使用できます。
OC4Jは、インターセプタをBeanのすべてのビジネス・メソッドに適用します。
複数のインターセプタ（1つのインターセプタ・メソッドと、1つの独自のインターセプタ・メソッドをそれぞれ含む1つ以上のインターセプタ・クラス）が存在する場合、クライアントがビジネス・メソッドを起動するたびに、OC4Jは、クライアントによる起動の続行を許可する前にインターセプタ・クラスを定義順に起動し、次にインターセプタ・メソッドを起動します。
インターセプタ・メソッドは、ビジネス・メソッドになることができません。
インターセプタ・メソッドは、次のシグネチャを持つ必要があります。
Object <METHOD>(InvocationContext) throws Exception
インターセプタ・メソッドには、public、private、protectedまたはpackageレベルのアクセスを割り当てることができますが、finalまたはstaticとして宣言することはできません。
インターセプタ内では、InvocationContextを使用してクライアント起動メタデータにアクセスできます。
インターセプタ・メソッドの起動は、起動されるビジネス・メソッドと同じトランザクションおよびセキュリティ・コンテキスト内で行われます。
インターセプタ・メソッドは、ランタイム例外をスローするか、次のようにEJBContextオブジェクトを使用してsetRollbackOnlyをコールすることにより、トランザクションにロールバックのマークを付けることができます。
InvocationContext.getEJBContext().setRollbackOnly();
インターセプタは、InvocationContext.proceed()のコールの前後にこのロールバックを引き起こすことがあります。
詳細は、「ロールバック計画の使用方法」を参照してください。
コンテナ管理のトランザクション（「コンテナ管理のトランザクションとは」を参照）を使用する場合、インターセプタでは、コンテナのトランザクション境界の設定に干渉するリソース・マネージャ固有のトランザクション管理メソッドを使用できません。たとえば、インターセプタは、java.sql.Connectionインタフェースのcommit、setAutoCommitおよびrollbackメソッド、またはjavax.jms.Sessionインタフェースのcommitおよびrollbackメソッドを使用できません。インターセプタは、javax.transaction.UserTransactionインタフェースの取得または使用を試行しません。
EJB 3.0仕様に指定されているとおり、OC4Jでは、デフォルトでBeanインターセプタが作成されます。Beanインターセプタ・インスタンスのライフ・サイクルは、関連付けられているBeanインスタンスのライフ・サイクルと同じです。Beanインスタンスが作成されると、Beanに定義されたインターセプタ・クラスごとにインターセプタ・インスタンスが作成されます。これらのインターセプタ・インスタンスは、Beanインスタンスの削除時に破棄されます。このようにして、インターセプタに状態を格納できます。
インターセプタがステートレスの場合、OC4JによるEJB 3.0仕様の最適化拡張を使用して、シングルトン・インターセプタを指定できます。シングルトン・インターセプタを使用するようセッションBeanまたはメッセージドリブンBeanを構成し、Beanをインターセプタ・クラスに関連付けると、OC4Jにより、すべてのBeanインスタンスで共有できるインターセプタ・クラスの単一のインスタンスが作成されます。これにより、メモリー要件が低下し、ライフ・サイクルのオーバーヘッドが減少します。
詳細は、次を参照してください。
ステートレス・セッションBeanはWebサービス・エンドポイントとして公開できます。任意のEJBタイプをWebサービスのクライアントにできます。
詳細は、第30章「EJBおよびWebサービスの使用方法」を参照してください。
Java EEアプリケーションのデプロイ後に、Java EE管理機能を使用して実行時にアプリケーションを監視および最適化できます。
詳細は、次を参照してください。
OC4Jでは、次の永続性APIがサポートされます。
OC4Jは、定義するオブジェクト・リレーショナル・マッピングのタイプおよび特定のデプロイXMLファイルが存在するかどうかに基づいて、使用する永続性のタイプを選択します。OC4Jの選択は、デプロイしているEJBアプリケーションのタイプに応じて変化します。
ejb-jar.xmlファイルを使用せずにEJB 3.0エンティティをejb.jarにデプロイする場合、またはOC4Jで1つ以上のEJB 3.0アノテーションが検出された場合、OC4JはTopLink EJB 3.0 JPA永続性プロバイダを使用します。
詳細は、次を参照してください。
EJB 2.1およびEJB 2.0アプリケーションでは、OC4Jは、アクションごとに表2-4にまとめられているアルゴリズムを使用します。たとえば、toplink-ejb-jar.xmlファイルを使用せずにCMPアプリケーションをデプロイする場合、OC4JはTopLink永続性マネージャを使用し、デフォルトのTopLinkオブジェクト・リレーショナル・マッピングを作成します。
| アクション | toplink-ejb-jar.xml | orion-ejb-jar.xml | 永続性マネージャ | マッピング・タイプ |
|---|---|---|---|---|
|
なし |
オプション。存在する場合、マッピングおよび |
Toplink |
デフォルトのTopLink |
|
|
存在 |
オプション。存在する場合、マッピングおよび |
Toplink |
|
|
|
存在 |
オプション。存在する場合はマッピングが含まれません。 |
Toplink |
|
|
|
なし |
存在し、Orionマッピングを含みます。 |
Orion |
|
|
|
なし |
オプション。存在する場合はマッピングが含まれません。 |
Orion |
デフォルトのOrion |
|
1
「<persistence-manager>」を参照してください。 |
詳細は、次を参照してください。
Java Naming and Directory Interface（JNDI）では、複数のネーミングおよびディレクトリ・サービスへの統一インタフェースがJava EEアプリケーションに提供されます。JNDIを使用して、分散Java EE環境でコンポーネントを編成および特定できます。Java EEコンポーネントおよび関連付けられているJNDIプロパティの環境参照を定義できます。
JNDIを使用すると、次のものを使用してこれらのコンポーネントをルックアップおよび取得できます。
詳細は、次を参照してください。
データソースは、OC4Jがエンティティを維持する物理的なエンタープライズ情報システムを表すJavaオブジェクトです。アプリケーションでは、データソース・オブジェクトを使用して、データソースが表すエンタープライズ情報システムへの接続を取得します。
この項の内容は次のとおりです。
詳細は、次を参照してください。
OC4Jでは、次のタイプのデータソースがサポートされます。
表2-5に、これらのOC4Jデータソースの特性をリストします。
| 特性 | マネージド | ネイティブ |
|---|---|---|
|
OC4J接続プールを使用するか |
○ |
× |
|
接続がグローバル・トランザクションに参加できるか |
○ |
× |
|
接続がOC4J |
○ |
× |
マネージド・データソース（例2-2を参照）は、JDBCドライバまたはデータソースのラッパーとして機能するjava.sql.DataSourceインタフェースのOC4J提供の実装です。マネージド・データソースを個別の接続プールに関連付けることができます。複数のマネージド・データソースで同じ接続プールを共有できます。
<connection-pool name="ScottConnectionPool">
<connection-factory
factory-class="oracle.jdbc.pool.OracleDataSource"
user="scott"
password="tiger"
url="jdbc:oracle:thin:@//localhost:1521/ORCL" >
</connection-factory>
</connection-pool>
<managed-data-source
name="OracleManagedDS"
jndi-name="jdbc/OracleDS"
connection-pool-name="ScottConnectionPool"
/>
詳細は、「Oracleデータベースのデータソースの構成」を参照してください。
ネイティブ・データソース（例2-3を参照）は、java.sql.DataSourceインタフェースのJDBCベンダー提供の実装です。選択するデータソース・インスタンスで提供される接続プールを使用します。各ネイティブ・データソースでは独自の接続プールを使用する必要があります。
<native-data-source
name="nativeDataSource"
jndi-name="jdbc/nativeDS"
description="Native DataSource"
data-source-class="com.ddtek.jdbcx.sqlserver.SQLServerDataSource"
user="frank"
password="frankpw"
url="jdbc:datadirect:sqlserver://server_name:1433;User=usr;Password=pwd">
</native-data-source>
詳細は、「サード・パーティ・データベースのデータソースの構成」を参照してください。
接続URLを指定して、OC4Jに基礎となる物理データソースの検索場所を指示します。
マネージド・データソース（「マネージド・データソース」を参照）を定義する場合、接続URLは関連付ける接続プールの属性です（例2-2を参照）。
ネイティブ・データソース（「ネイティブ・データソース」を参照）を定義する場合、接続URLはネイティブ・データソースの属性です（例2-3を参照）。
Oracleデータベースへの接続URLを指定する場合は、サービスベースのURLを使用する必要があります。つまり、例2-4に示すように（host:port:SIDではなく）host:port/SIDの形式のURLです。
url="jdbc:oracle:thin:@//localhost:1521/ORCL"
Oracle以外のデータベースへの接続URLを指定する場合は、そのシステムに適したURLを使用します。例2-5に、SQLServerデータベースの典型的な接続URLを示します。
url="jdbc:datadirect:sqlserver://server_name:1433;User=usr;Password=pwd"
マネージド・データソースでは、ローカル・トランザクションとグローバル（2フェーズ・コミット）トランザクションの両方がサポートされます。デフォルトでは、これらはグローバル・トランザクションをサポートするように構成されます。詳細は、「Oracleデータベースのデータソースの構成」を参照してください。
ネイティブ・データソースではローカル・トランザクションのみサポートされます。
OC4Jでは、data-sources.xmlファイルにデータソース情報を構成します。
EARにはdata-sources.xmlファイルを含めることができますが、OC4Jでは複数のdata-sources.xmlファイルはサポートされません。
EJB 3.0アプリケーションでは、データソースを永続性ユニットに関連付けます（「永続性ユニットでのデータソースの指定」を参照）。
詳細は、次を参照してください。
アプリケーション構成を単純化するために、デフォルトのデータソースを定義できます。
デフォルトのデータソースの定義方法は、デフォルトのデータソースにアクセスするアプリケーションのタイプによって決まります。
異なるタイプのアプリケーションのデータソースを構成する方法の詳細は、次を参照してください。
OC4Jでは、orion-ejb-jar.xmlファイルの異なるエンティティ内にある複数のデータソースはサポートされません。
アプリケーションが複数のEARから構成され、各EARにdata-sources.xmlが含まれている場合、アプリケーションのデプロイ時に、OC4Jは最後のエンティティBeanのdata-source.xmlファイルをすべてのエンティティBeanに対して使用します。
このシナリオに対処するには、データソースをorion-application.xmlファイルで指定するか、デフォルトのデータソースを指定します。
詳細は、次を参照してください。
OC4Jで、Java Transaction Service（JTS）でサポートされるJava Transaction API（JTA）を使用してトランザクションを管理できます。アノテーションまたはデプロイメント・ディスクリプタを使用して、設計またはデプロイ時にEnterprise Beanのトランザクション・プロパティを定義し、OC4Jでトランザクション管理を引き継ぎます。
この項の内容は次のとおりです。
詳細は、次を参照してください。
トランザクションは、コンテナ（「コンテナ管理のトランザクションとは」を参照）またはBean（「Bean管理のトランザクションとは」を参照）で管理できます。
コンテナ管理のトランザクション管理がデフォルトです。
Enterprise Beanでトランザクション管理を構成する場合、次の制限を考慮してください。
他のすべてのEJBタイプでは、コンテナ管理またはBean管理のトランザクション管理を選択できます。
詳細は、次を参照してください。
コンテナ管理のトランザクション（CMT）を使用する場合、EJBは、トランザクションが開始したことを確認して適宜コミットする責任をコンテナに委任します。
すべてのセッションBeanとメッセージドリブンBeanでCMTを使用できます。
EJB 2.1エンティティBeanではCMTを使用する必要があります。
EJB 3.0エンティティは、トランザクション管理タイプで構成できません。EJB 3.0エンティティは、コール元のトランザクション・コンテキスト内で実行されます。
CMTを使用するEnterprise Beanの開発時には、次の点を考慮します。
java.sqlConnectionのメソッドcommit、setAutoCommit、rollback、またはjavax.jms.Sessionのメソッドcommit、rollbackなど、リソース・マネージャ固有のトランザクション管理メソッドは使用しません。
javax.transaction.UserTransactionインタフェースは取得または使用しません。
javax.ejb.SessionSynchronizationインタフェースを実装できます。
javax.ejb.EJBContextのメソッドsetRollbackOnlyおよびgetRollbackOnlyを使用できます。
CMTを使用するEJBでは、各ビジネス・メソッドについて、クライアントがメソッドを起動したときにコンテナがトランザクションを管理する方法を決定するトランザクション属性も指定できます（「クライアントがビジネス・メソッドを起動する際のトランザクションの処理方法」を参照）。
Bean管理のトランザクション（BMT）を使用する場合は、トランザクションが開始したことを確認して適宜コミットする責任をBeanプロバイダが持ちます。
セッションBeanとメッセージドリブンBeanのみがBMTを使用できます。
BMTを使用するEJBの開発時には、次の点を考慮します。
javax.transaction.UserTransactionのメソッドbeginおよびcommitを使用してトランザクションの境界を設定します。
トランザクションがビジネス・メソッドの終わりまでに完了しなかった場合、最終的にインスタンスがトランザクションを完了するまで、コンテナは複数のクライアント・コールにわたってトランザクションとインスタンス間の関連付けを保持します。
java.sqlConnectionのメソッドcommit、setAutoCommit、rollbackや、javax.jms.Sessionのメソッドcommit、rollbackなど、リソース・マネージャ固有のトランザクション管理メソッドを使用しないでください。
EJBContextのメソッドgetRollbackOnlyおよびsetRollbackOnlyを使用しないでください。UserTransactionのメソッドgetStatusおよびrollbackをかわりに使用する必要があります。
CMT（「コンテナ管理のトランザクションとは」を参照）を使用するEnterprise Beanでは、クライアントがBeanメソッドを起動したときにコンテナがトランザクションを管理する方法を決定するトランザクション属性を指定できます。
次のタイプのBeanメソッドごとにトランザクション属性を指定できます。
表2-6に、トランザクション属性の構成方法およびクライアント管理のトランザクションがメソッドの起動時に存在するかどうかに応じてEJBメソッド起動で使用されるトランザクション（存在する場合）を示します。
OC4Jはコンテナ管理のトランザクションを暗黙的に開始し、クライアント管理のトランザクションがない状態でBeanメソッドが起動されたときのトランザクション属性構成を満足させます。
| トランザクション属性 | クライアント管理のトランザクションが存在 | クライアント管理のトランザクションが存在しない |
|---|---|---|
|
Not Supported |
コンテナはクライアント・トランザクションを一時停止します。 |
トランザクションを使用しません。 |
|
Supports |
クライアント管理のトランザクションを使用します。 |
トランザクションを使用しません。 |
|
Required1 |
クライアント管理のトランザクションを使用します。 |
コンテナは新規トランザクションを開始します。 |
|
Requires New |
コンテナはクライアント・トランザクションを一時停止して新規トランザクションを開始します。 |
コンテナは新規トランザクションを開始します。 |
|
Mandatory |
クライアント管理のトランザクションを使用します。 |
例外が発生します。 |
|
Never |
例外が発生します。 |
トランザクションを使用しません。 |
|
1
（メモリー内またはファイルベースの）OEMS JMSメッセージ・サービス・プロバイダを使用するメッセージドリブンBeanでは、Oracle JMSコネクタを使用してこのメッセージ・サービス・プロバイダにアクセスする場合にのみRequiredがサポートされます。詳細は、「J2CAリソース・アダプタを使用せずにメッセージ・サービス・プロバイダにアクセスする場合の制限」を参照してください。 |
「トランザクションを使用しません」と示されている条件では、エンティティBeanを変更しないことをお薦めします。また、Supportsトランザクション属性を使用すると、クライアントがトランザクションを明示的に提供しない場合に非トランザクション状態になるため、このトランザクション属性の使用は避けることもお薦めします。
TopLink CMPを使用する場合、トランザクションはEJB 2.X CMPエンティティBeanを変更するために存在する必要があります。トランザクションが存在しない場合、TopLink永続性マネージャによってBeanの読取り専用コピーが返されます。
詳細は、次を参照してください。
トランザクションに関与しているすべてのリソースがXAに準拠している場合、OC4Jはグローバルまたは2フェーズ・コミット・トランザクションを自動的に調整します。
このリリースのOC4Jでは、推奨されないデータベース内調整に置き換わるトランザクション調整機能がOC4Jにあります。また、中間層コーディネータは異種対応であるため、OracleのみでなくすべてのXA互換リソースがサポートされます。
中間層コーディネータでは、次の機能がサポートされます。
詳細は、次を参照してください。
OC4Jが提供する次のようなJava EEセキュリティ・サービスを使用するようにEJBを構成できます。
詳細は、次を参照してください。
メッセージ・サービス・プロバイダは、クライアントがメッセージを送信できる送信先およびメッセージドリブンBeanが処理するメッセージを受信できる受信先を提供します。
OC4Jでは、XA対応の2フェーズ・コミット（2PC）トランザクションとXA非対応のトランザクションの両方で様々なメッセージ・サービス・プロバイダがサポートされます。
メッセージ・サービス・プロバイダには、直接アクセスするか、Oracle JMSコネクタなどのJ2EE Connector Architecture（J2CA）リソース・アダプタを通じてアクセスします。Oracle JMSコネクタの詳細は、「Oracle JMSコネクタ: J2EE Connector Architecture（J2CA）ベース・プロバイダ」を参照してください。
|
注意 メッセージ・サービス・プロバイダには、Oracle JMSコネクタなどのJ2CAリソース・アダプタを使用してアクセスすることをお薦めします。詳細は、「J2CAリソース・アダプタを使用せずにメッセージ・サービス・プロバイダにアクセスする場合の制限」を参照してください。 |
詳細は、次を参照してください。
OC4Jでは、MDBを次のOracle Enterprise Messaging Service（OEMS）プロバイダと組み合せて使用できます。
メッセージ・サービス・プロバイダには、Oracle JMSコネクタなどのJ2CAリソース・アダプタを使用してアクセスすることをお薦めします。詳細は、「J2CAリソース・アダプタを使用せずにメッセージ・サービス・プロバイダにアクセスする場合の制限」を参照してください。
注意
Oracle JMSコネクタは、J2CA 1.5準拠のリソース・アダプタです。この機能により、OC4J管理アプリケーションに対して、JMS 1.1または1.02bを実装する任意のJMSプロバイダにアクセスする統一メカニズムが提供されます。Oracle JMSコネクタを使用すると、図2-1に示すように、OC4JをOracleおよびOracle以外の様々なJMSプロバイダと統合できます。
OC4Jの観点からは、J2CAは、メッセージドリブンBeanで使用するためにメッセージ・サービス・プロバイダにアクセスする手段としてのみ使用されます。
Oracle JMSコネクタでは、2フェーズ・コミット（2PC）トランザクション用のXAファクトリと、2PCを必要としないトランザクション用の非XAファクトリの両方がサポートされます。
表2-7に、Oracle JMSコネクタでサポートされるJMSメッセージ・サービス・プロバイダをまとめます。
| JMSプロバイダ | バージョン |
|---|---|
|
すべて |
|
|
すべて |
|
|
IBM WebSphere MQベースのJMS |
サーバー・バージョン5.3および6.0 |
|
TIBCO Enterprise for JMS |
3.1.0 |
|
SonicMQ |
6.0 |
|
注意 メッセージ・サービス・プロバイダには、Oracle JMSコネクタなどのJ2CAリソース・アダプタを使用してアクセスすることをお薦めします。詳細は、「J2CAリソース・アダプタを使用せずにメッセージ・サービス・プロバイダにアクセスする場合の制限」を参照してください。 |
詳細は、次を参照してください。
OEMS JMSは、メモリー内またはファイルベースの永続性を提供するネイティブJava JMSプロバイダ実装であり、OC4Jと緊密に統合されています。これは、OC4Jに含まれているデフォルトのJMSプロバイダです。図2-2に、OC4J内に内部的に格納されているOEMS JMSのキューまたはトピックに、クライアントが非同期リクエストを直接送信する方法を示します。MDBはOEMS JMSからメッセージを直接受信します。
OEMS JMSには、直接アクセスするか、Oracle JMSコネクタ（「Oracle JMSコネクタ: J2EE Connector Architecture（J2CA）ベース・プロバイダ」を参照）を通じてアクセスできます。
|
注意 メッセージ・サービス・プロバイダには、Oracle JMSコネクタなどのJ2CAリソース・アダプタを使用してアクセスすることをお薦めします。詳細は、「J2CAリソース・アダプタを使用せずにメッセージ・サービス・プロバイダにアクセスする場合の制限」を参照してください。 |
OEMS JMSでは、2フェーズ・コミット（2PC）トランザクション用のXAファクトリと、2PCを必要としないトランザクション用の非XAファクトリの両方がサポートされます。2PCサポートの詳細は、「グローバル・トランザクションまたは2フェーズ・コミット（2PC）トランザクションへの参加方法」を参照してください。XAファクトリをサポートするようOEMS JMSを構成する方法の詳細は、「jms.xmlの構成」を参照してください。
詳細は、次を参照してください。
OEMS JMSデータベースは、Oracle Database Streamsアドバンスト・キューイング（AQ）機能へのJMSインタフェースです。Oracle AQは、Oracleデータベースの統合メッセージ・キューイング機能であり、Oracleデータベース内でインストールおよび構成するOracle Streams情報統合インフラストラクチャに構築されています（図2-3を参照）。
MDBはOEMS JMSデータベースを次のように使用します。
onMessageメソッドにルーティングされます。
クライアントはいつでも、MDBがリスニングしているOracle JMSのトピックまたはキューにメッセージを送信できます。Oracle JMSのトピックまたはキューは、データベースにあります。
Oracle JMSを使用する前に、データベースに適切なキューまたは表を作成しておく必要があります。
OEMS JMSデータベースには、直接アクセスするか、Oracle JMSコネクタ（「Oracle JMSコネクタ: J2EE Connector Architecture（J2CA）ベース・プロバイダ」を参照）を通じてアクセスできます。
|
注意 メッセージ・サービス・プロバイダには、Oracle JMSコネクタなどのJ2CAリソース・アダプタを使用してアクセスすることをお薦めします。詳細は、「J2CAリソース・アダプタを使用せずにメッセージ・サービス・プロバイダにアクセスする場合の制限」を参照してください。 |
OEMS JMSデータベースでは、2フェーズ・コミット（2PC）トランザクション用のXAファクトリと、2PCを必要としないトランザクション用の非XAファクトリの両方がサポートされます。2PCサポートの詳細は、「グローバル・トランザクションまたは2フェーズ・コミット（2PC）トランザクションへの参加方法」を参照してください。XAファクトリをサポートするようOEMS JMSを構成する方法の詳細は、「OEMS JMSデータベース・プロバイダのインストールと構成」に記載されている手順2を参照してください。
詳細は、次を参照してください。
メッセージ・サービス・プロバイダには、Oracle JMSコネクタなどのJ2CAリソース・アダプタを使用してアクセスすることをお薦めします（「Oracle JMSコネクタ: J2EE Connector Architecture（J2CA）ベース・プロバイダ」を参照）。
J2CAリソース・アダプタを使用しない場合、次の制限を考慮してください。
RequiredまたはRequiresNewに設定する場合、Oracle JMSコネクタを使用する必要があります。
JMSプロデューサまたはコンシューマがJ2CAベースのXAコネクション・ファクトリから導出されない場合、グローバル・トランザクションが存在してもそのトランザクションに登録されません。この場合、JMSは、グローバル・トランザクションの有効範囲外であるかのように動作します。これは、次のようにトランザクション・パラメータをtrueに設定して（J2CA以外の）JMSセッションを作成する場合でも同様です。
QueueConnection.createQueueSession(true,1)
この場合、グローバル・トランザクションとは無関係にSessionのメソッドcommitまたはrollbackを起動する必要があります。
|
注意 リリース10.1.3.1では、MDBでJ2CAおよびXAファクトリを使用している場合にのみ、OC4JによりデフォルトでMDB接続が自動登録されます。詳細は、「2フェーズ・コミット（2PC）XAトランザクションへのMDBの自動登録」を参照してください。 |
oc4j.jms.pseudoTransactionEnlistment下位互換性フラグを使用する場合にはサポートされません（「2フェーズ・コミット（2PC）XAトランザクションへのMDBの自動登録」を参照）。
図2-4に示すように、メッセージ・サービス・プロバイダ・オプションを構成する場合、
次の2つの方法があります。
原則として、アノテーションまたはXMLのどちらを選択するかにかかわらず、属性ではなくアクティブ化構成プロパティを使用することをお薦めします。
アノテーションを使用する場合、@MessageDrivenDeploymentまたは@MessageDrivenアノテーションを使用してメッセージ・サービス・オプションを構成できます。@MessageDrivenDeployment構成は、@MessageDriven構成をオーバーライドします。
@MessageDrivenDeploymentを使用する場合、ネストされた@ActivationConfigPropertyアノテーションを使用するか、@MessageDrivenDeploymentの属性を使用してメッセージ・サービス・オプションを構成できます。@ActivationConfigProperty構成は、@MessageDrivenDeploymentの属性をオーバーライドします。
@MessageDrivenを使用する場合、ネストされた@ActivationConfigPropertyアノテーションのみを使用してメッセージ・サービス・オプションを構成できます。
@MessageDrivenDeploymentの属性を使用した構成の場合、アプリケーションでは、J2CAリソース・アダプタなしでメッセージ・サービス・プロバイダにアクセスすることのみ可能です。後からJ2CAリソース・アダプタを使用してメッセージ・サービス・プロバイダにアクセスすると、アプリケーションはデプロイに失敗します。ネストされた@ActivationConfigPropertyアノテーションを使用した構成の場合、アプリケーションでは、J2CAリソース・アダプタの有無にかかわらずメッセージ・サービス・プロバイダにアクセスできます。アノテーションを使用して構成する場合、@ActivationConfigPropertyによる方法を使用することをお薦めします。
例2-6に、@ActivationConfigPropertyアノテーションを使用した@MessageDrivenDeploymentおよび@MessageDrivenアノテーションによるメッセージ・サービス構成を示します。@MessageDrivenDeploymentアノテーションのDestinationNameアクティブ化構成プロパティは、@MessageDrivenアノテーションの同じプロパティをオーバーライドします。
import javax.ejb.MessageDriven;
import oracle.j2ee.ejb.MessageDrivenDeployment;
import javax.ejb.ActivationConfigProperty;
import javax.jms.Message;
import javax.jms.MessageListener;
@MessageDriven(
activationConfig = {
@ActivationConfigProperty(
propertyName="DestinationName", propertyValue="OracleASjms/MyQueue"
)
}
)
@MessageDrivenDeployment(
activationConfig = {
@ActivationConfigProperty(
propertyName="DestinationName", propertyValue="OracleASjms/DeployedQueue"
),
@ActivationConfigProperty(
propertyName="ResourceAdapter", propertyValue="OracleASjms"
)
}
)
public class JCAQueueMDB implements MessageListener
{
public void onMessage(Message msg) {
...
}
}
XMLを使用する場合、orion-ejb-jar.xmlファイルの<message-driven-deployment>要素またはejb-jar.xmlファイルの<message-driven>要素を使用してメッセージ・サービス・オプションを構成できます。orion-ejb-jar.xml構成は、ejb-jar.xml構成をオーバーライドします。
orion-ejb-jar.xmlファイルの<message-driven-deployment>要素を使用する場合、ネストされた<config-property>要素を使用するか、<message-driven-deployment>の属性を使用してメッセージ・サービス・オプションを構成できます。<config-property>構成は、<message-driven-deployment>の属性をオーバーライドします。
ejb-jar.xmlファイルの<message-driven>要素を使用する場合、ネストされた<activation-config-property>要素のみを使用してメッセージ・サービス・オプションを構成できます。
orion-ejb-jar.xmlファイルの<message-driven-deployment>要素の属性を使用した構成の場合、アプリケーションでは、J2CAリソース・アダプタなしでメッセージ・サービス・プロバイダにアクセスすることのみ可能です。後からJ2CAリソース・アダプタを使用してメッセージ・サービス・プロバイダにアクセスすると、アプリケーションはデプロイに失敗します。ネストされた<config-property>要素を使用した構成の場合、アプリケーションでは、J2CAリソース・アダプタの有無にかかわらずメッセージ・サービス・プロバイダにアクセスできます。XMLを使用して構成する場合、<config-property>による方法を使用することをお薦めします。
例2-8に、orion-ejb-jar.xmlファイルの<message-driven-deployment>要素で<config-property>要素を使用する方法を示します。また、例2-7に、ejb-jar.xmlファイルの<message-driven>要素で<activation-config-property>要素を使用する方法を示します。<message-driven-deployment>要素のDestinationNameアクティブ化構成プロパティは、<message-driven>要素の同じプロパティをオーバーライドします。また、ejb-jar.xmlファイルの<message-driven>要素では、<activation-config-property>要素が<activation-config>要素に含まれます。
<message-driven>
<ejb-name>JCA_QueueMDB</ejb-name>
<ejb-class>test.JCA_MDB</ejb-class>
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Container</transaction-type>
...
<activation-config>
<activation-config-property>
<activation-config-property-name>
DestinationName
</activation-config-property-name>
<activation-config-property-value>
OracleASJMSSubcontext
</activation-config-property-value>
</activation-config-property>
</activation-config>
...
</message-driven>
例2-8 orion-ejb-jar.xmlの<config-property>
<message-driven-deployment
name="JCA_QueueMDB"
resource-adapter="OracleASjms">
...
<config-property>
<config-property-name>
DestinationName
</config-property-name>
<config-property-value>
OracleASJMSRASubcontext
</config-property-value>
</config-property>
...
</message-driven-deployment>
OC4Jでは、XA対応リソースで2PCトランザクションがサポートされます（「グローバル・トランザクションまたは2フェーズ・コミット（2PC）トランザクションへの参加方法」を参照）。
|
注意 リリース10.1.3.1では、MDBでJ2CAおよびXAファクトリを使用している場合にのみ、OC4JによりデフォルトでMDB接続が自動登録されます。詳細は、「2フェーズ・コミット（2PC）XAトランザクションへのMDBの自動登録」を参照してください。 |
XA準拠のJMSメッセージ・サービス・プロバイダを構成する方法の詳細は、次を参照してください。
リリース10.1.2および10.1.3.0のOC4Jでは、通常の非XA JMSコネクションとXA JMSコネクションの両方が、ネイティブOEMS JMSプロバイダにより自動的にOC4Jグローバル・トランザクションに登録されていました。リリース10.1.3.1では、XA JMSコネクションも通常のJMSコネクションもOC4Jグローバル・トランザクションに登録されません。付属のJMS APIを使用する場合、OEMS JMSのjavax.jms.XA*実装を使用してXA接続を明示的にOC4Jグローバル・トランザクションに登録する必要があります。また、非XA JMSコネクションから作成された特定のJMSセッションのローカル・トランザクションも、明示的にコミットまたはロールバックする必要があります。
下位互換性を確保する目的から、リリース10.1.3.1でも自動登録機能を使用することは可能です（ただし非推奨）。自動登録はデフォルトで無効化されていますが、グローバルOC4Jシステム・プロパティoc4j.jms.pseudoTransactionEnlistmentをtrueに設定することで有効化できます。
XAコネクション・ファクトリを使用する（したがってXAセッションを作成する）ように構成されたJ2CA MDBは、通常の動作として自動登録されます。非XAファクトリで作成されたセッションは、登録されません。oc4j.jms.pseudoTransactionEnlistmentプロパティは、非XAセッションを強制的に登録する場合にのみ必要です。この設定は、主にJ2CAを使用しないレガシー・アプリケーションに関連します。
詳細は、『Oracle Containers for J2EEサービス・ガイド』の「Java Message Service（JMS）」を参照してください。
Oracle Application Serverには、クラスタリングなどの高可用性およびフェイルオーバー・オプションの広範なスイートが用意されています。クラスタリングでは、適切なホスト間通信手段が構成された複数のホストにアプリケーション・サーバーおよびエンドユーザー・アプリケーション・コンポーネントが分散されます。
OC4Jアプリケーション・クラスタリングは、HTTPセッションおよびステートフル・セッションBeanで使用可能な状態管理サービスです。このコンテキストでは、クラスタは、同じアプリケーション・セットをホスティングしている2つ以上のOC4Jサーバー・ノードとして定義されます。このリリースでは、構成が単純化され、HTTPセッションとステートフル・セッションBeanの両方に対して同一になっています。
トランザクションはフェイルオーバーできません。中断されたトランザクションを別のBeanに再インスタンス化する機能はありません。かわりに、トランザクションはロールバックされるため、最初からやりなおす必要があります。詳細は、「EJBトランザクション・サービスについて」を参照してください。
ステートフル・セッションBeanのクラスタリングのパフォーマンスは、選択するレプリケーションのタイプ（「状態レプリケーション」を参照）およびロード・バランシング（「ロード・バランシング」を参照）のオプションによって変わります。
レプリケーション頻度と堅牢性のバランスを適切に選択する必要があります。レプリケートの頻度が高いほど、状態が失われる可能性のある期間が短くなりますが、アプリケーション・サーバーとネットワークに対する負荷が高くなります。
この項では、次のようなステートフル・セッションBeanのOC4Jアプリケーション・クラスタリングについて説明します。
詳細は、次を参照してください。
クラスタリングされたOC4J EJBアプリケーションのレプリケーション・ポリシーを構成する場合、OC4Jはステートフル・セッションBeanインスタンスに含まれているオブジェクトと値のレプリケーションを処理します。クラスタリングできるのはステートフル・セッションBeanのみです。ステートレス・セッションBeanにはレプリケートする状態がないため、クラスタリングする必要はありません。
フェイルオーバーを利用するにはレプリケーション・ポリシーを構成する必要があります。元のBeanが予期せず終了した場合にリクエストがクラスタ内の別のOC4Jプロセスに透過的に転送されるように、Beanの状態がレプリケートされる必要があります。ロード・バランシングのみ利用する場合は、レプリケーションは不要です（「ロード・バランシング」を参照）。
レプリケーション・ポリシーによって、状態レプリケーション・トリガー（Bean状態がクラスタ内の他のすべてのOC4Jプロセスにブロードキャストされる条件）が決定されます。ステートフル・セッションBeanの場合、レプリケーションがトリガーされると、ステートフル・セッションBeanのすべての属性が（変更されたかどうかに関係なく）レプリケートされます。
レプリケーションは、アプリケーション・サーバーおよびネットワーク・パフォーマンスに影響することがあります。状態を送信する回数が少ないほど、パフォーマンスは向上します。ただし、パフォーマンスと、Beanインスタンスの障害の全範囲を対象とするようにBeanの状態がレプリケートされる確実性との間にはトレードオフがあります。
詳細は、次を参照してください。
ロード・バランシングは、着信クライアント・リクエストがクラスタ内のすべてのOC4Jインスタンスに配布される方法を表します。次のロード・バランシング計画から選択できます。
すべてのロード・バランシング計画において、クライアントのリクエストをクラスタ内のOC4Jインスタンス間でロード・バランシングする方法を構成できます（「ロード・バランシングの動作の構成」を参照）。
指定時刻、指定した時間の経過後または指定間隔でタイムアウト・コールバック・メソッドを起動するタイマーを設定できます。
EJB 3.0アプリケーションでは、@Timeoutアノテーションを使用して、EJBメソッドをタイムアウト・コールバック・メソッドとして指定できます。
EJB 2.1アプリケーションでは、EJBでTimedObjectインタフェースを実装し、ejbTimeoutというタイムアウト・コールバック・メソッドを提供する必要があります。
タイマーは、アプリケーションレベルのプロセスのモデリング用です。リアルタイムのイベントには使用しません。
OC4Jには、標準のJava EEタイマー以外に、UNIXのcronユーティリティと同様の構成を可能にするJava EEタイマーの便利な拡張機能が付属します。
詳細は、次を参照してください。
タイマーとタイムアウト・コールバック・メソッドは、トランザクション内でコールされる必要があります。OC4Jでは、タイムアウト・コールバック用にREQUIRES_NEWトランザクション属性がサポートされます。トランザクション属性の詳細は、「クライアントがビジネス・メソッドを起動する際のトランザクションの処理方法」を参照してください。
Enterprise Beanは、依存性注入、EJBContextインタフェースまたはJNDIネームスペースのルックアップによってEJBタイマー・サービスにアクセスします。
詳細は、第25章「タイマー・サービスの構成」を参照してください。
EJBタイマー・サービスは、時間ベースのイベントを対象にスケジュールされるEJBのコールバック・メソッドを定義するためのコンテナ管理のサービスです。EJBタイマー・サービスには、時間指定されたイベントに対する信頼性のあるトランザクション通知サービスが用意されています。タイマー通知は、指定時刻、指定した時間の経過後または特定の反復間隔で行うようにスケジュールできます。EJBのコールバック・メソッドを定義して、これらの時間ベースのイベントを受信できます。Java EEタイマー・サービスは、OC4Jにより実装されます。
詳細は、「Java EEタイマーを使用するEnterprise Beanの構成」を参照してください。
UNIXでは、指定された間隔で定期的に実行されるようにcronタイマーをスケジュールできます。オラクル社は、EJBでcronタイマーをサポートするようにOC4Jを拡張しました。OC4JにデプロイされるEJBとともにタイマー・イベントをスケジュールするためにcron式を使用できます。OC4Jのcronタイマーを使用すると、タイムアウト・コールバック・メソッドまたは任意のJavaクラスのmainメソッドを起動するタイマーを作成できます。
詳細は、「OC4J cronタイマーを使用するEnterprise Beanの構成」を参照してください。
|
 Copyright © 2002, 2008 Oracle Corporation. All Rights Reserved. |
|