13 WebLogic Serverトランザクション・マネージャでのXAResourceの調整
javax.transaction.xa.XAResource
実装を登録することによって、WebLogic Serverトランザクション・マネージャが調整する分散トランザクションに参加できる方法について理解します。WebLogic Serverトランザクション・マネージャは、2フェーズ・コミット(2PC)プロトコルの一部としてXAResourceを駆動します。これを、「トランザクションのエクスポート」と言います。 サード・パーティ・トランザクション・マネージャがXAResource
インタフェースを実装している場合、トランザクションをエクスポートすることによって、サード・パーティ・トランザクション・マネージャとWebLogic Serverトランザクション・マネージャを統合できます。エクスポートしたトランザクションによって、サード・パーティ・トランザクション・マネージャは、WebLogic Serverトランザクション・マネージャの従属トランザクション・マネージャとして機能できます。
WebLogic Serverも、サード・パーティ・システム(外部トランザクション・マネージャとも呼ばれます)が調整する分散トランザクションに参加できます。WebLogic Serverの処理は、外部トランザクションの処理の一部として行われます。サード・パーティ・トランザクション・マネージャは、コミット処理の一部としてWebLogic Serverのトランザクション・マネージャを駆動します。これは、トランザクションのインポートと呼ばれます。
トランザクションにおけるサード・パーティ・システムの調整(トランザクションのエクスポート)の詳細は、以下の節で説明します。サード・パーティ・システムが調整するトランザクションへの参加(トランザクションのインポート)の詳細は、「サード・パーティ・トランザクション・マネージャで管理されるトランザクションへの参加」を参照してください。WebLogic Server IIOP、WebLogic Tuxedo Connector (WTC)ゲートウェイ、およびOracle Java Adapter for Mainframe (JAM)ゲートウェイの内部では、その章で説明されているのと同じメカニズムにより、WebLogic Serverにおけるトランザクションのインポートおよびエクスポートが行われます。
この章には次の項が含まれます:
外部XAResourceと分散トランザクションの調整の概要
WebLogic Serverトランザクション・マネージャが調整する分散トランザクションに参加するには、サード・パーティのシステムでjavax.transaction.xa.XAResource
インタフェースを実装し、そのXAResource
オブジェクトをWebLogic Serverトランザクション・マネージャに登録する必要があります。
javax.transaction.xa.XAResource
インタフェースの実装に関する詳細は、次の場所でJava Platform Enterprise Edition API仕様を参照してください:
http://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html
トランザクション処理時は、サード・パーティ・システムのXAResource
オブジェクトを適切な各トランザクション・オブジェクトに登録する必要があります。
図13-1に、WebLogic Serverトランザクション・マネージャによって調整されるトランザクションへのサード・パーティ製システムの参加プロセスを示します。
XAResourceオブジェクトをトランザクションに登録する際に使用する登録モードに応じて、WebLogic Serverは、適切な時にXAResourceオブジェクトを自動的に登録解除する場合があります。登録および登録解除の詳細は、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。XAResourceオブジェクトをWebLogic Serverトランザクション・マネージャで登録する処理の詳細は、「XAResourceのトランザクションへの参加の登録」を参照してください。
XAResourceのトランザクションへの参加の登録
WebLogic Serverトランザクション・マネージャが調整する分散トランザクションに参加するには、サード・パーティのシステムでjavax.transaction.xa.XAResource
インタフェースを実装し、そのXAResource
オブジェクトをWebLogic Serverトランザクション・マネージャに登録する必要があります。
以下の処理のために登録が必要となります。
-
XAResource
のトランザクション・ブランチ修飾子の指定。ブランチ修飾子はリソース・マネージャ・インスタンスのトランザクション・ブランチを識別し、リソース・マネージャ(RM)インスタンスが参加するすべての分散トランザクションに使用されます。各トランザクション・ブランチは分散トランザクションの処理の1単位を表し、他のブランチとは分離しています。各トランザクション・ブランチは、2フェーズ・コミット(2PC)処理時に、準備とコミットの呼出しのセットを1つだけ受け取ります。WebLogic Serverトランザクション・マネージャは、トランザクション・ブランチ修飾子としてリソース名を使用します。リソース・マネージャ・インスタンスは
XAResource.isSameRM
メソッドによって定義されます。同じリソース・マネージャ・インスタンスに属するXAResourceインスタンスは、isSameRM
に対してtrueを返すことになります。トランザクション・ブランチの混乱を避けるために、同じリソース・マネージャ・インスタンスを異なるリソース名(異なるリソース・ブランチ)で登録しないでください。 -
登録モードの指定。リソース・マネージャ・インスタンスが特定の分散トランザクションに参加するには、XAResourceインスタンスをJTA
javax.transaction.Transaction
オブジェクトに登録する必要があります。WebLogic Serverのトランザクション・マネージャでは、静的、動的、およびオブジェクト指向の3つの登録モードが用意されています。登録モードの詳細は、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。 -
WebLogic Serverトランザクション・マネージャがクラッシュのリカバリを行う必要がある場合の
XAResource
のブート・ストラップ。(JTA仕様は、それを行う標準APIを定義していません。http://www.oracle.com/technetwork/java/javaee/jta/index.html
の「Java Transaction API」を参照してください)。Java Transaction APIでは、ブランチ修飾子の割当てはトランザクション・マネージャで行うことが推奨されます。ただし、適切にリカバリを行うには、正常な処理時とクラッシュ・リカバリ時の両方において、同じトランザクション・ブランチ修飾子が提供される必要があります。トランザクション・ブランチ修飾子が登録時に指定されるため、WebLogic Serverトランザクション・マネージャでの登録が、クラッシュのリカバリと正常なトランザクション処理をサポートするために必要となります。
リカバリ時に、WebLogic Serverトランザクション・マネージャは以下のタスクを行います。
-
トランザクション・マネージャのトランザクション・ログ・レコードと、記録されている分散トランザクションに参加したXAリソースのログ・レコードの読み込み、および2PCプロトコルの第2フェーズの続行と指定したブランチ修飾子のXAリソースのコミット。
-
XAResource.recover
を呼び出すことによる、XAリソースのすべての不明なトランザクションの解決。続いて、これに属する返されたトランザクション(Xids)のコミットまたはロールバック。(返されたXidは、すでに特定のブランチ修飾子を持っている場合があります。)ノート:
ここで述べる登録はプロセスごとの処理です(トランザクションごとの登録および登録解除とは異なります)。
-
XAResource実装をWebLogic Serverトランザクション・マネージャに登録しないと、予期しないトランザクション・ブランチ動作を引き起こす可能性があります。XAリソースがWebLogic Server分散トランザクションに登録される前にこの登録を行わないと、WebLogic Serverトランザクション・マネージャはリソース名(ブランチ修飾子)としてXAResourceインスタンスのクラス名を使用します。これによって、望ましくないリソース名やトランザクション・ブランチの競合が発生する可能性があります。
各リソース・マネージャ・インスタンスが、自身を一度だけWebLogic Serverトランザクション・マネージャに登録するようにしてください。各リソース・マネージャ・インスタンスは登録時にリソース名によって識別されるので、リカバリ、コミット処理、およびヘルス監視時にシステムに過大なオーバーヘッドが加わり、関連する内部データ構造によって使用されるメモリーが増加し、内部マップの検索効率が低下します。したがって、スケーラビリティおよびパフォーマンスの理由から、異なるトランザクション・ブランチでXAResourceインスタンスをむやみに登録しないようにする必要があります。
JTA XAResourceでは明示的なトランザクション・モデルが採用されています。このモデルでは、Xidが常にXAResourceメソッドで明示的に渡され、1つのリソース・マネージャ・インスタンスがすべてのトランザクションを処理します。これは、暗黙的なトランザクション・モデルが採用されているCORBA OTSリソースと対照的です。このモデルでは、参加対象の各トランザクションに対して異なるOTSリソース・インスタンスが存在します。XAResourceを設計する際は、JTAモデルを使用する必要があります。
各外部リソース・マネージャ・インスタンスは、サーバーの起動時にWebLogic Serverトランザクション・マネージャにXAResourceインスタンスを登録する必要があります。WebLogic Serverでは、起動クラスを使用して、外部トランザクション・マネージャを登録できます。
WebLogic Serverトランザクション・マネージャにリソース・マネージャを登録するステップは次のとおりです。
さまざまな登録モードの詳細については、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。XAResourceの登録時に以降に使用される登録モードを指定しますが、その登録プロセスの間に実際にリソースを登録しているわけではありません。実際の登録は、(サーバー起動時ではなく)トランザクションで別のAPIを使用して行う必要があります。詳細については、「トランザクションにおけるXAResourceの登録と登録解除」を参照してください。
登録する各XAResourceインスタンスは、複数のトランザクションのリカバリおよびコミット処理に並列的に使用されます。JTA仕様バージョン1.0.1Bのセクション3.4.6で定義されているリソース共有をXAResourceインスタンスがサポートしていることを確認してください。
ノート:
同じXAResourceの重複登録は無視されます。
リソースで新しいリクエストを受け付けなくなったら、WebLogic Serverトランザクション・マネージャからXAResourceの登録を解除する必要があります。XAResourceの登録を解除するには、次のメソッドを使用します。
tm.unregisterResource(name, res);
トランザクションにおけるXAResourceの登録と登録解除
XAResourceが分散トランザクションに参加するには、XAResourceインスタンスがトランザクション・オブジェクトに登録される必要があります。登録モードに応じて、異なる処理を実行する必要がある場合があります。
WebLogic Serverトランザクション・マネージャでは、以下の登録モードがサポートされています。
XAResourceはトランザクション・オブジェクトに登録しますが、登録モードが決定するのは、リソースをトランザクションに登録するときではなく、WebLogic Serverトランザクション・マネージャにXAResourceを登録するときです。「XAResourceのトランザクションへの参加の登録」を参照してください。
XAResource.start
およびend
の呼出しは、コストがかかる場合があります。WebLogic Serverトランザクション・マネージャでは、これらの呼出しの数を最小化するために以下の最適化方法が提供されています。
-
遅延登録解除
WebLogic Serverトランザクション・マネージャはXAResource実装が明示的な登録解除を行うかどうかに関わらず、XAResourceが登録解除される以下のイベントが発生する直前までは、現在のトランザクションに登録されているすべてのXAResourceインスタンスの登録解除を常に遅延します。
-
呼出しが正常に、または例外として呼出し側に返されます。
-
別のサーバーが呼び出されます。
-
-
重複登録の無視
WebLogic Serverトランザクション・マネージャは、すでに登録されているXAResourceの明示的な登録をすべて無視します。これは、XAResourceが明示的に登録解除され(前述のようにWebLogic Serverトランザクション・マネージャによって遅延または無視され)、同じ呼出しの間の中で続いて再登録されている場合に起こることがあります。
WebLogic Serverトランザクション・マネージャではデフォルトで、TMSUSPEND
フラグが指定されたXAResource.end
を呼び出すことによってXAResourceを登録解除します。TMSUSPEND
が指定されたXAResource.end
が呼び出されると、カーソルが開いたままになるデータベース管理システムもあるので、可能なかぎり、TMSUCCESS
を指定したXAResource.end
を呼び出してXAResourceを登録解除するようにしてください。これを行うには、javax.transaction.xa.XAResource
のかわりにgetDelistFlag
メソッドが含まれるweblogic.transaction.XAResource
インタフェースを実装します。詳細は、Oracle WebLogic Server Java APIリファレンスの
weblogic.transaction.XAResourceを参照してください。
標準的な登録
標準的な登録モードでは、トランザクション・オブジェクトにXAResourceインスタンスを登録するのは一度だけです。また、同じトランザクションに同じブランチのXAResourceインスタンスを2つ以上登録することもできます。WebLogic Serverトランザクション・マネージャでは、すべてのXAResourceインスタンスに対して適切な場合にXAResource.end
が呼び出されます(次の説明を参照)。WebLogic Serverトランザクション・マネージャでは、トランザクションのコミット時に、各ブランチが準備とコミットの呼出しのセットを1つだけ受け取ります。ただし、登録済の特定のXAResourceインスタンスの登録は無視されます。
標準的な登録では登録が簡素化されますが、特定のメソッド呼出しの間の中でリソースが全くアクセスされない場合には、XAResourceの不必要な登録および登録解除が生じる可能性もあります。
トランザクション・オブジェクトにXAResourceを登録するには、以下のステップに従います。
XAResourceをトランザクションに登録すると、WebLogic Serverトランザクション・マネージャによって、以降のすべての登録解除(「トランザクションにおけるXAResourceの登録と登録解除」を参照)および再登録が管理されます。標準的な登録モードでは、WebLogic Serverトランザクション・マネージャは、以下の場合に同じトランザクションでXAResourceを再登録します。
-
リクエストが実行される前
-
別のサーバーから応答が受信された後。(WebLogic Serverトランザクション・マネージャは、別のサーバーにリクエストを送信する前にXAResourceを登録解除します。)
動的な登録
動的な登録モードでは、リソースの各アクセス前にトランザクション・オブジェクトにXAResourceインスタンスを登録する必要があります。この登録モードでは、各トランザクションに一度に登録できるXAResourceインスタンスは、各トランザクション・ブランチから1つのみです。WebLogic Serverトランザクション・マネージャは、最初のインスタンスが登録されてから登録解除されるまでの間、同じトランザクション・ブランチの別のXAResourceインスタンスの登録を無視します。
動的な登録では、XAResourceインスタンスの登録と登録解除は最小限に抑えられます。
XAResourceを登録するステップは、「標準的な登録」で説明したステップと同じです。
静的な登録
静的な登録モードでは、トランザクション・オブジェクトにXAResourceインスタンスを登録する必要はありません。XAResourceは、以下のイベントの際にWebLogic Serverトランザクション・マネージャによって、すべてのトランザクションについて暗黙的に登録されます。
-
リクエストが実行される前
-
別のサーバーから応答が受信された後
ノート:
静的な登録モードを使用する前に以下の点を考慮する必要があります。
-
静的な登録モードではXAResourceを登録する必要がありません。ただし、リソースが特定のトランザクションで使用されない場合、不必要な登録および登録解除に繋がる可能性があります。
-
リソースがトランザクションで使用されない場合でも、問題のあるXAResourceによって、すべてのトランザクションが悪影響を受ける可能性があります。
-
1つのXAResourceインスタンスを使用して異なるトランザクションとスレッドを一度に関連付けます。つまり、複数のスレッドの異なるXidについて、同じXAResourceインスタンス上で
XAResource.start
およびXAResource.end
を交互に呼び出すことができます。XAResourceがこのような関連付けパターンをサポートするようにする必要があります。これはJTA仕様では要求されていません。
静的な登録には、パフォーマンスに対するオーバーヘッド、アイソレーションの問題、およびトランザクション関連付け要件が厳しいという理由があるため、十分に検討した上で慎重に使用する必要があります。
-
コミット処理
コミット処理の間、WebLogic Serverトランザクション・マネージャは、2フェーズ・コミットを行うため、トランザクション・マネージャに登録されているXAResourceインスタンスか、トランザクションに現在登録されているXAResourceインスタンスのいずれかを使用します。
WebLogic Serverトランザクション・マネージャでは、各トランザクション・ブランチが準備とコミットの呼出しのセットを1つだけ受け取ります。JTA仕様バージョン1.0.1Bのセクション3.4.6で定義されているように、様々なスレッドから同時に複数のトランザクションのコミット処理を行うために、どのようなXAResourceインスタンスも使用できるようにする必要があります。
リカバリ
WebLogic Serverサーバーが再起動されると、WebLogic Serverトランザクション・マネージャは自身のトランザクション・ログ(正常に準備されたが、2PC処理の第2コミット・フェーズを終了していない可能性のあるトランザクションのログ・レコード)を読み込みます。WebLogic Serverトランザクション・マネージャは次に、これらのトランザクションのXAResourceのコミットの再試行を続行します。
「XAResourceのトランザクションへの参加の登録」で説明したように、WebLogic Serverトランザクション・マネージャのリソース登録APIは、リカバリを目的としたXAResourceインスタンスのブート・ストラップにも使用されます。サーバーの再起動時にXAResourceインスタンスがWebLogic Serverトランザクション・マネージャに登録されていることを確認する必要があります。WebLogic Serverトランザクション・マネージャは、有効なXAResourceインスタンスがWebLogic Serverトランザクション・マネージャに登録されるまで、コミット呼出しを毎分再試行します。
トランザクション・コーディネータとして機能しているトランザクション・マネージャがクラッシュすると、コーディネータのトランザクション・ログにいくつかの不明なトランザクションが記録されないこともあります。したがって、コーディネータではサーバーの再起動時に、リソース・マネージャに対してXAResource.recover
を呼び出し、記録されなかった不明なトランザクションをロールバックする必要があります。コミットの再試行と同様に、WebLogic Serverトランザクション・マネージャは、有効なXAResourceインスタンスがWebLogic Serverトランザクション・マネージャに登録されるまで、5分間隔でXAResource.recover
を再試行します。
WebLogic Serverトランザクション・マネージャは、新しいXAResourceが最初にWebLogic Serverトランザクション・マネージャに登録される際、トランザクション・ログ・レコードにそのチェックポイントを記録します。サーバーの再起動時に、WebLogic Serverトランザクション・マネージャは、前にチェックポイントが記録され(トランザクション終了後にトランザクション・ログ・レコードから削除され)たすべてのリソースに対してXAResource.recover
を呼び出します。リソースがチェックポイント記録から削除されるのは、最後のPurgeResourceFromCheckpointIntervalSeconds
間隔(デフォルトは24時間)にアクセスされていない場合のみです。したがって、リソース・リカバリのオーバーヘッドを軽減するには、WebLogic Serverトランザクション・マネージャに登録されているリソース・マネージャ・インスタンスの数を最小限にする必要があります。
XAResource.recover
を実装する際は、以下に示すX/Open XA仕様で説明されているようにフラグを使用する必要があります。
-
WebLogic Serverトランザクション・マネージャで、
TMSTARTRSCAN
が指定されたXAResource.recover
を呼び出すと、不明Xidの最初のバッチがリソースによって返されます。WebLogic Serverトランザクション・マネージャでは次に、リカバリすべきXidがこれ以上ないことを示すnullまたは長さゼロの配列のいずれかがリソースによって返されるまで、
TMNOFLAGS
が指定されたXAResource.recover
の呼出しを繰返し行います。前のXAResource.recover(TMSTARTRSCAN)
呼出しですべてのXidがリソースによってすでに返されている場合、ここでnullまたは長さゼロの配列が返されるか、前のリカバリ・スキャンがすでに終了および削除されたことを示すXAER_PROTO
がスローされることもあります。XAResource.recover
実装の一般的な問題は、フラグが無視されることや、XAResource.recover(TMNOFLAGS)
に対して常に同じXidのセットが返されることです。これによって、WebLogic Serverトランザクション・マネージャのリカバリが無限ループに陥り、後の失敗が引き起こされます。 -
WebLogic Serverトランザクション・マネージャで
TMENDRSCAN
フラグが指定されたXAResource.recover
を呼び出すと、リカバリ・スキャンが終了します。追加のXidがリソースによって返される場合があります。
リソース・ヘルス監視
問題のあるXAResourceに対してサーバー・スレッドを失わないように、WebLogic Server JTAには内部リソース・ヘルス監視のメカニズムがあります。リソースがアクティブであると見なされるのは、保留中のリクエストが存在しない場合、またはXAResourceの保留中のリクエストの結果がXAER_RMFAIL
ではない場合です。XAResourceが2分以内にアクティブにならない場合、WebLogic Serverトランザクション・マネージャはXAResourceを応答なしと宣言します。
XAResourceに対する新たなリクエストは拒否され、XAER_RMFAIL XAException
がスローされます。
2分という間隔は、maxXACallMillis
JTAMBean属性を介して構成できます。maxXACallMillis
は、config.xml
ファイル内で構成できます。たとえば:
<Domain> .... <JTA MaxXACallMillis="240000" /> .... </Domain>
WebLogic Serverトランザクション・マネージャから通知を受信し、リソースが応答なしと宣言されようとしている際に、本当に応答なしかどうかをWebLogic Serverトランザクション・マネージャに通知するには、weblogic.transaction.XAResource
(javax.transaction.xa.XAResource
を拡張)を実装し、これをトランザクション・マネージャに登録します。トランザクション・マネージャは、XAResourceが利用できないことを宣言しようとする際に、そのdetectUnavailable
メソッドを呼び出します。XAResourceからtrue
が返されると、利用できないと宣言されることはありません。XAResourceが本当に利用できない場合には、この機会にクリーンアップおよびトランザクション・マネージャへの再登録を行うこともできます。Oracle WebLogic Server Java APIリファレンスのweblogic.transaction.XAResource
を参照してください。
Java EEコネクタ・アーキテクチャのリソース・アダプタ
WebLogic Serverトランザクション・マネージャに直接登録する他に、Java EEコネクタ・アーキテクチャのリソース・アダプタ・インタフェースを実装することもできます。リソース・アダプタをデプロイする際、リソース・マネージャのXAResourceは、WebLogic Server Java EEコンテナによってWebLogic Serverトランザクション・マネージャに自動的に登録されます。
『Oracle WebLogic Serverリソース・アダプタの開発』を参照してください。
実装のヒント
WebLogic Serverトランザクション・マネージャでのトランザクションのエクスポートとインポートのヒントについて学習します。
WebLogic Serverトランザクション・ログの共有
WebLogic Serverトランザクション・マネージャは、ゲートウェイなどのシステム・アプリケーションで共有されるようにトランザクション・ログを公開します。これによって、高速ロギングのためにWebLogic Serverトランザクション・マネージャの一括(バッチ)処理のトランザクション・ログ最適化をシステム・アプリケーションで利用できます。トランザクション・ログ・レコードは適時に解放することが重要となります(WebLogic Serverトランザクション・マネージャは、トランザクション・ログ・ファイル内のすべての記録が解放された場合にのみトランザクション・ログ・ファイルを削除します)。これができないと、トランザクション・ログ・ファイルが多数作成され、コミット済みのトランザクションの多くが再コミットされ、極端なケースでは、循環衝突やトランザクション・ログ・ファイルの上書きが発生する可能性があります。
WebLogic Serverトランザクション・マネージャは、トランザクション・ログ機能インタフェースweblogic.transaction.TransactionLogger
を公開しています。これはサーバー上でのみ使用でき、以下のステップで取得できます。
XAResourceのログ・レコードは、トランザクション・ログに記録されるために、weblogic.transaction.TransactionLoggable
インタフェースを実装する必要があります。weblogic.transaction.TransactionLogger
インタフェースの詳細とTransactionLogger
インタフェースの使用に関する詳細は、Oracle WebLogic Server APIリファレンスの
weblogic.transaction.TransactionLoggerを参照してください。
トランザクションのグローバル・プロパティ
WebLogic Server JTAトランザクション・オブジェクトは、ローカルおよびグローバルのプロパティに関連付けられます。グローバル・プロパティは、トランザクション伝播コンテキストでサーバー間を伝播され、トランザクション・ログにログ・レコードの一部としても保存されます。トランザクションのグローバル・プロパティにアクセスするには、以下の手順に従います。
Oracle WebLogic Server Java APIリファレンスのweblogic.transaction.TxHelper
を参照してください。
TxHelper.createXid
TxHelper.createXid(int formatId, byte[] gtrid, byte[] bqual)
メソッドを使用するとXid
を作成できます。作成したXidは、たとえば、リカバリ時にWebLogic Serverトランザクション・マネージャに返すことができます。
Oracle WebLogic Server Java APIリファレンスのweblogic.transaction.TxHelper
を参照してください。
リソース登録名の変更点
このリリースでは、XAデータ・ソース構成のリソース登録名の動作が変更されました。以前のリリースでは、JTAの登録名はデータ・ソースの名前のみでした。今後は、データ・ソース名とドメインの組合せになります。
JTAに登録されたすべてのリソースには、対応する実行時MBeanが存在し、MBeanを通じてそのリソースのXA使用状況の統計が公開されます。今回の変更により、MBeanのJMX ObjectName
が変わる(修飾される)ため、既存のアプリケーションでそのような実行時MBeanのJMXルックアップを名前に基づいて実行している場合は、何らかの影響を受ける可能性があります。旧リリースでは、ドメインmydomain
のmydatasource
という名前を持つデータ・ソース構成の場合、JTAリソースの実行時MBeanは、次のようなオブジェクト名で登録されていました。
com.bea:ServerRuntime=myserver,Name=mydatasource,Type=TransactionResourceRuntime,JTARuntime=JTARuntime
このリリースでは、次のように修飾されたオブジェクト名が使用されます。
com.bea:ServerRuntime=myserver,Name=mydatasource_mydomain,Type=TransactionResourceRuntime,JTARuntime=JTARuntime
トランザクション・ブランチ修飾子は、JTAリソース登録名からも派生します。そのため、アップグレード時に存在するXAデータ・ソースの保留トランザクション・ブランチは、アップグレード後にリカバリできないことがあります。アップグレードは、データベース・リソースに保留トランザクションが残っていない状態で実行することをお薦めします。そうでないと、場合によってはデータベース管理者がそれらを手動で解消することが必要になります。次を参照
このリリースでは、登録名の修飾を無効にするための次のようなシステム・プロパティが新たに使用できるようになりました。
-Dweblogic.jdbc.qualifyRMName=false
FAQ
トランザクション関連のよくある質問について理解します。
-
XAResourceのXidにはブランチ修飾子があるのに、トランザクション・マネージャのトランザクションにブランチ修飾子がないのはなぜですか。
WebLogic Server JTAトランザクション・オブジェクトはブランチ修飾子は持ちません(すなわち、
TxHelper.getTransaction().getXid().getBranchQualifier()
はnullになります)。ブランチ修飾子は個々のリソース・マネージャに固有のため、WebLogic Serverトランザクション・マネージャは、XAResourceメソッドに渡されるXidでのみブランチ修飾子を設定します。 -
TxHelper.getTransaction()
メソッドの使用目的は何ですか。WebLogic Server JTAでは、現在のスレッドに関連付けられたトランザクションを返すために、
TxHelper.getTransaction()
APIが提供されています。ただし、WebLogic Server JTAは、XAResourceメソッドを呼び出す前にトランザクション・コンテキストをサスペンドするので、トランザクションを識別するために信頼できるのは、現在のスレッドに関連付けられたトランザクションではなく、Xid入力パラメータのみです。
JTAに関するその他のドキュメント
トランザクション・マネージャとリソース・マネージャの間のJTA対話を示す、接続ベースのリソース使用のシナリオに関する追加のドキュメントは、JTA仕様で提供されています。
接続ベースのリソース使用のシナリオについては、JTA仕様1.0.1Bのセクション4.1を参照してください。トランザクション・マネージャとリソース・マネージャの間のJTA対話について説明されています。JTA仕様はhttp://www.oracle.com/technetwork/java/javaee/jta/index.html
にあります。