ヘッダーをスキップ
Oracle Containers for J2EEサービス・ガイド
10g（10.1.3.5.0）
B56027-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

3 OC4Jトランザクション・サポート

この章では、Oracle Containers for J2EE（OC4J）のトランザクション・サポートについて説明します。この章には、次の項目が含まれます。

トランザクション管理タスク

この章では、次のトランザクション管理タスクについて説明します。

トランザクション・コーディネータの構成

データベース内トランザクション・コーディネータの考慮事項

トランザクションの境界設定の管理（「トランザクションの境界設定」を参照）

手動によるコミットおよびロールバック操作

OC4Jトランザクション・マネージャの監視

新機能

次のOC4Jトランザクション・サポートの機能および動作は、今回のリリースの新機能です。

本番環境でOC4Jを使用する前に

本番環境でOC4Jを使用する前に、次のタスクを実行することをお薦めします。

追加ドキュメント

次のサイトにあるHow-Toドキュメントでは、OC4Jの機能に関する情報（各機能の概要や機能に関連するコードの抜粋など）を提供しています。

http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/index.html

OC4Jトランザクション・サポートの概要

Java Transaction API（JTA）は、J2EE環境でグローバル（分散）トランザクションをサポートするためにSun社が開発した仕様です。グローバル・トランザクションでは、データベースやメッセージ・キューなどの複数のエンタープライズ・システムが単一の作業ユニットに統合されます。

JTAにより、Open Groupの分散トランザクション処理モデルに基づく仕様がJava環境にマップされます。Open GroupのXA仕様は、トランザクション・マネージャとリソース・マネージャ間のインタフェースを定義しています。JTA仕様は、アプリケーションとトランザクション・マネージャ間のインタフェースを定義しています。

JTA仕様は、http://java.sun.com/products/jtaで入手できます。

トランザクションとは

トランザクションは、状態の変化するシステムにおいて正確な出力結果を保証するためのメカニズムです。プログラマは、トランザクションを使用することで、システム内の多くの状態変化を単一の作業ユニットとして把握できます。JTAトランザクションは、リソースの登録およびトランザクション境界設定で構成されます。トランザクション・スコープ内で発生した変更は、コミットまたはロールバックできます。

一般的に、トランザクションは、アプリケーションによって開始されます。アプリケーションは、共有リソース（1つ以上のデータベース・システムなど）に対してなんらかの作業を実行し、そのトランザクションをコミットします。コンテナ管理のトランザクションの場合、トランザクションはアプリケーション・サーバーによって開始されます。

J2EEでのトランザクション処理の詳細は、次の書籍を参照してください。

Little、Maron、Pavlik著『Java Transaction Processing: Design and Implementation』（Prentice Hall、2004）

ACID

J2EEおよび多くの主要な情報管理システムによってサポートされるトランザクション・モデルは、次に示すACID特性を保持するよう設計されているのが普通です。

システムのインフラストラクチャ自体では、これらすべての特性を保証できないことに注意してください。一貫性の特性を確保するには、整合性のある変更をシステムに加えるアプリケーション・ロジックが必要です。たとえば、人事管理データベースに人ではなく惑星を表す識別子を挿入するトランザクション・ロジックがあるとすると、一貫性のない結果が出力されます（もっとも、アプリケーション・サーバーとデータベースで惑星名が意味のない値であると判別する方法はまずありませんが）。

ACIDを確保することで、インフラストラクチャとアプリケーションに負荷がかかることにも注意してください。ACIDのオーバーヘッドを抑える必要がある場合は、できるかぎり単一のローカル・リソースのみを使用し、2フェーズ・コミットを使用しないように作業を設計します。

中間層2フェーズ・コミット（2PC）コーディネータ

今回のリリースでは、トランザクション調整機能はOC4Jに組み込まれています。置き換えられたデータベース内の調整機能は、非推奨になりました。また、中間層コーディネータは、異機種間環境対応となり、OracleリソースだけでなくすべてのXA互換リソースをサポートします。

中間層コーディネータの機能は、次のとおりです。

図3-1「新規の中間層コーディネータと非推奨のデータベース内コーディネータの比較」 に、新規の中間層コーディネータと、非推奨のデータベース内コーディネータの違いを示します。

図3-1 新規の中間層コーディネータと非推奨のデータベース内コーディネータの比較

新規の中間層コーディネータを示しています

ローカルおよびグローバル・トランザクション

トランザクションの複雑さは、アプリケーションがトランザクション内に登録するリソースの数によって決まります。

ローカル・トランザクションには、1つのリソースのみが含まれます。トランザクション・アクティビティのスコープ設定と調整は、リソース自体に対してローカルに実行されます。ローカル・トランザクションでは、1フェーズ・コミット（1pc）プロトコルが使用されます。

グローバル・トランザクション（分散トランザクション）では、トランザクション内に複数のリソースが登録されます。たとえば、グローバル・トランザクションは、2つのデータベースを作業範囲とする場合に使用できます。グローバル・トランザクションをサポートするトランザクション処理システムには、通常、複数の異なる論理コンポーネント（トランザクション・ファクトリ、リソース・マネージャ、コーディネータ、アプリケーションなど）が含まれます。グローバル・トランザクションでは、結果の原子性を保証するため、2フェーズ・コミット（2pc）プロトコルという終了プロトコルが使用されます。

2フェーズ・コミット・プロトコル

2フェーズ・コミット（2pc）プロトコルは、グローバル・トランザクションの複数の参加者が同意に至るためのメカニズムです。このプロトコルは、その名前が示すとおり、2つのフェーズに分けられます。最初のフェーズは、通常、投票フェーズと呼ばれます。各参加者は、トランザクション作業をコミットする準備ができているかどうかを尋ねられます。作業をコミットできる参加者は、コミット可能であるという投票メッセージをコーディネータに送信します。

投票の結果、トランザクションのコミット準備ができていない参加者が1つでも存在する場合は、すべての参加者がロールバックの指示を受けます。

ACID特性を保証するため、一部のトランザクション・システムでは、2フェーズ・コミット・プロトコルと2フェーズ・ロック・プロトコルを組み合せています。具体的には、準備フェーズが開始すると、トランザクション内で作業を実行できなくなります。

2フェーズ・コミット・プロトコルでは、システム障害時に結果の原子性を保証するため、トランザクション・マネージャでトランザクションの進捗状況を記録する必要があります。

複数のリソースの使用方法

各リソースは、トランザクションのスコープ内で使用されるときに、アプリケーション・サーバーによって自動的に登録されます。ただし、2フェーズ・コミット・トランザクションでACID特性を保証するには、参加するすべてのリソースがXAに準拠している必要があります（最終リソース・コミットによる最適化の場合を除く）。

最終リソース・コミット

最終リソース・コミットでは、XAに準拠しない単一のリソースがXAトランザクションに参加できます。XAに準拠しない複数のリソースをトランザクションに登録すると、登録試行時に例外がスローされます。

準備フェーズでは、すべてのXA準拠リソースが準備を行います。すべてのXAリソースが準備OKの通知を戻すと、コーディネータは、XAに準拠しないリソースに制御を移します。XAに準拠しないリソースがコミット終了の通知を戻した場合、コーディネータはコミット決定をログに記録し、そうでない場合はロールバック決定を記録します。次に、コーディネータは、すべてのXAリソースにその決定を通知します。


注意:

最終リソース・コミットによる最適化は、ほとんどの場合に適切に動作しますが、この最適化を使用する場合には若干のリスクが伴います。XAに準拠しないリソースへの制御の移行中に障害が発生した場合、コーディネータには、そのリソースがコミットされたかロールバックされたかを認識する方法がありません。これにより、結果の原子性が失われ、調整が非常に困難となる可能性があります。

