| Oracle® Fusion Middleware Oracle WebLogic Server JTAアプリケーションの開発 12c (12.2.1.1.0) E77263-01 |
|
 前へ |
 次へ |
この章には次の項が含まれます:
管理コンソールは、WebLogic JTAなどのWebLogic Serverの機能を構成するために使用するインタフェースを備えています。構成プロセスでは、属性の値を指定する必要があります。それらの属性によって、以下のようなトランザクション環境が定義されます。
トランザクションのタイムアウトと制限
トランザクション・マネージャの動作
また、EJB、JDBCデータ・ソース、JMSなど、トランザクションに参加可能なJava EEコンポーネントの管理についてもよく理解しておく必要があります。
注意:
トランザクション関連の構成には、WebLogic Scripting Tool (WLST)(『WebLogic Scripting Toolの理解』を参照)またはJMX(『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照)を使用することもできます。
WebLogic JTAおよび任意のトランザクション参加コンポーネントを構成すると、システムはJTA APIおよびWebLogic JTA拡張機能を使用してトランザクションを管理できます。次の点に注意してください。
JTA (トランザクション)の構成設定は、次のように、ドメイン・レベルおよびクラスタ・レベルで適用できます。
ドメイン・レベルでは、属性の設定はドメイン内のすべてのサーバーに適用されます。これらの設定は、クラスタ・レベルの設定に差し替えられます。表3-1を参照してください
クラスタ・レベルでは、属性の設定はドメイン内の1つのクラスタに適用されます。これらの設定は、ドメイン・レベルの設定に優先します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「クラスタ: 構成: JTA」を参照してください。
JTAのモニター・タスクは、サーバー・レベルで実行されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAの監視に関する項を参照してください。
参加リソース(JDBCデータ・ソースなど)の構成設定は、構成されるオブジェクトごとに行われます。設定は、特定のオブジェクトのすべてのインスタンスに対して適用されます。『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースのトランザクション・オプションに関する項、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのグローバル・トランザクション・オプションの構成に関する項を参照してください。
表3-1 JTAの構成オプション(トランザクション)
| 名前 | 説明 |
|---|---|
| タイムアウト | 2フェーズ・コミット・トランザクションの最初のフェーズでアクティブ・トランザクションが許容される最大秒数を指定します。指定した時間をすぎると、トランザクションは自動的にロールバックされます。 MBean属性:JTAMBean.TimeoutSeconds 最小値: 1 最大値: 2147483647 注意: DBMSには、XAトランザクションがDBMSロックを保持する最大許容期間である、独自のDISTRIBUTED_LOCK_TIMEOUT(デフォルトは60秒)があります。このDBMSオプションは、WebLogicの予期される最長トランザクションに対応できるように調整されていることが重要です。このDBMSタイムアウトがWebLogic JTA/txタイムアウトより小さい場合、DBMSはロール・バックし、WebLogicからの実行中のトランザクションを無視します。これにより、トランザクションの代理でWebLogicからDBMSに後続の処理を問合せた際に、DBMSにその情報がない場合、WebLogicで'NOTA' (不明なトランザクションID)エラーが発生します。 |
| 破棄タイムアウト | トランザクション・マネージャが2フェーズ・コミット・トランザクションの2番目のフェーズの完了を試行する最大時間(秒)を指定します。 2フェーズ・コミット・トランザクションの2番目のフェーズで、トランザクション・マネージャは、すべてのリソース・マネージャがトランザクション完了を示すまでトランザクションを完了しようとします。中止トランザクション・タイマーの期限が切れた後、トランザクションを解決するための試行は行われなくなります。トランザクションが破棄される前に準備状態に入った場合、トランザクション・マネージャはトランザクションをロールバックし、破棄されたトランザクションのかわりに保持されたロックを解放します。 MBean属性: JTAMBean.AbandonTimeoutSeconds 最小値: 1 最大値: 2147483647 |
| beforeCompletionの反復上限 | トランザクション・マネージャが、このWebLogic Serverドメインに対してbeforeCompletion同期化コールバックを実行するサイクルの最大数。 同期化オブジェクトはbeforeCompletionsがすでに呼び出されたオブジェクトであっても、beforeCompletionで別のオブジェクトを登録できます。たとえばEJBは、そのejbStore()メソッドで別のEJBを呼び出すことができます。これに対応するために、トランザクション・マネージャはすべての同期化オブジェクトを呼び出し、新しいオブジェクトが登録されている場合、このサイクルを繰り返します。この値で、同期化が発生するサイクルの回数を制限します。 MBean属性: JTAMBean.BeforeCompletionIterationLimit 最小値: 1 |
| 最大トランザクション数 | このWebLogic Serverドメインのサーバーで許可される同時進行トランザクションの最大数。 MBean属性: JTAMBean.MaxTransactions 最小値: 1 最大値: 2147483647 |
| 一意名の最大数 | 保持する統計の対象となる一意なトランザクション名の最大数。 最初の1001件の一意のトランザクション名は固有のトランザクション名で保持され、各統計に保存されます。1002件目以降のトランザクション名はweblogic.transaction.statistics.namedOverflowとして保存され、トランザクション統計もweblogic.transaction.statistics.namedOverflowにマージして保持されます。 トランザクション名は、通常、ビジネス・トランザクションのカテゴリを表します(送金など)。 MBean属性: JTAMBean.MaxUniqueNameStatistics 最小値: 0 最大値: 2147483647 |
| チェックポイント間隔 | トランザクション・マネージャが、新しいトランザクション・ログ・ファイルを作成し、すべての古いトランザクション・ログ・ファイルをチェックしてそれらを削除できるかどうかを確認する間隔。 MBean属性: JTAMBean.CheckpointIntervalSeconds 最小値: 10 最大値: 1800 |
| 決定子が構成されている場合は、リカバリ・ログが書き込まれます | 決定子が1つ以上構成されている場合でも、2フェーズ・トランザクション・リカバリ・ログが書き込まれることを示します。 |
| 決定子 | リソースのリストからトランザクション・リソース(決定子)を選択します。JMSの場合は、WebLogic JMSを決定子として選択します。決定子が構成されている場合、決定子の不確かなトランザクション・レコードがトランザクション・リカバリ時に使用されます。 MBean属性: JTAMBean.Determiners |
| ヒューリスティックの無視 | トランザクション・マネージャがトランザクションのヒューリスティックな終了に対して自動的にXA Resource forget処理を実行するかどうかを指定します。 有効化すると、トランザクション・マネージャは、トランザクションがヒューリスティックな結果を認識するとすべてのリソースのXA Resource forget()操作を自動的に実行します。リソースがヒューリスティックな決定をレポートするときに、リソースを使用した操作を把握している場合にのみ、この機能を無効にします。 MBean属性: JTAMBean.ForgetHeuristics |
| リソース登録解除の猶予期間 | トランザクション・マネージャが、リソースの関与するトランザクションの完了をリソースが登録解除されるまでに待機する時間(秒)。この猶予期間の設定は、登録解除されたリソース(アプリケーションと一緒にパッケージされているJDBCデータ・ソース・モジュールなど)が原因でトランザクションが破棄されるリスクを最小限に抑えるために役立ちます。 指定された猶予期間の間、unregisterResource呼出しは自身が戻るまでブロックを行い、関連するリソースに対して新しいトランザクションは開始されません。リソースに対して未処理のトランザクションの数が0になると、unregisterResource呼出しは即座に返ります。 猶予期間の終わりに、リソースに関連する未処理のトランザクションがある場合は、unregisterResourceが戻り、リソースが以前登録されていたサーバー上にログ・メッセージが書き込まれます。 MBean属性: JTAMBean.UnregisterResourceGracePeriod 最小値: 0 最大値: 2147483647 |
| XA呼出しの並列実行 | 使用可能なスレッドがある場合にXA呼出しを並列に実行することを示します。 MBean属性: JTAMBean.ParallelXAEnabled |
2フェーズ・コミットの有効化 |
複数のリソース・マネージャ間でトランザクションを調整するために2フェーズ・コミット・プロトコルを使用するかどうかを示します。 選択されていない場合:
MBean属性: JTAMBean.TwoPhaseEnabled |
| 密結合トランザクションの有効化 | 異なるトランザクション・マネージャ・システムにまたがるトランザクション・ブランチの密結合を示します。 有効にした場合、内部でマップされたXidではなく、XA呼出し用のInterposedTransactionManagerによってインポートされたトランザクションのトランザクション識別子がWebLogicで使用されます。これは、WebLogicドメイン内トランザクションとTuxedoからインポートされたトランザクションに適用されます。これは、異なるトランザクション・マネージャ・システムにまたがるトランザクションのトランザクション・ブランチの密結合を許可します。 WebLogicリソースとTuxedoリソースの間のトランザクションで、GridLinkアフィニティが有効なGridLinkデータ・ソースが使用される場合、XAアフィニティ・コンテキストは自動的にトランザクションに使用されます。 |
| クラスタ全体の回復の有効化 | 分散トランザクションに対してクラスタ全体のリカバリが使用されることを示します。 有効化した場合、InterposedTransactionManagerをホストしているサーバーのみでなく、InterposedTransactionManagerをホストしているクラスタのすべてのサーバーに、分散トランザクションのリカバリ操作が適用されます。 MBean属性: JTAMBean.ClusterwideRecoveryEnabled |
拡張構成オプションについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの拡張構成オプションに関する項を参照してください
アプリケーションと一緒にパッケージ化されたJDBCデータ・ソース・モジュールなど、必要に応じてアンデプロイしたり再デプロイしたりすることのあるリソースについては、ドメインに対して「リソース登録解除の猶予期間」を設定することで、リソースが登録解除されていたためにトランザクションが破棄される可能性を最小限にできます。猶予期間とは、リソースが登録解除される前に、トランザクション・マネージャがトランザクションの完了を待機する秒数です。
指定された猶予期間の間、unregisterResource呼出しは自身が返るまでブロックを行い、関連するリソースに対して新しいトランザクションは開始されません。リソースに対して未処理のトランザクションの数が0になると、unregisterResource呼出しは即座に返ります。
猶予期間の終わりに、まだリソースに関連する未処理のトランザクションがある場合は、unregisterResourceが返り、リソースが以前登録されていたサーバー上にログ・メッセージが書き込まれます。
デフォルトでは、グローバル・トランザクションに参加しているXAリソースがWebLogic Serverトランザクション・マネージャからのXA呼出しに応答しないと、そのリソースに異常があって使用できないことを示すフラグが付加されます。また、リソースのスレッドを保持するため、このリソースに対する以降のすべての呼出しがブロックされます。障害は、トランザクションに異常がある場合でも、リソースに異常がある場合でも発生する可能性があります。これら2つの原因の間に区別はありません。どちらの場合も、リソースに異常があるものとしてマークされます。この制限を軽減するために、WebLogic Serverでは次の構成属性が用意されています。
Maximum Duration of XA Calls: XAリソースに対するXA呼出しの最長許容期間をミリ秒で設定します。
Maximum Duration XA Resource Unavailable: XAリソースが異常とマークされる最長期間(ミリ秒)。
Maximum Resource Requests on a Server: ドメイン内の各サーバーで許容されるリソースへの同時リクエストの最大数。
これらの属性は、ドメイン・レベルとクラスタ・レベルで構成可能です。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「クラスタ: 構成: JTA」および「ドメイン: 構成: JTA」を参照してください。
XAトランザクション・アフィニティにより、サーバー・インスタンスで、関連リクエストを他のメンバー・サーバーにロード・バランシングするのではなく、グローバル・トランザクションへの参加によってこれらのリクエストを処理できます。Enable Transaction Affinity=trueに設定すると、次のような理由から、クラスタのスループットが向上します。
サーバー間のトランザクション調整トラフィックの軽減
JDBC接続の減少など、リソース使用率の改善
トランザクションの非同期処理の簡素化
そのトランザクションに参加しているメンバーがクラスタにない場合、リクエストは利用可能なクラスタ・メンバーへロード・バランシングされます。選択したクラスタ・メンバーに障害が発生した場合は、『Oracle WebLogic Serverクラスタの管理』のJTAトランザクション・リカバリ・サービスの自動移行を構成するためのロードマップに関する項の説明に従って、JTAトランザクション・リカバリ・サービスを移行できます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプでクラスタの構成に関する項を参照してください。コマンド行での-Dweblogic.cluster.TxnAffinityEnabled=trueの使用によって、XAトランザクション・アフィニティを有効にすることもできます。
各サーバーには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション・ログが備わっています。WebLogic Serverでは、システムのクラッシュやネットワーク障害からのリカバリ時にトランザクション・ログ(TLog)が使用されます。トランザクション・ログは直接は表示できません。それらのレコードはバイナリ形式であり、サーバーのデフォルト永続ストアまたはJDBC TLogストアに格納されます。
クラスタ内のサーバーに対するトランザクション・リカバリ・サービスの移行機能を利用するには、トランザクション・ログをサーバーとそのバックアップ・サーバーが使用できる場所(デュアル・ポートSCSIディスクまたはSAN (Storage Area Network)を推奨)に格納する必要があります。詳細は、「デフォルト永続ストアへのパスの設定」を参照してください。
デフォルトのストアがトランザクション・ログ・レコードの保存先とするファイル・システムで領域が不足したり、アクセス不能になったりすると、commit()によりSystemExceptionがスローされ、トランザクション・マネージャによってシステム・エラー・ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。
管理サーバーを含む、各サーバー・インスタンスには、デフォルトの永続ストアがあります。これは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができる、ファイル・ベースのストアです。トランザクション・マネージャは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。多くの場合、デフォルトの永続ストアは、構成を必要としません。ただし、トランザクション・リカバリ・サービスの移行を有効化するには、オリジナルのサーバーで障害が発生した場合に、クラスタ内の別のサーバーで使用できる、永続ストレージ・ソリューションに、データ・ファイルを格納するよう、デフォルトの永続ストアを構成する必要があります。
手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
WebLogic Serverは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。デフォルト・ストアの書込みポリシーを選択し、WebLogic Serverがレコードをディスクに書き込む方法を変更します。詳細は、『Oracle WebLogic Serverサーバー環境の管理』の同期書込みポリシーの構成ガイドラインに関する項を参照してください。
手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
トランザクション・ログがデータベース内に永続的に保持されるようJDBC TLogストアを構成できます。これにより、基礎となるデータベースのレプリケーションやHA特性の活用、障害回復の簡潔化、およびトランザクション・リカバリ・サービスの移行の改善が可能になります。「WebLogic永続ストアの管理」を参照してください。
LLRは、1つの非XAリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。「ロギング・ラスト・リソース・トランザクションの最適化」を参照してください
「トランザクションのリカバリのためのトランザクション・ログ・ファイルの使用」で説明されているように、TLogは、インダウト・トランザクションを解決するために使用されます。ただし、これらのファイルの作成と維持に関連するパフォーマンス・コストは、非常に高くなる可能性があります。たとえば、読取りと書込み、リソース・マネージャ間のネットワーク呼出し、およびHA記憶域などのコストがあります。
注意:
XAトランザクション内のサーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。これらのチェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。次の項では、XAトランザクションの範囲が単一のトランザクション・マネージャ(TM)である場合、TLogを除去することによりXAトランザクションのパフォーマンスが向上させる方法についての情報を提供します。
決定子は、JDBC XAリソースおよびJMS XAリソースで、TLogが存在しない場合に、トランザクション・リカバリにおいてそのリソースのインダウト・トランザクション・レコードが使用されます。
次の項では、グローバル・トランザクションで決定子リソースを使用するためのベスト・プラクティスを紹介します。
決定子リソースのターゲットは、グローバル・トランザクションを実行するサーバーである必要があります。クラスタ環境では、サービスまたはサーバーの移行時に高可用性を確保するため、決定子リソースのターゲットはクラスタである必要があります。
トランザクション・リカバリ・サービスの移行をサポートするには:
JDBC XAリソースの場合は、決定子DataSourceのターゲットをクラスタにします。
JMS XAリソースの場合は、JMSサービスのターゲットを、カスタム永続ストアによって使用されるのと同じ移行可能なターゲットにします。詳細は、『Oracle WebLogic Serverクラスタの管理』のJMSサービスで使用できるカスタム・ストアに関する項を参照してください。
最小限の数の決定子リソースを構成します。これにより、リカバリのために使用できる必要があるリソースの数が少なくなります。
次の各項では、ご使用の環境において決定子を構成、更新および削除する方法を説明します。
注意:
始める前に、「TLogを使用せずにトランザクションを構成する場合の制限と考慮事項」を参照してください。
次の項では、TLogを使用せずにトランザクションを構成する場合の制限と考慮事項に関する重要な情報を示します。
次のような場合には、TLogを使用しないトランザクションの構成はサポートされていません。
複数のTMがグローバル・トランザクションに参加する場合
グローバル・トランザクションにJTSリソースまたはLLRリソースが含まれる場合
WS-AT、OTS、WLSまたはTuxedoトランザクションなどのトランザクション、および外部のトランザクション・マネージャを含むトランザクションに参加する場合
グローバル・トランザクションの処理の一部として、決定子リソースで読取り操作しか実行されない場合
parallel-xa-enabledがfalseに設定されている場合(デフォルト値はtrue)
サーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。チェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。チェックポイントはトランザクションの早い段階で作成されるため、グローバル・トランザクションで参加者に変更がないかぎり、トランザクション・サービスの移行中や複数サイトまたはデータ・センターにわたるトランザクション・リカバリ中にチェックポイントが同期しなくなる危険はほとんどありません。
Abandon Timeout Secondsはサポートされていません。インダウト・トランザクションでは、解決されるかリソースが管理者によって削除されるまで、リカバリが試みられます。
XAトランザクションをリカバリできないために決定子リソースを利用できない場合、WebLogic Serverは起動しません。
決定子リソースのターゲット指定を変更するには、次を実行する必要があります。
その決定子リソースをホストするサーバー上の、すべてのXAトランザクションが完了していることを確認します。
その決定子リソースをホストするすべてのサーバーを停止します。
その決定子リソースのターゲットを再指定します。
その決定子リソースをホストするすべてのサーバーまたはクラスタを起動します。
複数のサーバーがグローバル・トランザクションに参加している場合は、トランザクション・エントリがTLogに書き込まれます。
指定された決定子のリストから、複数の決定子リソースが使用可能な場合は、リストされている最初の決定子が暗黙的にトランザクションの決定子に指定されます。
アプリケーションでは、決定子リソースがあるグローバル・トランザクションと、ないグローバル・トランザクションを組み合せて使用できます。決定子リソースがないグローバル・トランザクションのみがTLogに書き込まれます。
この機能では、動的クラスタはサポートされていません。
この機能では、サーバー全体の移行(WSM)がサポートされています。『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。サービスの移行(ASM)はサポートされていません。
Oracle Database (AQおよびRACを含む)などのリソース・マネージャによって読取り専用最適化が提供される場合、Oracle WebLogicで読取り専用1フェーズ・コミットの最適化を提供することができます。これによって、同一XAトランザクションの複数の接続を有効にする場合でも、Oracle WebLogicとリソース・マネージャの両方に、XAResource.prepareネットワーク・コールの消去やトランザクション・ログ書込みなどの様々な利点がもたらされます。
注意:
読取り専用1フェーズ・コミットの最適化には、Oracle DB 11.1.0.7.3PSU以上が必要です。
2フェーズ・コミット・トランザクションを必要としないアプリケーションの場合、WebLogicの「2フェーズ・コミット」プロトコルを無効にすることで、パフォーマンスをさらに最適化できます。このプロトコルは、2つ以上のリソース・マネージャ全体のトランザクションを調整します。2フェーズ・コミットを無効にするには、次の手順を実行します。
永続的なインダウト・ロギングおよびロック、ならびにデータベースのブックキーピング・オーバーヘッドを削除します。
WebLogicのすべてのチェックポイント・ロギングを削除します。
特定のサーバー・インスタンスが2フェーズ・コミットを必要としないという前提を、施行またはテスト(あるいはその両方を実行)します。
WebLogic移行(サーバーまたはサービス全体)リカバリの必要性を排除します。これによって、その移行に関わる追加のアセット/キャパシティ、管理などの必要性が排除されます。
読取り専用1フェーズ・コミットの最適化を有効にし、2フェーズ・コミットを無効化するには、次のJTAドメイン構成属性を設定します。
XA呼出しの並列実行 - falseに設定すると、読取り専用1フェーズ・コミットの最適化が有効になります。
2フェーズ・コミットの有効化 - (オプション)falseに設定すると、2フェーズ・コミットが無効になります。これによって、チェックポイント・レコードを含むすべてのトランザクション・ロギングが無効になります。2フェーズ・コミットの使用を試行すると、RollbackExceptionがスローされます。
重要: 「2フェーズ・コミットの有効化」設定(デフォルトではtrueに設定されている)は、読取り専用最適化を提供するリソース・マネージャ(Oracleデータベースなど)のみをアプリケーションが使用すること、あるいは単一のリソース・マネージャへの単一の接続のみをアプリケーションが使用することが周知されている場合を除き、falseには設定してはなりません。
注意:
XAリソースがXA_OK投票を準備から返し(例: 対象がOracleデータベースではない場合)、その後ロールバックが発生する前にWebLogicインスタンスがクラッシュする場合は、インダウト・レコードが存在し、ロックがリソース・マネージャ(データベース)で保持されるため、手動で解決する必要があります。
すべてのJTAドメイン構成オプションの詳細は、Oracle WebLogic管理コンソール・オンライン・ヘルプのJTAドメインの構成に関する項を参照してください。
監視目的のため、JTAの「監視」ページには5つのトランザクション処理統計があります。これらの統計はともに「コミット済みトランザクション総数」統計を分類し、あらゆる読取り専用1フェーズ・トランザクション統計を追跡しやすくします。
リソースのないコミット済みトランザクションの合計数 - サーバーの起動以降コミットされた、リソースが確保されていないトランザクションの合計数。
1リソース1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降1フェーズ・コミットされた、1リソースのみが確保されたトランザクションの合計数。
読取り専用1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降、読取り専用最適化のために1フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
2フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降2フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
LLRコミット済みトランザクション合計数 - サーバーの起動以降コミットされたLLRトランザクションの合計数。
注意: JTAトランザクションに列記された唯一のリソースがLLRデータ・ソースの場合、そのトランザクションは「LLRコミット済みトランザクション合計数」カテゴリではなく、「1リソース1フェーズ・コミット済みトランザクション合計数」カテゴリの下に含まれます。
JTA監視統計の詳細は、Oracle WebLogic管理コンソール・オンライン・ヘルプのJTA統計の監視に関する項を参照してください。
