2 トランザクションの構成
この章には次の項が含まれます:
トランザクション構成の概要
トランザクション構成は、WebLogic JTAなどのWebLogic Serverの機能を構成するためのインタフェースを備えている管理コンソールを通じて処理できます。
構成プロセスでは、属性の値を指定する必要があります。それらの属性によって、以下のようなトランザクション環境が定義されます。
-
トランザクションのタイムアウトと制限
-
トランザクション・マネージャの動作
また、EJB、JDBCデータ・ソース、JMSなど、トランザクションに参加可能なJava EEコンポーネントの管理についてもよく理解しておく必要があります。
ノート:
トランザクション関連の構成には、WebLogic Scripting Tool (WLST)(『WebLogic Scripting Toolの理解』を参照)またはJMX(『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照)を使用することもできます。
JTAの構成
JTA設定をドメイン・レベルまたはクラスタ・レベルで構成できます。WebLogic JTAおよび任意のトランザクション参加コンポーネントを構成すると、システムはJTA APIおよびWebLogic JTA拡張機能を使用してトランザクションを管理できます。
次の点に注意してください。
-
JTA (トランザクション)の構成設定は、次のように、ドメイン・レベルおよびクラスタ・レベルで適用できます。
-
ドメイン・レベルでは、属性の設定はドメイン内のすべてのサーバーに適用されます。これらの設定は、クラスタ・レベルの設定に差し替えられます。表2-1を参照してください
-
クラスタ・レベルでは、属性の設定はドメイン内の1つのクラスタに適用されます。これらの設定は、ドメイン・レベルの設定に優先します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタ: 構成: JTAに関する項を参照してください。
-
-
JTAのモニター・タスクは、サーバー・レベルで実行されます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAの監視に関する項を参照してください。
-
参加リソース(JDBCデータ・ソースなど)の構成設定は、構成されるオブジェクトごとに行われます。設定は、特定のオブジェクトのすべてのインスタンスに対して適用されます。『Oracle WebLogic Server JDBCデータ・ソースの管理』の「JDBCデータ・ソース・トランザクション・オプション」、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースのグローバル・トランザクション・オプションの構成に関する項を参照してください。
表2-1 JTAの構成オプション(トランザクション)
名前 | 説明 |
---|---|
タイムアウト |
2フェーズ・コミット・トランザクションの最初のフェーズでアクティブ・トランザクションが許容される最大秒数を指定します。指定した時間をすぎると、トランザクションは自動的にロールバックされます。 MBean属性: 最小値: 1 最大値: 2147483647 注意: DBMSには、XAトランザクションがDBMSロックを保持する最大許容期間である、独自の |
破棄タイムアウト |
トランザクション・マネージャが2フェーズ・コミット・トランザクションの2番目のフェーズの完了を試行する最大時間(秒)を指定します。 2フェーズ・コミット・トランザクションの2番目のフェーズで、トランザクション・マネージャは、すべてのリソース・マネージャがトランザクション完了を示すまでトランザクションを完了しようとします。中止トランザクション・タイマーの期限が切れた後、トランザクションを解決するための試行は行われなくなります。トランザクションが破棄される前に準備状態に入った場合、トランザクション・マネージャはトランザクションをロールバックし、破棄されたトランザクションのかわりに保持されたロックを解放します。 MBean属性: 最小値: 1 最大値: 2147483647 注意: まだアクティブになっているトランザクションを破棄して保留のままにできるため、 |
beforeCompletionの反復上限 |
トランザクション・マネージャが、このWebLogic Serverドメインに対してbeforeCompletion同期化コールバックを実行するサイクルの最大数。 同期化オブジェクトはbeforeCompletionsがすでに呼び出されたオブジェクトであっても、beforeCompletionで別のオブジェクトを登録できます。たとえばEJBは、その MBean属性: 最小値: 1 |
最大トランザクション数 |
このWebLogic Serverドメインのサーバーで許可される同時進行トランザクションの最大数。 MBean属性: 最小値: 1 最大値: 2147483647 |
一意名の最大数 |
保持する統計の対象となる一意なトランザクション名の最大数。 最初の1001件の一意のトランザクション名は固有のトランザクション名で保持され、各統計に保存されます。1002件目以降のトランザクション名は トランザクション名は、通常、ビジネス・トランザクションのカテゴリを表します(送金など)。 MBean属性: 最小値: 0 最大値: 2147483647 |
チェックポイント間隔 |
トランザクション・マネージャが、新しいトランザクション・ログ・ファイルを作成し、すべての古いトランザクション・ログ・ファイルをチェックしてそれらを削除できるかどうかを確認する間隔。 MBean属性: 最小値: 10 最大値: 1800 |
決定子が構成されている場合は、リカバリ・ログが書き込まれます |
決定子が1つ以上構成されている場合でも、2フェーズ・トランザクション・リカバリ・ログが書き込まれることを示します。 |
決定子 |
リソースのリストからトランザクション・リソース(決定子)を選択します。JMSの場合は、WebLogic JMSを決定子として選択します。決定子が構成されている場合、決定子の不確かなトランザクション・レコードがトランザクション・リカバリ時に使用されます。 MBean属性: |
ヒューリスティックの無視 |
トランザクション・マネージャがトランザクションのヒューリスティックな終了に対して自動的にXA Resource forget処理を実行するかどうかを指定します。 有効化すると、トランザクション・マネージャは、トランザクションがヒューリスティックな結果を認識するとすべてのリソースの MBean属性: |
リソース登録解除の猶予期間 |
トランザクション・マネージャが、リソースの関与するトランザクションの完了をリソースが登録解除されるまでに待機する時間(秒)。この猶予期間の設定は、登録解除されたリソース(アプリケーションと一緒にパッケージされているJDBCデータ・ソース・モジュールなど)が原因でトランザクションが破棄されるリスクを最小限に抑えるために役立ちます。 指定された猶予期間の間、 猶予期間の終わりに、リソースに関連する未処理のトランザクションがある場合は、 MBean属性: 最小値: 0 最大値: 2147483647 |
XA呼出しの並列実行 |
使用可能なスレッドがある場合にXA呼出しを並列に実行することを示します。 MBean属性: |
2フェーズ・コミットの有効化 |
複数のリソース・マネージャ間でトランザクションを調整するために2フェーズ・コミット・プロトコルを使用するかどうかを示します。 選択されていない場合:
MBean属性: |
密結合トランザクションの有効化 |
異なるトランザクション・マネージャ・システムにまたがるトランザクション・ブランチの密結合を示します。 有効にした場合、内部でマップされたXidではなく、XA呼出し用の WebLogicリソースとTuxedoリソースの間のトランザクションで、GridLinkアフィニティが有効なGridLinkデータ・ソースが使用される場合、XAアフィニティ・コンテキストは自動的にトランザクションに使用されます。 |
クラスタ全体の回復の有効化 |
分散トランザクションに対してクラスタ全体のリカバリが使用されることを示します。 有効化した場合、 MBean属性: |
拡張構成オプションについては、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トランザクション・クラスタ・アフィニティ
XAトランザクション・アフィニティにより、サーバー・インスタンスで、関連リクエストを他のメンバー・サーバーにロード・バランシングするのではなく、グローバル・トランザクションへの参加によってこれらのリクエストを処理できます。Enable Transaction Affinity=true
に設定すると、次のような理由から、クラスタのスループットが向上します。
-
サーバー間のトランザクション調整トラフィックの軽減
-
JDBC接続の減少など、リソース使用率の改善
-
トランザクションの非同期処理の簡素化
そのトランザクションに参加しているメンバーがクラスタにない場合、リクエストは利用可能なクラスタ・メンバーへロード・バランシングされます。選択したクラスタ・メンバーに障害が発生した場合は、『Oracle WebLogic Serverクラスタの管理』のJTAトランザクション・リカバリ・サービスの自動移行を構成する手順に関する項の説明に従って、JTAトランザクション・リカバリ・サービスを移行できます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの構成に関する項を参照してください。コマンド行での-Dweblogic.cluster.TxnAffinityEnabled=true
の使用によって、XAトランザクション・アフィニティを有効にすることもできます。
JTA通信用のネットワーク・チャネルの構成
ネットワーク・チャネルは、ネットワーク・トラフィックを分離およびロード・バランシングするために構成できる、WebLogic Serverの構成可能なリソースです。また、内部サーバー通信をクライアント・ユーザー通信から分離するようにネットワーク・チャネルを構成することもできます。
WebLogic Serverによって、デフォルト・ネットワーク・チャネルが自動的に生成されます。デフォルト・ネットワーク・チャネルのかわりにJTA通信用のカスタム・ネットワーク・チャネルを構成できます。WebLogic Serverトランザクション・マネージャでは、複数のサーバーを更新する分散トランザクションを調整するために、これらのカスタム・ネットワーク・チャネルを使用します。
JTA通信用に指定したネットワーク・チャネルでは、クロスドメインJTA通信と、デフォルト・ネットワーク・チャネルで構成されたサーバーとの相互運用のために、内部アドレスと外部アドレスの混在指定がサポートされています。アプリケーションが(EJBなどの)リモート・オブジェクトや(JMS、JDBCなどの)リソースにアクセスすると、グローバル・トランザクション・コンテキストがサーバー間を伝播されます。各サーバーはローカル・アドレス情報をトランザクション・コンテキストに追加して、他のサーバーが自身との通信にそれを使用できるようにします。トランザクション・コンテキストには、調整を行うサーバーおよびすべての下位サーバーのアドレス情報が含まれています。
サーバーの初期化中に、ローカル・サーバーを表すコーディネータURLが、静的構成および実行時オーバーライドからのアドレス情報を使用して構成されます。ローカル・サーバーのコーディネータURLは、コーディネータ割当て時に、またはリモート・サーバーでトランザクション伝播コンテキストが受信されるときに、トランザクション・コンテキストに追加されます。リモート・コーディネータの割当てでは、アウトバウンドRMI呼出し中にRMI接続から取得されて伝播コンテキストに追加されたリモート・サーバーの情報からコーディネータURLが作成されます。
サーバー・ネットワーク・チャネル構成から取得された最大4つのタイプのURLをJTAインターサーバー通信用に作成できます:
- プライマリ
- セキュア
- パブリック
- パブリック・セキュア
作成されたURLは、コーディネータと下位サーバーを識別するために使用されるJTA記述子とともに格納され、サーバー間で伝播されて、トランザクション・コンテキストおよびサーバー・チェックポイント・レコードで永続化されます。サーバー参加者がリモート参加者用のコーディネータまたはサブコーディネータ・リモート・オブジェクトを取得する必要がある場合、4つのURLのうち1つを使用して、JNDI初期コンテキストが確立され、ルックアップが実行されます。
ネットワーク・チャネルの構成の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項およびチャネルの構成に関する項を参照してください。WebLogic Server管理コンソールまたはNetworkAccessPointMBean
を使用して、ネットワーク・チャネルを構成し、protocol
、listen address
、listen port
、public address
、public port
属性を設定してJTAコーディネータURLを構成します。
サーバーURLの構成
次の例では、ポート7001
および7101
に対応するネットワーク・アドレスでt3
トラフィックをリスニングするサーバーの構成を示します。
例2-1 サーバー構成
<server>
<name>myserver</name>
<listen-port>7001</listen-port>
<listen-port-enabled>true</listen-port-enabled>
<listen-address>myhost</listen-address>
<network-access-point>
<name>channelt3</name>
<protocol>t3</protocol>
<listen-address>myhost</listen-address>
<public-address>publicaddress</public-address>
<listen-port>7101</listen-port>
<public-port>7101</public-port>
</network-access-point>
</server>
コーディネータURLはネットワーク・チャネル構成から導出され、<protocol>://host:port
という形式になります。この例で定義されたサーバーのネットワーク構成でサポートされるURLは、t3://myhost:7001
、t3://myhost:7101
およびt3://publicaddress:7101
です。
JTAネットワーク・チャネルの構成でサポートされるサーバー・レベル属性は、次のとおりです:
ServerMBean.TransactionPrimaryChannelName
–サーバーとの内部JTA通信用のプライマリURLを導出するために使用されるサーバー・ネットワーク・チャネルの名前。設定しない場合、プライマリURLは、サーバーのデフォルト・チャネル構成を使用して初期化されます。表2-2 プライマリURLを使用するネットワーク・チャネルの例
プロトコル listen-address:listen-port public-address:public-port プライマリURL t3
host:7001
NA t3://host:7001
t3
host:7001
public-address:7201
t3://public-address:7201
ServerMBean.TransactionSecureChannelName
– セキュア通信で使用されるサーバー・ネットワーク・チャネルの名前。ネットワーク・アクセス・ポイント構成には、t3s
プロトコルが必要です。この属性を指定しない場合、セキュアURLにデフォルト・セキュア・チャネルが使用されます(有効になっている場合)。セキュア・チャネルが管理チャネル構成よりも優先されます。表2-3 セキュアURLを使用するネットワーク・チャネルの例
プロトコル listen-address:listen-port public-address:public-port セキュアURL t3s
host:9003
NA t3s://host:9003
t3s
host:9003
public-address:9003
t3s://public-address:9003
ServerMBean.TransactionPublicChannelName
– パブリックURLの決定に使用されるサーバー・ネットワーク・チャネルの名前。オプションの属性です。表2-4 パブリックURLを使用するネットワーク・チャネルの例
プロトコル listen-address:listen-port public-address:public-port パブリックURL t3
host:7001
NA t3://host:7001
t3
host:7001
public-address:7201
t3://public-address:7201
ServerMBean.TransactionPublicSecureChannelName
– パブリック・セキュアURLの導出に使用されるサーバー・ネットワーク・チャネルの名前。参照されるネットワーク・アクセス・ポイント構成には、t3s
プロトコルが必要です。オプションの属性です。表2-5 パブリック・セキュアURLを使用するネットワーク・チャネルの例
プロトコル listen-address:listen-port public-address:public-port パブリック・セキュアURL t3s
host:9303
NA t3s://host:9303
t3s
host:9303
public-address:9333
t3s://public-address:9333
ノート:
ネットワーク・チャネル構成には、パブリック・セキュア・アドレスとパブリック非セキュア・アドレスを1つのみ含めることができます。複数のパブリック・アドレスはサポートされていません。サーバーURLを構成するための条件
listen-address
かpublic-address
のどちらが設定されているかに応じて、プライマリ、パブリック、セキュアおよびパブリック・セキュアのURLが構成されます。プライマリとパブリック、またはセキュアとパブリック・セキュアに対して同じネットワーク・アクセス・ポイント構成を構成した場合、プライマリおよびセキュアURLにはlisten-address:listen-port
が使用され、パブリックおよびパブリック・セキュアURLにはpublic-address:public-port
が使用されます。
次の表に、ネットワーク・アクセス・ポイント属性からURLが構成される方法の例を示します:
表2-6 プライマリおよびパブリックURLを構成するための条件
プロトコル | listen-address:listen-port | public-address:public-port | プライマリURL | パブリックURL |
---|---|---|---|---|
t3 |
host:7001 |
public-address:7201 |
t3://host:7001 |
t3://public-address:7201 |
表2-7 セキュアおよびパブリック・セキュアURLを構成するための条件
プロトコル | listen-address:listen-port | public-address:public-port | セキュアURL | パブリック・セキュアURL |
---|---|---|---|---|
t3s |
host:9303 |
public-address:9333 |
t3s://host:9303 |
t3s://public-address:9333 |
リモート・ドメインに対するパブリック・アドレスの使用
パブリックURLを使用してリモート・ドメインと通信するには、ドメイン名で定義された新しい属性JTAMBean.UsePublicAddressesForRemoteDomains
を使用します。
この属性でターゲット・ドメイン名が指定されていない場合は、プライマリまたはセキュアURLが使用されます。
ドメインに対する非セキュア・アドレスの使用
JTA通信に非セキュアURLを使用するドメインを指定するには、ドメイン名で定義された新しい属性JTAMBean.UseNonSecureAddressesForDomains
を使用します。
ノート:
パブリック・アドレスは、ドメイン間通信にのみ使用されます。デフォルト・チャネルを使用したサーバーとの相互運用
次のようなネットワーク・チャネルを使用できるように、混合構成がサポートされています:
- JTA通信用のネットワーク・チャネルを使用するようにドメイン内のサーバーを構成する。
- リスニング・アドレスとポートに基づいたサーバー・デフォルト・チャネル、またはリスニング・アドレスとSSLポートを使用する。
- サーバーがデフォルト・チャネルを使用するように構成されたリモート・サーバーに接続する必要がある場合は、プライマリURLを使用する。
例2-1に示されたサーバー構成例で、ServerMBean.TransactionPublicChannelName
がchannelt3
に設定されている場合、生成されるプライマリURLはt3://myhost:7001
になり、パブリックURLはt3://publicaddress:7101
になります。
トランザクションのリカバリのためのトランザクション・ログ・ファイルの使用
各サーバーには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション・ログが備わっています。WebLogic Serverでは、システムのクラッシュやネットワーク障害からのリカバリ時にトランザクション・ログ(TLog)が使用されます。
トランザクション・ログは直接は表示できません。それらのレコードはバイナリ形式であり、サーバーのデフォルト永続ストアまたはJDBC TLogストアに格納されます。
デフォルト永続ストアの使い方
クラスタ内のサーバーに対するトランザクション・リカバリ・サービスの移行機能を利用するには、トランザクション・ログをサーバーとそのバックアップ・サーバーが使用できる場所(デュアル・ポートSCSIディスクまたはSAN (Storage Area Network)を推奨)に格納する必要があります。「デフォルト永続ストアへのパスの設定」を参照してください。
デフォルトのストアがトランザクション・ログ・レコードの保存先とするファイル・システムで領域が不足したり、アクセス不能になったりすると、commit()
によりSystemException
がスローされ、トランザクション・マネージャによってシステム・エラー・ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。
デフォルト永続ストアへのパスの設定
管理サーバーを含む、各サーバー・インスタンスには、デフォルトの永続ストアがあります。これは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができる、ファイル・ベースのストアです。トランザクション・マネージャは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。多くの場合、デフォルトの永続ストアは、構成を必要としません。ただし、トランザクション・リカバリ・サービスの移行を有効化するには、オリジナルのサーバーで障害が発生した場合に、クラスタ内の別のサーバーで使用できる、永続ストレージ・ソリューションに、データ・ファイルを格納するよう、デフォルトの永続ストアを構成する必要があります。
手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
デフォルト永続ストアの同期書込みポリシーの設定
WebLogic Serverは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。デフォルト・ストアの書込みポリシーを選択し、WebLogic Serverがレコードをディスクに書き込む方法を変更します。詳細は、同期書込みポリシーの構成ガイドラインに関する項を参照してください。
手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
JDBC TLOGストアの使用
トランザクション・ログがデータベース内に永続的に保持されるようJDBC TLogストアを構成できます。これにより、基礎となるデータベースのレプリケーションやHA特性の活用、障害回復の簡潔化、およびトランザクション・リカバリ・サービスの移行の改善が可能になります。「永続ストアの管理」を参照してください。
ラスト・ロギング・リソース
LLRは、1つの非XAリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。「ロギング・ラスト・リソース・トランザクションの最適化」を参照してください
トランザクションTLog書込みなしのXAトランザクション
「トランザクションのリカバリのためのトランザクション・ログ・ファイルの使用」で説明されているように、TLogは、インダウト・トランザクションを解決するために使用されます。ただし、これらのファイルの作成と維持に関連するパフォーマンス・コストは、非常に高くなる可能性があります。たとえば、読取りと書込み、リソース・マネージャ間のネットワーク呼出し、およびHA記憶域などのコストがあります。
ノート:
XAトランザクション内のサーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。これらのチェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。次の項では、XAトランザクションの範囲が単一のトランザクション・マネージャ(TM)である場合、TLogを除去することによりXAトランザクションのパフォーマンスが向上させる方法についての情報を提供します。
決定子リソースとは
決定子は、JDBC XAリソースおよびJMS XAリソースで、TLogが存在しない場合に、トランザクション・リカバリにおいてそのリソースのインダウト・トランザクション・レコードが使用されます。
決定子リソースを使用する場合のベスト・プラクティス
次の項では、グローバル・トランザクションで決定子リソースを使用するためのベスト・プラクティスを紹介します。
-
決定子リソースのターゲットは、グローバル・トランザクションを実行するサーバーである必要があります。クラスタ環境では、サービスまたはサーバーの移行時に高可用性を確保するため、決定子リソースのターゲットはクラスタである必要があります。
-
トランザクション・リカバリ・サービスの移行をサポートするには:
-
JDBC XAリソースの場合は、決定子DataSourceのターゲットをクラスタにします。
-
JMS XAリソースの場合は、JMSサービスのターゲットを、カスタム永続ストアによって使用されるのと同じ移行可能なターゲットにします。詳細は、『Oracle WebLogic Serverクラスタの管理』のJMSサービスで使用できるカスタム・ストアに関する項を参照してください。
-
-
最小限の数の決定子リソースを構成します。これにより、リカバリのために使用できる必要があるリソースの数が少なくなります。
TLogを使用しないXAトランザクションの構成
次の各項では、ご使用の環境において決定子を構成、更新および削除する方法を説明します。
ノート:
始める前に、「TLogを使用せずにトランザクションを構成する場合の制限と考慮事項」を参照してください。
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)はサポートされていません。
読取り専用1フェーズ・コミットの最適化
XAResource.prepare
ネットワーク・コールの消去やトランザクション・ログ書込みなどの様々な利点がもたらされます。
ノート:
読取り専用1フェーズ・コミットの最適化には、Oracle Database 11.1.0.7.3PSU以降が必要です。
2フェーズ・コミット・トランザクションを必要としないアプリケーションの場合、WebLogicの「2フェーズ・コミット」プロトコルを無効にすることで、パフォーマンスをさらに最適化できます。このプロトコルは、2つ以上のリソース・マネージャ全体のトランザクションを調整します。2フェーズ・コミットを無効にするには、次の手順を実行します。
-
永続的なインダウト・ロギングおよびロック、ならびにデータベースのブックキーピング・オーバーヘッドを削除します。
-
WebLogicのすべてのチェックポイント・ロギングを削除します。
-
特定のサーバー・インスタンスが2フェーズ・コミットを必要としないという前提を、施行またはテスト(あるいはその両方を実行)します。
-
WebLogic移行(サーバーまたはサービス全体)リカバリの必要性を排除します。これによって、その移行に関わる追加のアセット/キャパシティ、管理などの必要性が排除されます。
読取り専用1フェーズ・コミットの最適化と2フェーズ・コミット無効化の設定
読取り専用1フェーズ・コミットの最適化を有効にし、2フェーズ・コミットを無効化するには、次のJTAドメイン構成属性を設定します。
-
XA呼出しの並列実行 -
false
に設定すると、読取り専用1フェーズ・コミットの最適化が有効になります。 -
2フェーズ・コミットの有効化 - (オプション)
false
に設定すると、2フェーズ・コミットが無効になります。これによって、チェックポイント・レコードを含むすべてのトランザクション・ロギングが無効になります。2フェーズ・コミットの使用を試行すると、RollbackExceptionがスローされます。重要: 「2フェーズ・コミットの有効化」設定(デフォルトでは
true
に設定されている)は、読取り専用最適化を提供するリソース・マネージャ(Oracleデータベースなど)のみをアプリケーションが使用すること、あるいは単一のリソース・マネージャへの単一の接続のみをアプリケーションが使用することが周知されている場合を除き、false
には設定してはなりません。
ノート:
XAリソースがXA_OK
投票を準備から返し(たとえば、対象がOracleデータベースではない場合)、その後ロールバックが発生する前にWebLogicインスタンスがクラッシュする場合は、インダウト・レコードが存在し、ロックがリソース・マネージャ(データベース)で保持されるため、手動で解決する必要があります。
すべてのJTAドメイン構成オプションの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTAドメインの構成に関する項を参照してください。
読取り専用1フェーズ・トランザクション統計の監視
監視目的のため、JTAの「監視」ページには5つのトランザクション処理統計があります。これらの統計はともに「コミット済みトランザクション総数」統計を分類し、あらゆる読取り専用1フェーズ・トランザクション統計を追跡しやすくします。
-
リソースのないコミット済みトランザクションの合計数 - サーバーの起動以降コミットされた、リソースが確保されていないトランザクションの合計数。
-
1リソース1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降1フェーズ・コミットされた、1リソースのみが確保されたトランザクションの合計数。
-
読取り専用1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降、読取り専用最適化のために1フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
-
2フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降2フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
-
LLRコミット済みトランザクション合計数 - サーバーの起動以降コミットされたLLRトランザクションの合計数。
ノート: JTAトランザクションに列記された唯一のリソースがLLRデータ・ソースの場合、そのトランザクションは「LLRコミット済みトランザクション合計数」カテゴリではなく、「1リソース1フェーズ・コミット済みトランザクション合計数」カテゴリの下に含まれます。
JTA監視統計の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJTA統計の監視に関する項を参照してください。