最終リソース・コミットによる最適化では、単一の1フェーズ・コミット・リソースのみが特定のトランザクションへの登録を許可されるため、OC4Jでは、1フェーズ・コミット・リソースの登録をルートOC4Jプロセスに制限しています。1フェース・コミット・リソースをOC4Jの下位プロセスで登録しようとすると、サーバーがリソースを登録できなかったという例外がスローされます。この制限が必要とされる理由は、最終リソース・コミットによる最適化を使用する場合、1フェーズ・コミット・リソースの登録を下位プロセスに許可すると、グローバル・トランザクション・ツリーに登録されている1フェーズ・コミット・リソースが1つのみであることを保証する処理でオーバーヘッドが発生するためです。


注意:

  • トランザクション・ロギングをnoneに設定すると、XAに準拠しない複数のリソースをグローバル・トランザクションに登録できますが、この場合ACID特性やリカバリ可能性は保証されません。トランザクション・ロギングの設定方法は、「トランザクション・コーディネータの構成」を参照してください。

  • トランザクション・マネージャで永続ストアを使用しない場合、下位ノードでの登録が許可されます。

最終リソース・コミットを使用するには、トランザクション・マネージャで永続ストアを構成してトランザクション・ロギングを有効化します。永続ストア（およびロギング）は、デフォルトでは無効化されています。「トランザクション・コーディネータの構成」を参照してください。

単一の非XAリソースによるグローバル・トランザクションへの参加が可能になると同時に、最終リソース・コミットは、最適化の手段としても使用できます。XA準拠リソースを非XAリソースとして登録し、最終リソース・コミットを使用すると、パフォーマンスが向上します。これは、リソースでロギングを実行する必要がなくなり、コーディネータのリソースに対するコールが2つではなく1つのみとなってネットワーク・コールが減少するためです。また、リソースが不明（インダウト）状態とならないため、リソースのロックを防ぐことができます。ただし、最終リソース・コミットは、パフォーマンスの最適化に使用できますが、かわりに正確さの保証は失われます。

OC4Jの最終リソース・コミット機能の詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』の「トランザクション管理」を参照してください。

リソース・マネージャ

リソース・マネージャは、共有リソースの管理を担当します。リソース・マネージャの一般的な例は、リレーショナル・データベース・システムです。

トランザクション・マネージャ

トランザクション・マネージャは、トランザクション・ファクトリとコーディネータの両方の役割を担います。アプリケーションは、トランザクション・マネージャと通信して、トランザクションの開始と終了およびリソースの登録を行います。アプリケーションがトランザクションのコミットをリクエストすると、トランザクション・マネージャは、2フェーズ・コミット・プロトコルを調整します。

ヒューリスティック

全体の一致を必要とするため、2フェーズ・コミットは、ブロック・プロトコルです。つまり、最終フェーズのメッセージを配信する前にコーディネータで障害が発生した場合、各参加者は、ブロックされた状態のままリソースを保持する必要があります。最新のトランザクション・システムでは、このような参加者がコミットまたはロールバックの実行を一方的に決定できるように、2フェーズ・コミットにヒューリスティック（経験則）機能が追加されています。ある参加者の決定が、最終的に別の参加者の決定と一致しなかった場合、原子性に欠ける動作が発生します。通常、これらの決定は、管理的な操作により実行されます。「手動によるコミットおよびロールバック操作」を参照してください。

Synchronization

Synchronizationは、トランザクションに登録され、2フェーズ・コミット・プロトコルの実行前後に通知されるオブジェクトです。たとえば、アプリケーションは、独自の状態を保持しており、必要に応じて（またはトランザクション完了前に）キャッシュをリソースに永続化して、完了後はリソースを解放するのが普通です。

Synchronizationは、UserTransactionインタフェースからは使用できないため、アプリケーションではSynchronizationを直接登録できません。この操作は、アプリケーション・サーバーでのみ実行できます。CMPの場合は、永続性レイヤーがこの操作を処理します。

EJBの詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。

プログラミング・モデル: コンテナ管理およびBean管理のトランザクション

Enterprise JavaBeansでは、コンテナ管理のトランザクションまたはBean管理のトランザクションを通じたトランザクション管理に、JTA 1.0.1Bを使用します。


注意:

コンテナ管理のトランザクションは、宣言型のトランザクションまたはCMTとも呼ばれます。

Bean管理のトランザクションは、プログラム的なトランザクションまたはBMTとも呼ばれます。

コンテナ管理のトランザクション

コンテナ管理のトランザクションは、コンテナによって制御されます。つまり、コンテナは、デプロイメント・ディスクリプタ内の定義に従って、既存のトランザクションと結合するか、アプリケーション用に新しいトランザクションを起動します。新規に作成されたトランザクションは、Beanメソッドが完了すると終了します。トランザクションを管理するために、実装でコードを提供する必要はありません。

Bean管理のトランザクション

Bean管理のトランザクションは、Bean実装内でプログラムによって境界設定されます。トランザクション境界は、アプリケーションによって完全に制御されます。

トランザクションの境界設定

トランザクションの境界設定とは、トランザクションの開始と終了の区切りを意味します。

トランザクション境界をユーザー自身が設定するには、BeanをBean管理のトランザクションとして指定します。トランザクション境界の設定をコンテナに任せるには、EJBデプロイメント・ディスクリプタにトランザクション属性を設定して、Beanをコンテナ管理のトランザクションとして指定します。

コンテナ管理のトランザクションは、すべてのEJBで使用できます。ただし、Bean管理のトランザクションは、セッションBeanとメッセージドリブンBean（MDB）でのみ使用できます。つまり、データ・アクセス用に設計されているエンティティBeanでは、コンテナ管理のトランザクションによる境界設定を使用する必要があります。セッションBeanでは、どちらのモデルも使用できます。


注意:

トランザクション境界は、アプリケーション・クライアント・コンテナからは設定できません。

境界設定のタイプは、Beanのデプロイメント・ディスクリプタに指定します。次の例に、<transaction-type>要素にContainerと指定して、セッションBeanをコンテナ管理のトランザクションとして宣言する方法を示します。Beanを構成してBean管理のトランザクション境界を設定するには、<transaction-type>要素にBeanと指定します。

例: コンテナ管理のトランザクションとして宣言されるセッションBean

</session>
  <description>no description</description>
  <ejb-name>myEmployee</ejb-name>
  <home>cmtxn.ejb.EmployeeHome</home>
  <remote>cmtxn.ejb.Employee</remote>
  <ejb-class>cmtxn.ejb.EmployeeBean</ejb-class>
  <session-type>Stateful</session-type>
  <transaction-type>Container</transaction-type>
  <resource-ref>
   <res-ref-name>jdbc/OracleMappedDS</res-ref-name>
   <res-type>javax.sql.DataSource</res-type>
   <res-auth>Application</res-auth>
  </resource-ref>
</session>

コンテナ管理のトランザクションの境界設定

コンテナ管理のトランザクション（CMT）を使用するようにBeanを定義する場合、後述の例に示すとおり、コンテナによるBeanのJTAトランザクションの管理方法を、Beanのデプロイメント・ディスクリプタの<trans-attribute>要素に指定する必要があります。次の表に、トランザクション属性の設定とその説明を示します。

表3-1<trans-attribute>要素の設定

設定 説明

NotSupported

Beanはトランザクションに関連しません。

Beanの実行者が、トランザクションに関連しているときにBeanをコールすると、実行者のトランザクションが一時停止され、Beanが実行されます。Beanが戻ると、実行者のトランザクションが再開されます。

メッセージドリブンBean（MDB）の場合、この設定がデフォルトです。

Required

Beanはトランザクションに関連している必要があります。

実行者がトランザクションに関連している場合は、実行者のトランザクションが使用されます。

実行者がトランザクションに関連していない場合は、コンテナによってそのBean用の新規トランザクションが開始されます。これはデフォルト設定です。

CMP 2.0エンティティBeanの場合、この設定がデフォルトです。

Supports

