| Oracle® Fusion Middleware Oracle WebLogic Server JTAのプログラミング 11g リリース1 (10.3.6) B61631-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JTAのプログラミング 11g リリース1 (10.3.6) B61631-07 |
|
前 |
次 |
この章では、トランザクション関連の基本的な構成タスクについて説明します。これらのタスクには、JTAの使用、セキュアなトランザクション通信の構成、トランザクション・ログ(TLOG)ファイルの使用、読取り専用の1フェーズ・コミット最適化の使用があります。
管理コンソールは、WebLogic JTAなどのWebLogic Serverの機能を構成するために使用するインタフェースを備えています。構成プロセスでは、属性の値を指定する必要があります。それらの属性によって、以下のようなトランザクション環境が定義されます。
トランザクションのタイムアウトと制限
トランザクション・マネージャの動作
また、EJB、JDBCデータ・ソース、JMSなど、トランザクションに参加可能なJava EEコンポーネントの管理についてもよく理解しておく必要があります。
|
注意: トランザクション関連の構成には、WebLogic Scripting Tool (WLST)(『Oracle WebLogic Scripting Tool』を参照)またはJMX(『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照)を使用することもできます。 |
WebLogic JTAおよび任意のトランザクション参加コンポーネントを構成すると、システムはJTA APIおよびWebLogic JTA拡張機能を使用してトランザクションを管理できます。次の点に注意してください。
JTA(トランザクション)の構成設定は、ドメイン・レベルで適用できます。つまり、構成属性の設定はドメイン内のすべてのサーバーに適用されることになります。Oracle WebLogic Server管理コンソール・ヘルプのJTAの構成に関する項を参照してください。
JTAのモニター・タスクは、サーバー・レベルで実行されます。Oracle WebLogic Server管理コンソール・ヘルプのJTAのモニターに関する項を参照してください。
参加リソース(JDBCデータ・ソースなど)の構成設定は、構成されるオブジェクトごとに行われます。設定は、特定のオブジェクトのすべてのインスタンスに対して適用されます。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のJDBCデータ・ソース・トランザクション・オプションに関する項およびOracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソースのグローバル・トランザクション・オプションの構成に関する項を参照してください。
アプリケーションと一緒にパッケージ化されたJDBCデータ・ソース・モジュールなど、必要に応じてアンデプロイしたり再デプロイしたりすることのあるリソースについては、ドメインに対して「リソース登録解除の猶予期間」を設定することで、リソースが登録解除されていたためにトランザクションが破棄される可能性を最小限にできます。猶予期間とは、リソースが登録解除される前に、トランザクション・マネージャがトランザクションの完了を待機する秒数です。
指定された猶予期間の間、unregisterResource呼出しは自身が返るまでブロックを行い、関連するリソースに対して新しいトランザクションは開始されません。リソースに対して未処理のトランザクションの数が0になると、unregisterResource呼出しは即座に返ります。
猶予期間の終わりに、まだリソースに関連する未処理のトランザクションがある場合は、unregisterResourceが返り、リソースが以前登録されていたサーバー上にログ・メッセージが書き込まれます。
デフォルトでは、グローバル・トランザクションに参加しているXAリソースがWebLogic Serverトランザクション・マネージャからのXA呼出しに応答しないと、そのリソースに異常があって使用できないことを示すフラグが付加されます。また、リソースのスレッドを保持するため、このリソースに対する以降のすべての呼出しがブロックされます。障害は、トランザクションに異常がある場合でも、リソースに異常がある場合でも発生する可能性があります。これら2つの原因の間に区別はありません。どちらの場合も、リソースに異常があるものとしてマークされます。
この制約を緩和するため、WebLogic Serverには表3-1に列記したような構成属性が用意されています。
表3-1 XAリソースのヘルス監視構成属性
| 属性 | MBean | 定義 |
|---|---|---|
ResourceHealthMonitoring |
weblogic.managment.configuration.JDBCXAParamsBean |
JDBCXAParamsBean MBeanのResourcehealthMonitoring属性。 JDBCデータ・ソースのリソースのヘルス監視を有効または無効にします。この属性は、データベース接続にXA JDBCドライバを使用するデータ・ソースにのみ適用されます。非XA JDBCドライバを使用している場合は無視されます。
デフォルト: JDBCデータ・ソースの「リソース・ヘルス監視」属性は、管理コンソールの「JDBCデータ・ソース」→「構成」→「接続プール」タブで設定します。 |
MaxXACallMillis |
weblogic.management.configuration.JTAMBean |
XAリソースに対するXA呼出しの最長許容期間をミリ秒で設定します。この設定は、ドメイン全体に適用されます。 デフォルト値: 120000 |
MaxResourceUnavailableMillis |
weblogic.management.configuration.JTAMBean |
XAリソースが異常とマークされる最長期間(ミリ秒)。この期間を過ぎると、トランザクション・マネージャでXAリソースを明示的に再登録しなくても、リソースが再び使用可能と宣言されます。この設定は、ドメイン全体に適用されます。 デフォルト値: 1800000 |
MaxResourceRequestOnServer |
weblogic.management.configuration.JTAMBean |
ドメイン内の各サーバーで許容するリソースへの同時リクエストの最大数。 デフォルト値: 50 最小値: 10 最大値: |
JDBCデータ・ソースの「リソース・ヘルス監視」を除き、これらの属性は、ドメインが非アクティブの時にconfig.xmlファイルで直接設定します。これらの属性は、管理コンソールでは使用できません。次の例は、これらの属性に関する部分を構成ファイルから抜粋したものです。
...
<JTA
MaxUniqueNameStatistics="5"
TimeoutSeconds="300"
RecoveryThresholdMillis="150000"
MaxResourceUnavailableMillis="900000"
MaxResourceRequestOnServer="60"
MaxXACallMillis="180000"
/>
分散トランザクションを管理するトランザクション・マネージャの場合、トランザクション・マネージャは、トランザクションを準備して、コミットまたはロールバックするためにすべての参加サーバーやリソースと通信できるようにしておく必要があります。通信チャネルの構成は、トランザクション・ルートが次のどちらであるかによって異なります。
ドメイン間 - トランザクション通信は、同じドメイン内ではないトランザクションに参加するサーバー間で行われます。
ドメイン内 - トランザクション通信は、同じドメイン内のトランザクションに参加するサーバー間で行われます。
通信チャネルは、悪質なサード・パーティがトランザクションの結果に影響を与える中間者攻撃を使用できず、1つ以上のドメイン間で管理制御を取得できないようにセキュアにしておく必要があります。WebLogic Serverには、通信チャネルをセキュアにする次のオプションが用意されています。
クロス・ドメイン・セキュリティ - 資格証明マッパーを使用して、ドメイン間トランザクションのサーバー間で互換性のある通信チャネルを構成できます。この場合、複雑な構成が必要になりますが、クロス・ドメイン・セキュリティを使用すると、各ドメイン間の信頼を調整できます。
セキュリティの相互運用モード - すべてのドメインのセキュリティの資格証明を同じ値に設定して、トランザクションに参加するすべてのドメイン間での信頼を確立します。これにより、あるWebLogic Serverインスタンスのサブジェクトのプリンシパルが、別のインスタンスのプリンシパルとして受け入れられます。クロス・ドメイン・セキュリティを構成するよりも簡単ですが、「セキュリティの相互運用モード」の一部の設定は、ドメイン信頼に依存するため、クロス・ドメイン・セキュリティよりもセキュリティの程度は低くなります。
次の項では、トランザクション時にサーバー間でセキュアな通信を構成する方法について説明します。
トランザクション環境に通信チャネルを構成する場合、次の要件に注意してください。
ドメイン名およびすべての参加リソースの名前は一意でなければなりません。したがって、JDBCデータ・ソース、サーバー、またはドメインを、別のドメイン内や同じドメイン内のオブジェクトと同じ名前にすることはできません。
プロセスで使用されるすべてのドメインについて、クロス・ドメイン・セキュリティを構成するか、セキュリティの相互運用モードを設定します。どちらの設定もドメイン・レベルで設定されるため、ドメインがクロス・ドメイン・セキュリティとセキュリティの相互運用モードの両方が設定された混在モードになる可能性があります。
WebLogic Server 8.1ドメインと相互運用している場合、JMX 1.0とJMX 1.2の間に互換性がないことに伴って、ドメイン間トランザクションを実行する際に問題が発生する場合があることが知られています。この非互換性に伴う問題を解決するには、JVMフラグ-Djmx.serial.form=1.0を使用します。詳細は、『Oracle WebLogic Serverアップグレード・ガイド』のJMX 1.2実装に関する項を参照してください。
次の2つの属性が両方とも次のように設定されているデータ・ソースは、グローバル・トランザクションには1つしか参加させることができません。この制約は、データ・ソースがどのドメインに構成されているかに関係なく適用されます。
「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」を選択しています。
データ・ソースで、非XAドライバを使用してデータベース接続を作成しています。
グローバル・トランザクションに参加するすべてのドメインについて、クロス・ドメイン・セキュリティまたはセキュリティの相互運用モードを使用し、互換性のある通信チャネルを適切に構成する必要があります。次を参照してください。
次の表を参考に、クロス・ドメイン・セキュリティまたはセキュリティの相互運用モードを使用するタイミングを決定します。
表3-2 チャネル構成の選択
| チャネル構成 | 長所 | 短所 |
|---|---|---|
|
クロス・ドメイン・セキュリティ |
|
|
|
セキュリティの相互運用モード |
|
|
ドメイン間トランザクション用にどのタイプの通信チャネルを構成する必要があるかについては、次の表を参考に判断してください。
表3-3 ドメイン間トランザクション用の通信チャネルの構成
| ドメイン | 10.xおよび9.2 MP2以上 | 9.0、9.1、および9.2 MP1以下 | 8.1 SP5以上 | 8.1 SP4以下 |
|---|---|---|---|---|
|
10.xおよび9.2 MP2以上 |
両方のドメインをクロス・ドメイン・セキュリティ用に構成する または セキュリティの相互運用モードを使用し、両方のドメインを「デフォルト」または「パフォーマンス」に設定する |
10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、9.0、9.1、または9.2 MP1以下のドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、両方のドメインを「デフォルト」または「パフォーマンス」に設定する |
10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、両方のドメインを「パフォーマンス」に設定する |
10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、10.xまたは9.2 MP2以上のドメインを「互換性」に設定する |
|
9.0、9.1、および9.2 MP1以下 |
10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、9.0、9.1、または9.2 MP1以下のドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、両方のドメインを「デフォルト」または「パフォーマンス」に設定する |
両方のドメインを「デフォルト」または「パフォーマンス」に設定する |
両方のドメインを「パフォーマンス」に設定する |
9.xのドメインを「互換性」に設定する |
|
8.1 SP5以上 |
10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、両方のドメインを「パフォーマンス」に設定する |
両方のドメインを「パフォーマンス」に設定する |
両方のドメインを「パフォーマンス」に設定する |
8.1 SP5以上のドメインを「互換性」に設定する |
|
8.1 SP4以下 |
10.xまたは9.2 MP2以上のドメインをクロス・ドメイン・セキュリティ用に構成し、8.1ドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、10.xまたは9.2 MP2以上のドメインを「互換性」に設定する |
9.xのドメインを「互換性」に設定する |
8.1 SP5以上のドメインを「互換性」に設定する |
なし |
|
注意:
|
セキュリティの相互運用モードを使用して、同じドメイン内のトランザクションに参加するサーバー間に、互換性のある通信チャネルを正しく構成する必要があります。「セキュリティの相互運用モードの構成」を参照してください。
WebLogic Server 10.xドメインのサーバーの場合は、参加サーバーをdefault、performance、またはcompatibilityに設定します。
クロス・ドメイン・セキュリティでは、資格証明マッパーを使用することで、グローバル・トランザクション内のサーバー間に、互換性のある通信チャネルを構成することを可能にしています。トランザクションに参加するすべてのドメイン・ペアについて、資格証明マッパーを1つずつ構成します。CrossDomainConnectorセキュリティ・ロールに属する資格証明は、ドメイン・ペアごとに異なっていてもかまいません(詳細は、『Oracle WebLogic Serverの保護』のクロス・ドメイン・ユーザーの構成に関する項を参照してください)。
『Oracle WebLogic Serverの保護』のWebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化に関する項およびクロス・ドメイン・セキュリティの資格証明マッピングの構成に関する項を参照してください。
トランザクションに参加する複数のサーバーでは、相互にクロス・ドメインの資格証明マッピングを設定します。ドメイン信頼とは異なり、クロス・ドメイン・セキュリティの構成は推移的ではありません。つまり、AがBを信頼し、BがCを信頼していても、それによってAがCを信頼しているということにはなりません。
以下のシナリオについて考察します。
DomainAにはServer1があります(コーディネータ)
DomainBにはServer2があります(サブコーディネータ)
DomainCにはServer3とServer4があります(Server3はサブコーディネータ)
DomainDにはServer5があります(トランザクションには参加しません)
このシナリオでクロス・ドメインの資格証明マッピングを設定するには、次の操作を行います。
DomainAにおいてDomainBのクロス・ドメイン・セキュリティを設定します。
DomainBにおいてDomainAのクロス・ドメイン・セキュリティを設定します。
DomainAにおいてDomainCのクロス・ドメイン・セキュリティを設定します。
DomainCにおいてDomainAのクロス・ドメイン・セキュリティを設定します。
DomainBにおいてDomainCのクロス・ドメイン・セキュリティを設定します。
DomainCにおいてDomainBのクロス・ドメイン・セキュリティを設定します。
DomainDはトランザクションに参加しないため、クロス・ドメインの資格証明マッピングを使用する必要はありません。ただし、「トランザクションへの参加に基づいて除外リストにドメインを追加する」にある、より詳細な説明を参照してください。
これらを分かりやすい形で表したのが、表3-4です。表のセルに「必要」と記されているのは、それに対応するドメインの組合せに対してクロス・ドメイン・セキュリティを構成する必要があることを表したものです。
表3-4 参加ドメインが3つの場合のクロス・ドメイン・セキュリティの設定
| -- | DomainA | DomainB | DomainC | DomainD |
|---|---|---|---|---|
|
DomainA |
いいえ |
はい |
はい |
いいえ |
|
DomainB |
はい |
いいえ |
はい |
いいえ |
|
DomainC |
はい |
はい |
いいえ |
いいえ |
|
DomainD |
いいえ |
いいえ |
いいえ |
いいえ |
その上でクロス・ドメイン・セキュリティの構成にDomainDを追加し、さらにDomainEも追加する場合、クロス・ドメインの資格証明マップは表3-5のようになります。表のセルに「必要」と記されているのは、それに対応するドメインの組合せに対してクロス・ドメイン・セキュリティを構成する必要があることを表したものです。
除外リストでは、クロス・ドメイン・セキュリティが構成されているドメインのサーバーと、クロス・ドメイン・セキュリティがサポートされていないか、有効になっていない別のドメインのサーバーがトランザクションに参加するためのメカニズムが提供されます。
クロス・ドメイン・セキュリティが構成されていないドメインのサーバーが、クロス・ドメイン・セキュリティが構成されているドメインのサーバーと一緒にトランザクションに参加する場合、クロス・ドメイン・セキュリティが構成されているドメインの除外リストに該当ドメインを追加します。「クロス・ドメイン・セキュリティを構成する場合の重要な考慮事項」の説明に従い、セキュリティの相互運用モードを使用して、参加ドメインの通信チャネルを確立します。
クロス・ドメイン・セキュリティが構成されているドメインすべての除外リストにドメインを追加する必要はありません。ただし、除外リストへ追加する必要があるケースでは、ドメインとのトランザクションへの参加を明示的に行う必要があります。
以下のシナリオについて考察します。
トランザクション#1:
DomainAにはServer1があります(コーディネータ)
DomainBにはServer2があります(サブコーディネータ)
DomainCにはServer3とServer4があります(Server3はサブコーディネータ)
DomainDにはServer5があります(トランザクションには参加せず、クロス・ドメイン・セキュリティは構成されていません)
トランザクション#2:
DomainBにはServer6があります(コーディネータ)
DomainDにはServer5があります(サブコーディネータで、クロス・ドメイン・セキュリティは構成されていません)
この場合、トランザクション#2のためにDomainDをDomainBの除外リストに追加する必要があります。
DomainAおよびDomainCのサーバーとのトランザクションには参加していないため、これら2つのドメインの除外リストにはDomainDを含める必要はありません。
クロス・ドメイン・セキュリティを構成する際には、以下のガイドラインを考慮に入れてください。
クロス・ドメイン・セキュリティでは、ドメイン信頼は必須ではありません。
トランザクションに参加するすべてのドメイン・ペアについて、資格証明マッパーを正しく構成する必要があります - CrossDomainConnectorセキュリティ・ロールに属する資格証明のセットを設定しなければなりません。資格証明マッピングが正しくないと、参加ドメイン間のトランザクションは失敗します。『Oracle WebLogic Serverの保護』のクロス・ドメイン・セキュリティの資格証明マッピングの構成に関する項を参照してください。
中間者攻撃からトランザクションを保護するには、一方向SSLを構成して通信のセキュリティを強化します。
クロス・ドメイン・セキュリティをサポートしない(またはクロス・ドメイン・セキュリティが無効になっている)WebLogicドメインと相互運用するには、それらのドメインを、クロス・ドメイン・セキュリティが有効になっているすべての参加WebLogic Serverドメインの「除外するドメイン名」リストに追加する必要があります。「除外するドメイン名」およびCrossDomainSecurityEnabledフラグの構成が、すべての参加ドメインで統一されていない場合、トランザクションのブランチは失敗します。
Cross Domain Security Enabledフラグが無効になっているか、ドメインがExcluded Domain Namesリストに含まれている場合は、セキュリティの相互運用モードを使って参加ドメインとの通信チャネルが確立されます。
「クロス・ドメイン・セキュリティの有効化」フラグの有効/無効の設定を切り替えると、しばらくの間トランザクションや他のリモート呼出しが失敗することがあります。トランザクションにおいてコミット・リクエストが失敗した場合は、構成の変更が完了した後にコミットが再試行されます。トランザクションのRMI呼出しが失敗した場合は、トランザクションがタイムアウトしてロールバックされます。ロールバックは、AbandonTimeoutSecondsが経過するまで再試行されます。
「セキュリティの相互運用モード」を使用すると、グローバル・トランザクション内のサーバー間に、互換性のある通信チャネルを構成できます。次の手順に従って、セキュリティの相互運用モードを構成します。
表3-3の値を使用して、セキュリティの相互運用モードの構成を行います。
|
注意:
|
すべての参加ドメインのセキュリティ資格証明を同じ値に設定することにより、ドメイン信頼を確立します。
8.xドメインについては、『WebLogicセキュリティの管理』のWebLogicドメイン間の信頼の有効化に関する項(http://docs.oracle.com/cd/E13222_01/wls/docs81/secmanage/domain.html#domain_interop)を参照してください。
9.xドメインについては、Oracle WebLogic Server管理コンソール・ヘルプのドメイン間での信頼の有効化に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs92/ConsoleHelp/taskhelp/security/EnableTrustBetweenDomains.html)を参照してください。
10.xドメインについては、Oracle WebLogic Server管理コンソール・ヘルプのドメイン間での信頼の有効化に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs100/ConsoleHelp/taskhelp/security/EnableTrustBetweenDomains.html)を参照してください。
参加しているすべてのサーバーの「セキュリティの相互運用モード」パラメータを同じ値に設定する必要があります。
有効な値は以下のとおりです。
default - トランザクション・コーディネータでは、カーネルIDを使用し、管理チャネル(有効化されている場合)を介して呼出しを行います。管理チャネルが構成されていない場合、セキュリティの相互運用モードの動作は、performanceを使用する場合と同じになります。
performance - トランザクション・コーディネータでは、常にanonymousを使用して呼出しを行います。この設定では、悪意のあるサード・パーティが中間者攻撃を通じてトランザクションの結果に影響を与える可能性があるため、セキュリティ上、リスクを伴います。
compatibility - トランザクション・コーディネータでは、カーネルIDで非セキュアなチャネルを使用して呼出しを行います。このモードは、セキュリティの相互運用モードをサポートしていないWebLogic Serverサーバーと対話する場合に必要です。中間者攻撃が成功すると、攻撃者は双方のドメインに対する管理制御権を得ることができるため、セキュリティ上のリスクが高くなります。この設定は、強固なネットワーク・セキュリティが確立されている場合にのみ使用してください。
参加しているサーバーのセキュリティの相互運用モードを構成する場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。
WebLogic Server 10.xドメイン内のサーバーについては、セキュリティの相互運用性モードの構成に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs100/ConsoleHelp/taskhelp/jta/ConfigureInteropMode.html)を参照してください。
WebLogic Server 9.xドメイン内のサーバーについては、XAトランザクションのセキュリティ・モードの構成に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs92/ConsoleHelp/taskhelp/jta/ConfigureInteropMode.html)を参照してください。
WebLogic Server 8.1ドメイン内のサーバーについては、セキュリティの相互運用性モードの使用に関する項(http://docs.oracle.com/docs/cd/E13222_01/wls/docs81/ConsoleHelp/jta.html#CR241279)を参照してください。
以下では、管理ユーザーを必要とするJNDIルックアップをトランザクションが使用する際にセキュリティの相互運用モードを構成する方法について説明します。
WebLogic Serverドメインが9.0、9.1、9.2およびMP以上、または10.xおよびMP以上の場合は、以下のいずれかを行います。
セキュリティの相互運用モードを「デフォルト」に設定し、管理チャネルを構成し、ドメイン信頼を有効にします。
セキュリティの相互運用モードを「互換性」に設定し、ドメイン信頼を有効にします。
WebLogic Serverドメインが8.1SP5以上の場合は、SecurityInteropMode=compatibilityを設定し、ドメイン信頼を有効にします。
セキュリティの相互運用モードを「互換性」に設定すると、中間者攻撃を受ける可能性があります。
各サーバーには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション・ログが備わっています。WebLogic Serverでは、システムのクラッシュやネットワーク障害からの回復時にトランザクション・ログを使用します。トランザクション・ログを直接見ることはできません。レコードはバイナリ形式で、サーバーのデフォルト永続ストアまたはJDBC TLOGストアに格納されます。
クラスタ内のサーバーに対するトランザクション・リカバリ・サービスの移行機能を利用するには、トランザクション・ログをサーバーとそのバックアップ・サーバーが使用できる場所(デュアル・ポートSCSIディスクまたはSAN (Storage Area Network)を推奨)に格納する必要があります。詳細については、「デフォルト永続ストアへのパスの設定」を参照してください。
デフォルトのストアがトランザクション・ログ・レコードの保存先とするファイル・システムで領域が不足したり、アクセス不能になったりすると、commit()によりSystemExceptionがスローされ、トランザクション・マネージャによってシステム・エラー・ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。
管理サーバーを含む、各サーバー・インスタンスには、デフォルトの永続ストアがあります。これは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができる、ファイル・ベースのストアです。トランザクション・マネージャは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。多くの場合、デフォルトの永続ストアは、構成を必要としません。ただし、トランザクション・リカバリ・サービスの移行を有効化するには、オリジナルのサーバーで障害が発生した場合に、クラスタ内の別のサーバーで使用できる、永続ストレージ・ソリューションに、データ・ファイルを格納するよう、デフォルトの永続ストアを構成する必要があります。
手順については、Oracle WebLogic Server管理コンソール・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
WebLogic Serverは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。デフォルト・ストアの書込みポリシーを選択し、WebLogic Serverがレコードをディスクに書き込む方法を変更します。詳細は、『Oracle WebLogic Serverサーバー環境の構成』の同期書込みポリシーの構成ガイドラインに関する項を参照してください。
手順については、Oracle WebLogic Server管理コンソール・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
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リソースが |
すべてのJTAドメイン構成オプションの詳細は、WebLogic管理コンソール・オンライン・ヘルプのJTAドメインの構成に関する項を参照してください。
監視目的のため、JTAの「監視」ページには5つのトランザクション処理統計があります。これらの統計はともに「コミット済みトランザクション総数」統計を分類し、あらゆる読取り専用1フェーズ・トランザクション統計を追跡しやすくします。
リソースのないコミット済みトランザクションの合計数 - サーバーの起動以降コミットされた、リソースが確保されていないトランザクションの合計数。
1リソース1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降1フェーズ・コミットされた、1リソースのみが確保されたトランザクションの合計数。
読取り専用1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降、読取り専用最適化のために1フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
2フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降2フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
LLRコミット済みトランザクション合計数 - サーバーの起動以降コミットされたLLRトランザクションの合計数。
注意: JTAトランザクションに列記された唯一のリソースがLLRデータ・ソースの場合、そのトランザクションは「LLRコミット済みトランザクション合計数」カテゴリではなく、「1リソース1フェーズ・コミット済みトランザクション合計数」カテゴリの下に含まれます。
JTA監視統計の詳細は、WebLogic管理コンソール・オンライン・ヘルプのJTA統計の監視に関する項を参照してください。