実行者が関連しているトランザクションの状態にかかわらず、そのトランザクションがBeanに使用されます。

実行者がトランザクションを開始している場合は、実行者のトランザクション・コンテキストが使用されます。

実行者がトランザクションに関連していない場合は、Beanも関連しません。

これは、CMP 2.0エンティティBeanとMDBを除くすべてのエンティティBeanのデフォルト設定です。

RequiresNew

実行者がトランザクションに関連しているかどうかに関係なく、そのBeanに対してのみ存在する新規トランザクションが開始されます。

実行者が、トランザクションに関連しているときにBeanをコールすると、実行者のトランザクションはBeanが完了するまで一時停止されます。

Mandatory

このBeanを起動する前に、実行者がトランザクションに関連している必要があります。Beanには、実行者のトランザクション・コンテキストが使用されます。

Never

Beanはトランザクションに関連しません。さらに、Beanコール中、実行者がトランザクションに関連することはありません。

実行者がトランザクションに関連している場合は、RemoteExceptionがスローされます。


注意:

各タイプのエンティティBeanに対応するデフォルトの<trans-attribute>設定は、次のとおりです。

  • CMP 2.0のエンティティBeanの場合、デフォルトはRequiredです。

  • MDBの場合、デフォルトはNotSupportedです。

  • 他のすべてのエンティティBeanの場合、デフォルトはSupportsです。

次の例に、EJBデプロイメント・ディスクリプタの<container-transaction>部分を示します。この例では、myEmployee EJBのすべての（*）メソッドに対してRequiresNewトランザクション属性を指定しています。

例: デプロイメント・ディスクリプタの<container-transaction>

   <assembly-descriptor>
      <container-transaction>
         <description>no description</description>
         <method>
            <ejb-name>myEmployee</ejb-name>
            <method-name>*</method-name>
         </method>
        <trans-attribute>RequiresNew</trans-attribute>
      </container-transaction>
   </assembly-descriptor>

トランザクションの開始、コミットまたはロールバックにBean実装は必要ありません。これらの操作は、デプロイメント・ディスクリプタに指定したトランザクション属性に基づいて、コンテナによって処理されます。

Bean管理のトランザクションの境界設定

Webコンポーネント（JSPおよびサーブレット）と、ステートレスおよびステートフル・セッションBeanでは、プログラムによるトランザクション境界設定を使用できます。エンティティBeanでは、この方法は使用できないため、コンテナ管理によるトランザクション境界設定を使用する必要があります。


注意:

クライアント・サイドのトランザクション境界設定は、アプリケーション・クライアント・コンテナではサポートされません。OC4Jでは、クライアント・サイドのトランザクション境界設定はサポートされません。この形式のトランザクション境界設定は、J2EE仕様の要件となっておらず、パフォーマンスと待機時間にも影響があるため、お薦めしません。

デプロイメント・ディスクリプタの<transaction-type>要素内でBeanをBean管理のトランザクション（BMT）として宣言する場合、グローバル・トランザクションの開始、コミットまたはロールバックの境界は、Bean実装によって設定する必要があります。

Bean管理の（プログラムによる）トランザクション境界設定を使用する場合、Bean開発者は、UserTransactionインタフェースを使用してグローバル・トランザクション境界を設定するか、RM固有のメソッドを使用してRMのローカル・トランザクション境界を設定することが可能です。

WebコンポーネントまたはBeanの開発者は、次の例に示すとおり、UserTransactionインタフェースのbegin()、commit()およびrollback()メソッドを明示的に発行する必要があります。

Context initCtx = new Initial Context();
ut = (UserTransaction)  initCtx.lookup("java:comp/UserTransaction");

ut.begin();
// Do work.
…
try {
    // Commit the transaction.
    ut.commit();
// Handle exceptions.  Should really catch specific exceptions, not Exception
} catch (Exception ex) { … }

初期コンテキストを作成するかわりに、@Resource注釈を使用してリソース・インジェクションをリクエストすることも可能です。そのような場合、ルックアップは実行時に自動的に行われます。例:

@Resource

begin(); // Do work. …try {    // Commit the transaction.

   commit();

// Handle exceptions. Should really catch specific exceptions, not Exception} catch (Exception ex) { … }

トランザクション・コーディネータの構成

この項では、2PCトランザクション・コーディネータの構成方法を説明します。この章には、次の項目が含まれます。

トランザクション・コーディネータは、Oracle Enterprise Manager 10g Application Server Controlコンソールまたはトランザクション・マネージャの構成ファイル（J2EE_HOME/config/transaction-manager.xml）を使用して構成されます。この項では、コンソールを使用する方法を主に説明します。

トランザクション・コーディネータの定義

トランザクション・コーディネータは、トランザクション・マネージャ・タスクまたはJTAResource MBeanを使用して定義できます。どちらもApplication Server Controlコンソールの「管理」タブからアクセスできます。

トランザクション・コーディネータの構成時には、変更内容を反映するためにサーバーを再起動する必要があります。また、停止前にすべてのトランクションをパージする必要があります。パージされていないトランザクションがある場合、サーバーは、それが管理者により解決されるまで待機します。トランザクション中にサーバーが強制的に停止され、インダウト状態が続いている場合、構成の変更は保存されません。

トランザクション・マネージャ・タスク

トランザクション・マネージャ・タスクを使用してトランザクション・コーディネータを構成するには、次のようにします。

  1. Application Server Controlコンソールにログインし、「OC4J: ホーム」→「管理」→「タスク名: サービス」→「トランザクション・マネージャ(JTA)」→「タスクに移動」と操作します。

  2. 「管理」をクリックします。

  3. 表3-2の説明を参照してコーディネータのフィールドを入力します。

  4. 「適用」をクリックします。

  5. OC4Jを再起動します。

JTAResource MBean

JTAResource MBeanを使用してトランザクション・コーディネータを構成するには、次のようにします。

  1. Application Server Controlコンソールにログインし、「OC4J: ホーム」→「管理」→「タスク名: JMX」→「システムMBeanブラウザ: タスクに移動」→「JTAResource」→「oc4j-tm」と操作します。

  2. 「操作」をクリックします。

  3. 操作のリストから、「configureCoordinator」をクリックします。「操作」画面が表示されます。

  4. 表3-2の説明を参照してフィールドに入力します。

  5. 「起動操作」をクリックします。

  6. OC4Jを再起動します。

表3-2 トランザクション・コーディネータのパラメータ

パラメータ 説明

commitCoordinator

2フェーズ・コミット・コーディネータのタイプ（databaseまたはmiddle-tier）。

データベース内コーディネータの使用は、OC4Jでは推奨されていません。今後は、中間層コーディネータを使用することをお薦めします。詳細は、「データベース内トランザクション・コーディネータの考慮事項」を参照してください。

logType

ログ・タイプ（none、fileまたはdatabase）。この設定は、commitCoordinatorがmiddle-tierの場合にのみ適用されます。

logLocation

ログの場所。ファイルの場合はディレクトリ・パスを、データベース・ロギングの場合はJNDIロケーションを指定します。

userName

データベース・ユーザー名。

password

データベース・パスワード。

retryCount

コーディネータがリソース・マネージャに対して同期的にコマンドを再試行する回数（有効な場合）。再試行は、たとえばリソース・マネージャがXA_RETRYを戻した場合に発生する可能性があります。

コーディネータ属性の設定

トランザクション・コーディネータには、実行時のパフォーマンスの制御に使用される属性が複数含まれています。属性への変更はすぐに反映されるため、サーバーの再起動は不要です。

汎用属性

トランザクション・コーディネータには、トランザクション・マネージャ・タスクまたはJTAResource MBeanを使用して定義できる属性が2つあります。表3-3で、汎用属性を説明します。

表3-3 汎用属性

属性 説明

transactionTimeout

デフォルトのトランザクション・タイムアウト（秒単位）

maxConcurrentTransactions

システム例外をスローせずに実行できるサーバー内の同時トランザクションの最大数。（-1は無制限であることを示します。）

ファイル・ストア・ログの属性

ファイル・ストア・ログの属性は、トランザクション・コーディネータのファイル・ストア・ロギングを使用している際に、ファイル・ストアのパフォーマンスの制御に使用されます。属性を変更するには、JTAResource MBeanを使用するか、transaction-manager.xmlファイルを手動で編集する必要があります。表3-4で、ファイル・ストア・ログの属性を説明します。

表3-4 ファイル・ストア・ロギングの属性

属性 説明

minPoolSize

起動時にプールに割り当てるファイルの数。デフォルトは40です。最適値は、同時リクエストの最大数に十分対応できる数です。

maxOpenFiles

オープン状態またはアクティブ状態にできるファイル・チャネルの最大数。この数を超えると、XIDが再度リクエストされるまで、最も古いチャネルから順に解放されます。デフォルトは256です。最適値は、同時リクエストの最大数に十分対応できる数です。

oldFileReleaseSize

maxOpenFilesを超えたときにクローズする最も古いファイル・ハンドルの数。デフォルトは20です。最適値は、maxOpenFilesを超える確率に応じて変化します。この最大数を超えることはできるかぎり避け、超えたとしてもその数を最小限に維持する必要があります。

データベース・ストアの属性

データベース・ストア・ログの属性は、トランザクション・コーディネータのデータベース・ストア・ロギングを使用している際に、データベース・ストアのパフォーマンスの制御に使用されます。属性を変更するには、JTAResource MBeanを使用するか、transaction-manager.xmlファイルを手動で編集する必要があります。表3-4で、ファイル・ストア・ログの属性を説明します。


中間層コーディネータのデータベース・ロギングに関する注意:

  • データベースはOracleである必要があります。

  • 次の場所にあるスキーマをデータベースにインストールする必要があります。

     ORACLE_HOME/j2ee/home/database/j2ee/jta/oracle/2pc_jdbcstore.sql

  • ロギングに使用するデータソースは、マネージド・データソースではなくネイティブ・データソースである必要があります。

  • ロギングに使用するデータソースは、デフォルト・アプリケーションにデプロイする必要があります。

表3-5 データベース・ストア・ロギングの属性

属性 説明

batchCreateInterval

トランザクションのバッチ書込みを実行する間隔（ミリ秒単位）。デフォルトは10です。最適値は小さい値ですが、データベース・コール（ネットワーク待機時間）のコストやJVMのヒープ・サイズに影響します。

batchStateInterval

トランザクションの状態変更のバッチ書込みを実行する間隔（ミリ秒単位）。デフォルトは10です。最適値は小さい値ですが、データベース・コール（ネットワーク待機時間）のコストやJVMのヒープ・サイズに影響します。

batchPurgeInterval

完了済トランザクションのバッチ・パージを実行する間隔（ミリ秒単位）。デフォルトは100です。最適値は大きい値ですが、データベース・コール（ネットワーク待機時間）のコストやJVMのヒープ・サイズに影響します。

サポート・リソースの構成

トランザクション・コーディネータでは、実行時の設定に応じてリソースに関する追加の構成が必要な場合があります。

サーバー

トランザクション・マネージャを構成するには、J2EE_HOME/config/server.xmlファイルに次の要素を含める必要があります。

 <transaction-manager-config path="./transaction-manager.xml"/>

注意:

transaction-timeout属性などのすべてのトランザクション・マネージャ構成が、server.xmlファイルではなくtransaction-manager.xmlファイルに含まれます。

server.xmlのリファレンス・ドキュメントは、『Oracle Containers for J2EE構成および管理ガイド』の付録B「OC4Jで使用される構成ファイル」の、OC4Jサーバー構成ファイル（server.xml）の概要に関する項を参照してください。

データソース

実行時ユーザーにXAResource.recover権限を付与しない場合、J2EE_HOME/config/data-sources.xmlファイルを使用して、データソースが2pcトランザクションに参加し、リカバリするために必要なリカバリ情報を指定します。

//
<connection-pool
 name="cmt Connection Pool">
 min-connections="10"
 max-connections="30"
 inactivity-timeout="30"
 <connection-factory   factory-class="oracle.jdbc.xa.client.OracleXADataSource"
   user="scott"
   password="tiger"
   url="jdbc:oracle:thin:@localhost:1521:ORCL">

 <xa-recovery-config>
   <password-credential>
   <username>system</username>
   <password>manager</password>
   </password-credential>
 </xa-recovery-config>
 </connection-factory>
 </connection-pool>

<managed-data-source connection-pool-name="cmt Connection Pool"
           jndi-name="jdbc/cmt"
           name="cmt"/>

注意:

OC4Jグローバル・トランザクションに参加するためには、データソースをマネージド・データソースとして指定する必要があります。

リソース・アダプタ

oc4j-ra.xmlファイルでは、JMSコネクタや他の任意のコネクタが2pcトランザクションに参加し、リカバリするために必要なXA情報とリカバリ情報を指定します。

2フェーズ・コミット処理に参加するためには、XAConnectionFactoryを使用する必要があります。また、必要なXAResource.recoverコールを実行するパーミッションを実行時ユーザーに付与しない場合は、connection-factoryでxa-recovery-config要素を定義する必要があります。

詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』の「トランザクション管理」の章と、付録の「OC4Jリソース・アダプタ構成ファイル」を参照してください。

xa-recovery-config要素の形式は、次のとおりです。

 <connection-factory>
...
 <xa-recovery-config>
   <password-credential>
   <username>adapter_admin_user</username>
   <password>adapter_admin_pw</password>
   </password-credential>
 </xa-recovery-config>
...
 </connection-factory>

次のリストに、ベンダー固有のパーミッションの例を示します。RDBMSのリソース・マネージャに関連するパーミッションは、data-sources.xmlに指定します。

  • Oracle: DBA_PENDING_TRANSACTIONSに対するselect権限と、sys.dbmsシステムに対するexecute権限（リリース9.2以上のRDBMS）。システムに、sys.dbms_systemパッケージに対応するシノニムを作成する必要があります。

  • DB2: sysadminロール

  • MSSQL: XAストアド・プロシージャに対するexecute権限

  • MQSeries: sysadminロール

データベース内トランザクション・コーディネータの考慮事項

この項では、データベース内の2フェーズ・コミット・コーディネータを使用するための要件について説明します。


注意:

データベース内2フェーズ・コミット・コーディネータの使用は、OC4Jでは推奨されていません。今後は、中間層コーディネータを使用することをお薦めします。

データベース内の2フェーズ・コミット・エンジンは、次の項目で構成されます。

  • 調整を担当するデータベースから、トランザクションに関連する各データベースへと向かう完全修飾データベース・リンク。トランザクションの終了時に、2フェーズ・コミット・エンジンは、完全修飾データベース・リンクを介して関連するデータベースと通信します。

  • 関連する各データベースに対するセッションの作成と、コミットまたはロールバックを実行する責任が与えられたユーザー。通信を実行するユーザーは、関連するすべてのデータベース上に作成され、適切な権限を与えられる必要があります。


注意:

データベース内の2フェーズ・コミット（2pc）機能には、Oracle Databaseリリース9.2.0.4以上を使用してください。データベース内の2フェーズ・コミット（2pc）機能は、Oracle Databaseリリース9.2以下では使用できません。


データベース内コーディネータ構成に関する注意:

  • データベースはOracleを使用する必要があります。

  • コーディネータとして指定するデータソースは、マネージド・データソースではなくネイティブ・データソースである必要があります。

  • データベース内コーディネータは、伝播されるトランザクション内では（ルート・コーディネータとしても介在コーディネータとしても）使用できません。また、最終リソース・コミットによる最適化も提供されません。

  • コーディネータとして指定するデータソースは、デフォルト・アプリケーションにデプロイする必要があります。

適切なOracleデータベースを2フェーズ・コミット・エンジンとして指定および構成する手順は、次のとおりです。

  1. Application Server Controlコンソールの「JDBCリソース」ページまたはdata-sources.xmlファイルでマネージド・データソースを定義します。

    次の例は、data-sources.xmlファイルでの定義です。

     <connection-pool
      name="OracleCommitDS">
      min-connections="10"
      max-connections="30"
      inactivity-timeout="30"
      <connection-factory
          factory-class="oracle.jdbc.xa.client.OracleXADataSource"
          user="scott"
          password="tiger"
          url="jdbc:oracle:thin:@localhost:1521:ORCL">
      </connection-factory>
  </connection-pool>
<managed-data-source connection-pool-name="Example Connection Pool"
                         jndi-name="jdbc/OracleCommitDS"
                         name="OracleCommitDS"/>

  2. transaction-manager.xmlで次のように2フェーズ・コミット・エンジンのデータソースを参照します。

           <database location="jdbc/OracleCommitDS">
           <identity user-name="COORDUSR" password="COORDPW"/>
       </database>

    identity要素は、マネージド・データソースで指定したuserとpasswordを上書きする必要がある場合にのみ使用します。

  3. ユーザーを作成し、トランザクションに関連するすべてのデータベースに対する適切なパーミッションを付与します。

    • トランザクションを調整する2フェーズ・コミット・エンジンにユーザーを作成します。

    • このユーザーは、2フェーズ・コミット・エンジンから関連する各データベースへのセッションをオープンします。

    • 各データベースに接続するため、このユーザーにCONNECT、RESOURCEおよびCREATE SESSION権限を付与します。FORCE ANY TRANSACTION権限を付与すると、ユーザーによるトランザクションのコミットまたはロールバックが可能になります。

    たとえば、トランザクションを調整するユーザーがCOORDUSRの場合、2フェーズ・コミット・エンジンとトランザクションに関連する各データベースに対する操作は、次のようになります。

    CONNECT SYSTEM/MANAGER;
CREATE USER COORDUSR IDENTIFIED BY COORDUSR;
GRANT CONNECT, RESOURCE, CREATE SESSION TO COORDUSR;
GRANT FORCE ANY TRANSACTION TO COORDUSR;

  4. CREATE PUBLIC DATABASE LINKコマンドを使用して、2フェーズ・コミット・エンジンからグローバル・トランザクションに関連する各データベースへと向かう完全修飾のパブリック・データベース・リンクを構成します。これらのリンクは、トランザクション終了時に、2フェーズ・コミット・エンジンが各データベースと通信するために必要です。これらのリンクにより、COORDUSRは、関連するすべてのデータベースに接続できます。

  5. トランザクションに参加するマネージド・データソースごとに、2フェーズ・コミット・エンジンからそのデータベースへと向かう完全修飾データベース・リンクのプロパティを追加します。

    Application Server Controlコンソールの「接続プール」ページまたはdata-sources.xmlファイルでプロパティを追加します。

    次の例は、data-sources.xmlファイルでの定義です。

     <connection-pool
      name="OracleDS1">
      min-connections="10"
      max-connections="30"
      inactivity-timeout="30"
      <connection-factory
          factory-class="oracle.jdbc.xa.client.OracleXADataSource"
          user="scott"
          password="tiger"
          url="jdbc:oracle:thin:@host1:1521:ORCL">
       <property name="dblink"
 value="DBLINK1.REGRESS.RDBMS.DEV.US.OLE.COM"/>
          </connection-factory>
  </connection-pool>
<managed-data-source connection-pool-name="Example Connection Pool"
                         jndi-name="jdbc/OracleDS1"
                         name="OracleDS1"/>
 <connection-pool
      name="OracleDS2">
      min-connections="10"
      max-connections="30"
      inactivity-timeout="30"
      <connection-factory
          factory-class="oracle.jdbc.xa.client.OracleXADataSource"
          user="scott"
          password="tiger"
          url="jdbc:oracle:thin:@host2:1521:ORCL">
       <property name="dblink"
 value="DBLINK2.REGRESS.RDBMS.DEV.US.OLE.COM"/>
      </connection-factory>
 </connection-pool>
<managed-data-source connection-pool-name="Example Connection Pool"
                         jndi-name="jdbc/OracleDS2"
                         name="OracleDS2"/>

OC4Jトランザクション・マネージャの管理

この項では、実行時に可能となる次の操作について説明します。

手動によるコミットおよびロールバック操作

JTAResource MBeanへのパス:

「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「システムMBeanブラウザ」→「タスクに移動」

Application Server Controlコンソールを通じてアクセス可能なJTAResource MBeanの次の操作は、現在のトランザクションの結果を強制的に決定する場合に使用できます。

操作 説明
heuristicCommit インダウト・トランザクションに対する自律型のコミット決定
heuristicRollback インダウト・トランザクションに対する自律型のロールバック決定
setRollbackOnly アクティブなトランザクションに対する自律型のsetRollbackOnly決定

OC4Jトランザクション・マネージャの監視

この項では、JTAResource MBeanを通じて可能となる次の機能について説明します。

OC4Jトランザクション・サポート統計

次の表にリストされた統計は、Application Server Controlコンソールを通じてアクセスできるJTAResource MBeanにより提供されます。

統計 説明
activeCount アクティブなトランザクションの合計数。

高い値が続く場合、サーバーの負荷が高くなっている可能性があります。

クラスタ全体のバランシングを検討してください。
committedCount コミットされたトランザクションの合計数。

この値は、起動以降（または統計がリセットされてから）のサーバーの平均負荷を確定する際に使用できます。activeCountと同様、高い平均値が続く場合、サーバーの負荷が高くなっている可能性があります。

ロード・バランシングを検討してください。
rolledbackCount ロールバックされたトランザクションの合計数。

値が高い場合、システムの問題（データベースの停止など）が原因でパフォーマンスが低下している可能性があります。

詳細なロールバックの原因数とロールバックの原因に関するログを調べてください。
rolledbackDueToTimedOutCount タイムアウトが原因でロールバックされたトランザクションの合計数。

値が高い場合、トランザクション（またはトランザクション範囲内のアクティビティ）がタイムアウトになる原因となる、いくつかの問題がある可能性があります。指定したタイムアウト値の対応度が不十分であることも考えられます。

関連するトランザクション内で時間のかかっているアクティビティ（特定のタイプまたはアプリケーション）を特定するか、transaction-manager.xml構成ファイルでトランザクションのタイムアウト値を調整してください。
rolledbackDueToAppCount setRollbackOnlyまたはロールバックを明示的にコールするアプリケーションが原因でロールバックされたトランザクションの合計数。

値は様々な理由で高くなりますが、ほとんどの場合、アプリケーション内の複数の処理済の例外（データベースの更新時のSQLExceptionなど）が原因です。

setRollbackOnlyまたはロールバックをコールするアプリケーション・コードを調べて、原因を特定してください。
rolledbackDueToResourceCount 登録されたリソース内のエラーが原因でロールバックされたトランザクションの合計数。

値が高い場合、1つ以上のリソース・マネージャ（データベースなど）、またはOC4Jとこれらのリソースとの間のネットワーク接続に問題が発生している可能性があります。

OC4Jおよびリソース・マネージャのログを調べてください。
rolledbackDueToAdminCount 管理処理が原因でロールバックされたトランザクションの合計数。

値が高い場合、システムまたはアプリケーションの自動化が十分ではないこと（全体にシステム管理が多すぎる、またはトランザクション・アーキテクチャの処理が不適切であるなど）を示します。または大規模な管理を必要とする、特定の問題が発生している可能性もあります。

ログで傾向を分析し、管理処理の担当者に問い合せてください。
rollbackExceptionCount 発生したRollbackExceptionsの合計数。

値が高い場合、システムの問題（データベースの停止など）が原因でパフォーマンスが低下している可能性があります。これは、直接的な内部システム障害、またはなんらかの理由によってsetRollbackOnlyをコールするアプリケーションが原因である可能性があります。

詳細なロールバックの原因数とロールバックの原因に関するログを調べ、setRollbackOnlyをコールするアプリケーション・コードを検証してください。
heuristicMixedExceptionCount 発生したHeuristicMixedExceptionsの合計数。

値が高い場合、一貫性がないか不適切な管理処理により、非ACIDになりうる結果が多数発生している可能性があります。

ログで傾向を分析し、管理処理の担当者に問い合せてください。
heuristicRollbackExceptionCount 発生したヒューリスティックなロールバック例外の合計数。

値が高い場合、システムまたはアプリケーションの自動化が十分ではないこと（全体にシステム管理が多すぎる、またはトランザクション・アーキテクチャの処理が不適切であるなど）を示します。または大規模な管理を必要とする、問題が発生している可能性もあります。トランザクションがアクティブなときのルート・トランザクション・マネージャ・レベルにおける管理ロールバックを示すrolledbackDueToAdminCountとは異なり、この数値は下位のトランザクション・マネージャまたはリソース・マネージャが準備状態のときに管理ロールバックされていることを示します。

OC4Jおよびリソース・マネージャのログで傾向を分析し、管理処理の担当者に問い合せてください。
securityExceptionCount 発生したSecurityExceptionsの合計数。

値が高い場合、特に値が0より大きい場合、これを実行するスレッドでIDに問題がある可能性があります。

OC4Jログを調べてください。
illegalStateExceptionCount 発生したIllegalStateExceptionsの合計数。

この値が高くなることはほとんどありません。高い場合は、前の管理処理が原因と考えられます。

OC4Jログで傾向を分析し、管理処理の担当者に問い合せてください。
systemExceptionCount 発生したSystemExceptionsの合計数。

この値が高くなることはありません。高い場合は、システムで重大な障害が発生していることを示します。

OC4Jおよびリソース・マネージャのログを分析してください。
heuristicCommittedCount ヒューリスティックにコミットされたトランザクションの合計数。

値が高い場合、システムまたはアプリケーションの自動化が十分ではないこと（全体にシステム管理が多すぎる、またはトランザクション・アーキテクチャの処理が不適切であるなど）を示します。または大規模な管理を必要とする、問題が発生している可能性もあります。これは下位のトランザクション・マネージャが原因であり、準備状態のときにリソース・マネージャが管理ロールバックされることは原因ではありません。

OC4Jログで傾向を分析し、管理処理の担当者に問い合せてください。
heuristicRolledbackCount ヒューリスティックにロールバックされたトランザクションの合計数。

値が高い場合、システムまたはアプリケーションの自動化が十分ではないこと（全体にシステム管理が多すぎる、またはトランザクション・アーキテクチャの処理が不適切であるなど）を示します。または大規模な管理を必要とする、問題が発生している可能性もあります。これは下位のトランザクション・マネージャが原因であり、準備状態のときにリソース・マネージャが管理ロールバックされることは原因ではありません。

OC4Jログで傾向を分析し、管理処理の担当者に問い合せてください。
heuristicCount ヒューリスティックにロールバックおよびコミットされたすべてのトランザクションの合計数。

heuristicCommittedCountおよびheuristicRolledbackCountの説明を参照してください。
averageCommitTime すべてのトランザクションの平均コミット時間。

これは、performTransaction値の平均です。ただし、これは平均値であるため、システムで値が急上昇している可能性もあり、その場合は他の問題も発生しています。

システムで値が急上昇しているかどうか、詳細な統計およびログ・ファイルを分析してください。また、必要に応じてアーキテクチャ全体を分析してください。
performTransaction トランザクションの開始から終了までの時間。

これは、パフォーマンスの問題に関する高レベルのインジケータとして役に立ちます。ただし、この値はトランザクションの開始から終了までの時間を測定しただけの値であるため、この時間内に発生したすべてのことがこの値に影響している可能性があります。候補として、アプリケーション・ロジック、データベース・アクティビティ、JMSアクティビティ、トランザクション処理などがあげられます。

必要に応じて、詳細な統計およびアーキテクチャ全体を分析してください。
singlePhaseCommitCompletion 1フェーズ・コミットの完了に必要な時間。

1フェーズ・コミットには単一のリソースのみが含まれ、2PCコスト（ロギングなど）は含まれません。この値が高い場合は通常、コミットされる単一のリソースに問題（データベースに対するネットワーク待機時間など）があること示します。

コミットに含まれるリソースのメトリックを分析してください。
twoPhaseCommitCompletion 2フェーズ・コミットの完了に必要な時間。

値が高い場合、リソース・マネージャの準備およびコミットのコールまたはOC4J内のトランザクション・レコードのロギングが遅れていることを示します。

transaction-manager.xmlファイルで、関連するリソースのメトリックおよびOC4Jにおけるトランザクション・レコードのロギングのパフォーマンス設定を分析してください。
transactionSuspended トランザクションが一時停止している時間。

値が高い場合、トランザクションが一時停止状態であり、（通常EJBメソッド・コールからの）別のコンテキストまたはトランザクション以外のコンテキストで、あるいはトランザクション・コンテキストの伝播中に、リターン・コールを待機していることを示します。

アプリケーションを分析し、一時停止中に発生しているアクティビティを特定するか、伝播中の場合はネットワーク待機時間があるかどうかを確認してください。
rollbackCompletion ロールバックの完了に必要な時間。

値が高い場合、ネットワーク待機時間またはリソース・マネージャの問題の結果、リソース・マネージャのロールバック・コールが遅れていることを示します。

ロールバックに含まれるリソースのメトリックを分析してください。

次の表にリストされた属性は、JTAResource MBeanにより提供されます。

属性 説明
inDoubtXids インダウト・トランザクションXIDの配列
activeXids アクティブ・トランザクションXIDの配列
heuristicCommittedXids ヒューリスティックにコミットされたトランザクションXIDの配列
heuristicRolledbackXids ヒューリスティックにロールバックされたトランザクションXIDの配列
currentTransactionDetail アクティブ、インダウト、リカバリ中を含む、サーバー上のすべての現行トランザクションの詳細

次のJTAResource MBean操作は、統計に関連しています。

操作 説明
clearStats activeCount以外のすべてのOC4Jトランザクション・サポート統計を0にリセットします。
addThresholdEvent 指定されたOC4Jトランザクション件数統計が特定のしきい値を超えたときに起動され、指定された件数の間隔で繰り返されるイベントを追加します。

addThresholdEventには次のパラメータがあります。

  • statName: 監視対象とする件数統計の名前

  • threshold1: イベントが配信されるときの件数

  • repeatNotificationInterval: 後続のイベントが配信される件数の間隔
removeThresholdEvent しきい値イベントを削除します。

removeThresholdEventには次のパラメータがあります。

  • statName: しきい値イベントが削除される件数統計の名前

イベント通知のサブスクライブ

JTAResource MBeanでは、MBeanの「通知」タブに一連のイベント通知がリストされています。タブは、通知のサブスクライブにも使用できます。

通知 説明
jtaThresholdEvent 指定されたJTA統計の件数が特定のしきい値を超えたときにリスナーに通知し、指定された件数の間隔で繰り返します。

しきい値を設定するには、前の表で説明されているaddThresholdEvent操作を使用します。
jtaAbandonRecoveryEvent 1つ以上のトランザクションのリカバリが管理処理によって中止された場合に、リスナーに通知します。
jtaSevereMessageEvent 重大なレベルのJTAメッセージが記録された場合に、リスナーに通知します。
jtaProtocolErrorEvent 2フェーズ・コミットの処理中にプロトコル違反が原因でProtocolErrorがスローされた場合にリスナーに通知します。

また、Application Server Controlコンソールの「通知サブスクリプション」ページで通知にサブスクライブできます。

「グローバル: 通知サブスクリプション」ページへのパス:

「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「通知サブスクリプション」

通知は、Application Server Controlコンソールの「受信済の通知」ページで参照できます。

「グローバル: 受信済の通知」ページへのパス:

「OC4J: ホーム」→「管理」タブ→「タスク名: JMX」→「受信済の通知」

OC4Jトランザクション・マネージャのリカバリの管理

通常、システムが適切に構成されていれば、OC4Jまたは2PCトランザクションに参加するリソースのいずれかに障害が発生しても、引き続き元の状態に戻り、自動的にリカバリが行われます。

リカバリ管理

Application Server ControlコンソールのJTAResource MBeanを使用すると、リカバリ中止ルールの定義やリカバリ・トランザクションの即時中止を含め、トランザクション・リカバリを管理できます。

JTAResource MBeanの次の操作を使用して、トランザクション・リカバリを管理できます。

操作 説明
abandonRecovery 指定されたトランザクションのリカバリを中止します。
abandonRecoveryForType このタイプ（アプリケーション）のすべてのトランザクションのリカバリを中止します。
addThresholdEvent 指定されたJTA統計の件数が特定のしきい値を超えたときに起動され、指定された件数の間隔で繰り返されるイベント通知を追加します。
clearStats すべてのJTA集計数統計を0にリセットします。
configureCoordinator 2フェーズ・コミット・コーディネータを構成します（これらの設定を反映するにはサーバーを再起動する必要があります）。
configureDatabaseLoggingPerformance 2フェーズ・コミット・コーディネータのデータベース・ロギング・パフォーマンスの設定を構成します。
configureFileLoggingPerformance 2フェーズ・コミット・コーディネータのファイル・ロギング・パフォーマンスの設定を構成します。
getMBeanInfo MBeanのローカライズされたメタデータを取得します。
heuristicCommit インダウト・トランザクションに対する自律型のコミットを決定します。
heuristicRollback インダウト・トランザクションに対する自律型のロールバックを決定します。
removeThresholdEvent しきい値イベントを削除します。
rollbackTransaction アクティブなトランザクションに対する自律型のロールバックを決定します。
setAbandonRecoveryCountForResourceManager 指定した参加者（JNDIロケーション）が、指定された数のリカバリの再試行でリカバリに失敗したトランザクションのリソースのみの場合に、特定タイプ（アプリケーション）のトランザクションの中止を指定するリカバリ中止定義を追加します。
setAbandonRecoveryCountForType 指定された数のリカバリの再試行でリカバリに失敗した場合に、特定タイプ（アプリケーション）のトランザクションの中止を指定するリカバリ中止定義を追加します。
setAbandonRecoveryTimeForResourceManager 指定した参加者（JNDIロケーション）が、指定された時間（秒）内でのリカバリに失敗したトランザクションのリソースのみの場合に、特定タイプ（アプリケーション）のトランザクションの中止を指定するリカバリ中止定義を追加します。
setAbandonRecoveryTimeForType 指定された時間（秒）内でのリカバリに失敗した場合に、特定タイプ（アプリケーション）のトランザクションの中止を指定するリカバリ中止定義を追加します。
setRollbackOnly アクティブなトランザクションに対する自律型のsetRollbackOnly決定。

リカバリ再試行間隔

JTAResource MBeanにも含まれているrecoveryRetryInterval属性は、トランザクションのリカバリを試行するまでにリカバリ・マネージャが待機する時間（秒単位）の特定に使用されます。再試行は任意の中止定義の対象になります。属性は、デフォルトで300秒に設定されます。

ログ

OPMN環境では、OC4Jに障害が発生すると、障害の発生したインスタンスのログを使用する新規インスタンスがOPMNによって起動されます。

スタンドアロン環境では、OC4Jインスタンスに障害が発生して、なんらかの理由でそのインスタンスを元の状態に戻すことができない（または戻してはならない）場合、別のOC4Jインスタンスにログを移行できます。

スタンドアロンでのログの移行

ログの移行プロセスは、インスタンスがルート・トランザクション・マネージャと介在トランザクション・マネージャのいずれであるか（またはその両方であるか）に応じて変化します。また、ロギング・メカニズムがファイルとデータベースのいずれであるかによっても変化します。

ファイル・ストアを使用するルート・トランザクション・マネージャの場合、新規OC4Jインスタンスのログ位置の構成を障害の発生したインスタンスのログ位置に変更するか、以前のログを手動で新規OC4Jインスタンスのログ位置に移動する必要があります。この作業は、宛先サーバーがオフラインであるか停止しているときに実行する必要があります。

ファイル・ストアを使用する介在トランザクション・マネージャの場合も同じプロセスを使用します。ただし、この介在トランザクション・マネージャの親トランザクション・マネージャは、以前の参照を新しいログ位置に更新する必要があります。この作業は、オフライン管理コマンドの-updateTransactionLogsを使用して実行できます。

データベース・ストアを使用するルート・トランザクション・マネージャの場合、オフライン管理コマンドの-updateTransactionLogsを使用して、oc4j_transaction表のインスタンス・フィールドを更新することでログを移行します。新規OC4Jインスタンスで完全新規のデータベースを使用する場合は、ログ・ファイルをエクスポートおよびインポートする必要もあります。

データベース・ストアを使用する介在トランザクション・マネージャの場合も同じプロセスを使用します。ただし、この介在トランザクション・マネージャの親トランザクション・マネージャは、以前の参照を新しいログ位置に更新する必要があります。この作業は、オフライン管理コマンドの-updateTransactionLogsを使用して実行できます。

admin.jarでは、次の2つのオフライン管理コマンドを使用できます。

  • -analyzeTransactionLogs

  • -updateTransactionLogs


注意:

前述の手順は、スタンドアロン環境のファイルを移行する場合に適用されますが、一定の状況下にあるOPMN環境でも役に立つ可能性があります。

-analyzeTransactionLogsコマンドでは、トランザクション・ログ・ファイルのオフライン分析が可能になります。このユーティリティは、OC4Jが実行中の場合には使用しないでください（かわりにApplication Server Controlコンソールを使用します）。引数は次のとおりです。

引数 説明
-logType ["file" | "database"] ストア・タイプ。
-location [location] ストアの場所。

ファイル・ロギング用のディレクトリ。

データベース・ロギング用の接続URL。
-username [username] データベース・ロギング専用。
-password [password] データベース・ロギング専用。

-updateTransactionLogsコマンドでは、トランザクション・ログ・ファイルのオフライン更新が可能になります。このユーティリティは、OC4Jが実行中の場合には使用しないでください（かわりにApplication Server Controlコンソールを使用します）。引数は次のとおりです。

引数 説明
-logType ["file" | "database"] ストア・タイプ。
-location [location] ストアの場所。

ファイル・ロギング用のディレクトリ。

データベース・ロギング用の接続URL。
-username [username] データベース・ロギング専用。
-password [password] データベース・ロギング専用。
-instanceId [old instance id] [new instanceid] このログに関連付けるOC4JインスタンスID。
-branchLocation [old branch location] [new branch location] ブランチの場所。一般的には、アプリケーション名を接頭辞とするJNDIロケーション。
-branchArg [old branch arg] [new branch arg] ブランチの引数。コンテナ管理のサインオン・ユーザー名など。

ORMIを通じたOC4Jプロセス間でのトランザクション伝播

トランザクション・コンテキストの伝播により、複数のOC4Jインスタンスが単一のグローバル・トランザクションに参加できます。クライアントのトランザクションにおけるメソッド・サポートのスコープ決定作業がEJBのセマンティクスに含まれるすると、OC4Jインスタンスが既存のトランザクションのスコープ内にある別のOC4Jインスタンスにリモート・コールを行う場合、複数のOC4Jインスタンスが同じトランザクションに参加する必要があります。この例の1つは、次のようなOC4Jインスタンスのサーブレットです。


注意:

トランザクション・コンテキストの伝播とサブジェクトの伝播は、以前のリリースのOC4Jではサポートされていません。

複数のOC4Jインスタンスが単一のトランザクションに参加する場合、それらのOC4Jインスタンスによりグローバル・トランザクションの一部として実行されるすべての作業は、その原子性が保証されます。

Remote Method InvocationがOC4Jインスタンス間で使用される場合、リクエスト側のOC4Jインスタンスは、現在のトランザクションを示すトランザクション・コンテキストを作成し、ORMIを通じたリモート・コールを使用してそのコンテキストを暗黙的に送信する必要があります。これにより、Remote Method Invocationを受信するOC4Jインスタンスは、リクエストの一部として実行する作業を、トランザクション・コンテキストで示されるトランザクションに関連付けることができます。リモートOC4Jインスタンスは、リクエスト側のOC4Jインスタンスにリソースとして登録されます。これにより、元のOC4Jインスタンスがルート・トランザクション・コーディネータとなり、子のOC4JインスタンスがノードとなるOC4Jインスタンスのツリーが作成されます。1つのOC4Jインスタンスは、親と子の両方になることが可能です。この場合、そのインスタンスは、親に対してはリソースとして振る舞い、子に対してはコーディネータとして振る舞います。これは、インターポジショニングと呼ばれます。ORMIの詳細は、第6章「Remote Method Invocationの使用方法」を参照してください。

ルート・コーディネータは、トランザクションをコミットすると、2フェーズ・コミット（2pc）プロトコルを実行し、登録されているOC4Jインスタンスを含むすべての登録済リソースに完了コールを送信します。ルート・コーディネータは、2フェーズ・コミット（2pc）プロトコルを使用してトランザクションの完了処理を制御しますが、下位のOC4Jインスタンスは、トランザクションの単なるリソースとして機能します。J2CA 1.5のトランザクション・インフロー規約を使用してOC4Jでトランザクションをインポートする場合のように、ルート・コーディネータは、OC4Jインスタンスではなく外部のコーディネータでもかまいません。リソースとして登録されたOC4Jインスタンスは、他の任意の登録済リソースと同じように振る舞い、自身のトランザクション・ブランチの準備とコミットのみを担当します。OC4Jインスタンスは、準備を指示するコールを受信すると、自身のすべての登録済リソースの準備を試行し、その結果を戻します。同様に、OC4Jインスタンスは、コミットを指示するコールを受信すると、自身のすべての登録済リソースに対してcommitをコールし、その結果を親に戻します。

トランザクション・インフロー規約の詳細は、『Oracle Containers for J2EEリソース・アダプタ管理者ガイド』の「インバウンド接続でのRAの使用方法」を参照してください。

ORMIを通じてOC4Jインスタンス間でトランザクションを伝播することにより、トランザクションを複数のOC4Jインスタンスに拡張できます。

次のサイトにあるHow-Toドキュメント「How-To Propagate a transaction context between OC4J instances」とZIPファイルには、OC4Jインスタンス間でのトランザクション・コンテキストの伝播に関する情報および使用例が含まれます。

http://www.oracle.com/technology/tech/java/oc4j/1013/how_to/how-to-transaction-propagation/doc/how-to-transaction-propagation.html

トランザクション伝播の構成

この項では、トランザクション伝播の構成に関する問題について説明します。

有効化と無効化


注意:

ほとんどの場合、トランザクション伝播を無効化することはありません。トランザクション伝播の無効化は、トラブルシューティングなどの例外的な状況においてのみ実行します。トランザクション伝播を無効化する場合は、慎重に行ってください。

トランザクション伝播は、OC4Jではデフォルトで有効です。トランザクション伝播を無効化するには、システム・プロパティ-Drmi.disablePropagation=trueを設定します。このフラグの設定により、トランザクションおよびサブジェクトの伝播を含むすべてのコンテキスト伝播が無効化されます。トランザクション伝播の有効化または無効化は、サーバーにデプロイされているすべてのアプリケーションに影響します。粒度レベルを細かくすることはできません。トランザクション伝播の無効化は、慎重に行う必要があります。この設定については、リクエストに関連するすべてのOC4Jプロセスで必ず同じ構成にする必要があります。つまり、リクエストに関連するすべてのOC4Jプロセスで有効化するか、すべてのOC4Jプロセスで無効化します。これらの構成が混在すると（つまり、リクエストに関連するOC4Jプロセスの一部で有効化され、一部で無効化されると）、予期しない動作が発生する可能性があります。また、トランザクション伝播が無効化されると、複数のOC4Jプロセスは、単一のグローバル・トランザクションに参加できません。トランザクション伝播の無効化は、その結果をすべて完全に理解した場合にのみ行ってください。トランザクション伝播を無効化すると、問題が発生する可能性があるため、この機能は有効化しておくことをお薦めします。

リカバリ

OC4Jプロセスは、トランザクション・リソースとして機能することがあるため、障害時にリカバリ可能である必要があります。トランザクション・リカバリを容易にするため、各OC4Jプロセスでは、トランザクション・リカバリ時にトランザクション・リカバリ・マネージャによって使用されるパスワードを構成する必要があります。OC4Jに事前設定されているデフォルトのパスワードは、インストール後に変更する必要があります。

リカバリ・パスワードは、$J2EE_HOME/configディレクトリの構成ファイルjazn-data.xmlで構成します。トランザクション・リカバリ・パスワードを変更するには、jazn-data.xmlファイルのJtaAdminユーザーの資格証明値を変更します。

<user>
    <name>JtaAdmin</name>
    <display-name>JTA Recovery User</display-name>
    <description>Used to recover propagated OC4J transactions</description>
    <credentials>!newJtapassword</credentials>
</user>

注意:

Oracle Internet DirectoryなどのJAZN以外のセキュリティ・サービスを使用するようOC4Jが構成されていても、トランザクション・リカバリ・パスワードはjazn-data.xmlに構成する必要があります。

トランザクション・リカバリの実行時には、リカバリされるOC4Jプロセスの実際のセキュリティ・ストアにあるリカバリ・パスワードと、トランザクション処理中にjazn-data.xmlで構成されたパスワードが一致する必要があります。パスワードが一致しない場合、リカバリ・マネージャはOC4Jの下位プロセスと通信できないため、リカバリを完了できません。

ロギング

トランザクション伝播では、追加のトランザクション・ロギング構成を必要としませんが、1つのトランザクションは複数のOC4Jプロセスに拡張されることがあるため、各OC4Jプロセスは、ロギングに関して相互に依存しないよう構成する必要があります。

トランザクション伝播の制限事項

この項では、トランザクション伝播機能に適用される次の制限事項について説明します。

下位互換性

OC4Jの旧リリースでは伝播はサポートされていません。トランザクション伝播をサポートするOC4Jインスタンスが、トランザクション伝播をサポートしない旧リリースのOC4JにデプロイされたBeanに対してRemote Method Invocationを実行しても、トランザクション・コンテキストは伝播されません。このため、コール元がトランザクションのスコープ内にあっても、リモート・マシンでの作業は、コール元のトランザクションのスコープ内で実行されません。アプリケーション・デプロイヤまたは管理者は、アプリケーションを様々なリリースのOC4Jにデプロイする場合、デプロイの前にアプリケーションのトランザクション要件を理解しておく必要があります。

EJBフェイルオーバー

トランザクションがOC4Jプロセスに伝播される場合、伝播されたトランザクションのスコープ内で障害が発生し、あるサーバーに対するリクエストがセカンダリ・サーバーにフェイルオーバーされると、そのトランザクションはロールバックされます。

EJBフェイルオーバーの動作の詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。

デバッグとトラブルシューティング

デバッグとトラブルシューティングに役立つヒントは、次のとおりです。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引