| Oracle® Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド 11g リリース 1 (10.3.1) B55540-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド 11g リリース 1 (10.3.1) B55540-01 |
|
戻る |
次へ |
以下の節では、トランザクション関連のコンフィグレーション タスクについて説明します。
Administration Console は、WebLogic JTA などの WebLogic Server の機能をコンフィグレーションするために使用するインタフェースを備えています。コンフィグレーション プロセスでは、属性の値を指定する必要があります。それらの属性によって、以下のようなトランザクション環境が定義されます。
トランザクションのタイムアウトと制限
トランザクション マネージャの動作
また、EJB、JDBC データ ソース、JMS など、トランザクションに参加可能な Java EE コンポーネントの管理についてもよく理解しておく必要があります。
|
注意 : トランザクション関連のコンフィグレーションには、WebLogic Scripting Tool (WLST) (『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』を参照) または JMX (『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』を参照) を使用することもできます。 |
WebLogic JTA および任意のトランザクション参加コンポーネントをコンフィグレーションすると、システムは JTA API および WebLogic JTA 拡張機能を使用してトランザクションを管理できます。以下の点に注意してください。
JTA (トランザクション) のコンフィグレーション設定は、ドメイン レベルで適用できる。つまり、コンフィグレーション属性の設定はドメイン内のすべてのサーバに適用されることになります。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JTA のコンフィグレーション」を参照してください。
JTA のモニタ タスクは、サーバ レベルで実行される。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JTA のモニタ」を参照してください。
参加リソース (JDBC データ ソースなど) のコンフィグレーション設定は、コンフィグレーションされるオブジェクトごとに行われる。設定は、特定のオブジェクトのすべてのインスタンスに対して適用されます。『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「トランザクション オプション」および Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「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 データ ソースの [リソース ヘルス モニタ] 属性は、Administration Console の [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 ファイルで直接設定します。Administration Console では設定できません。次の例は、これらの属性に関する部分をコンフィグレーション ファイルから抜粋したものです。
... <JTA MaxUniqueNameStatistics="5" TimeoutSeconds="300" RecoveryThresholdMillis="150000" MaxResourceUnavailableMillis="900000" MaxResourceRequestOnServer="60" MaxXACallMillis="180000" />
トランザクション マネージャで分散トランザクションを管理する場合、トランザクションを準備し、その後コミットまたはロールバックするために、トランザクション マネージャはすべての参加リソースと通信できる必要があります。これは、WebLogic ドメインが、分散トランザクションにおいて、トランザクション マネージャまたはトランザクション参加コンポーネント (リソース) として機能する場合に当てはまります。以下の節では、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする方法を説明します。
以下の節では、ドメイン間トランザクション用にドメインをコンフィグレーションする方法について説明します。
ドメイン間トランザクションには以下の制限事項があります。
ドメイン名およびすべての参加リソースの名前はユニークでなければならない。したがって、JDBC データ ソース、サーバ、またはドメインを、別のドメイン内や同じドメイン内のオブジェクトと同じ名前にすることはできません。
次の 2 つの属性が両方とも以下のように設定されているデータ ソースは、グローバル トランザクションには 1 つしか参加させることができない。この制約は、データ ソースがどのドメインにコンフィグレーションされているかに関係なく適用されます。
[ロギング ラスト リソース] または [2 フェーズ コミットのエミュレート] を選択している。
データ ソースで、非 XA ドライバを使用してデータベース接続を作成している。
|
注意 : グローバル トランザクションでは、非 XA ドライバ (2 フェーズ コミットのエミュレート) ではなく、XA ドライバを使用することをお勧めします。グローバル トランザクションで非 XA ドライバを使用することにはリスクが伴います。『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「非 XA ドライバを使用して 2 フェーズ コミットをエミュレートする際の制限およびリスク」を参照してください。 |
グローバル トランザクションに参加するすべてのドメインについて、クロス ドメイン セキュリティまたはセキュリティの運用モードを使用し、互換性のある通信チャネルを適切にコンフィグレーションする必要があります。
プロセスで使用されるすべてのドメインについて、クロス ドメイン セキュリティをコンフィグレーションするか、セキュリティの相互運用モードを設定します。どちらの設定もドメイン レベルで設定されるため、ドメインがクロス ドメイン セキュリティとセキュリティの相互運用モードの両方が設定された混在モードになる可能性があります。
以下の節では、グローバル トランザクションの通信チャネルのコンフィグレーションについて説明します。
ドメイン間トランザクション用にどのタイプの通信チャネルをコンフィグレーションする必要があるかについては、次の表を参考に判断してください。
表 3-2 ドメイン間トランザクション用の通信チャネルのコンフィグレーション
| ドメイン | 10.x および 9.2 MP2 以上 | 9.0、9.1、および 9.2 MP1 以下 | 8.1 SP5 以上 | 8.1 SP4 以下 | 7.0 以上 |
|---|---|---|---|---|---|
|
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 以上のドメインを [互換性] に設定する |
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 のドメインを [互換性] に設定する |
9.x のドメインを [互換性] に設定する |
|
8.1 SP5 以上 |
10.x または 9.2 MP2 以上のドメインをクロス ドメイン セキュリティ用にコンフィグレーションし、8.1 ドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、両方のドメインを [パフォーマンス] に設定する |
両方のドメインを [パフォーマンス] に設定する |
両方のドメインを [パフォーマンス] に設定する |
8.1 SP5 以上のドメインを [互換性] に設定する |
8.1 SP5 以上のドメインを [互換性] に設定する |
|
8.1 SP4 以下 |
10.x または 9.2 MP2 以上のドメインをクロス ドメイン セキュリティ用にコンフィグレーションし、8.1 ドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、10.x または 9.2 MP2 以上のドメインを [互換性] に設定する |
9.x のドメインを [互換性] に設定する |
8.1 SP5 以上のドメインを [互換性] に設定する |
なし |
なし |
|
7.0 以上 |
10.x または 9.2 MP2 以上のドメインをクロス ドメイン セキュリティ用にコンフィグレーションし、8.1 ドメインを例外リストに追加する または セキュリティの相互運用モードを使用し、10.x または 9.2 MP2 以上のドメインを [互換性] に設定する |
9.x のドメインを [互換性] に設定する |
8.1 SP5 以上のドメインを [互換性] に設定する |
なし |
なし |
|
注意 : [ |
ドメイン間トランザクションを実行する際、JMX 1.0 と JMX 1.2 の間に互換性がないことに伴って、ある問題が発生する場合があることが知られています。この非互換性に伴う問題を解決するには、JVM フラグ -Djmx.serial.form=1.0 を使用します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アップグレード ガイド』の「JMX 1.2 実装」を参照してください。
クロス ドメイン セキュリティでは、資格マッパーを使用することで、グローバル トランザクション内のサーバ間に、互換性のある通信チャネルをコンフィグレーションすることを可能にしています。トランザクションに参加するすべてのドメイン ペアについて、資格マッパーを 1 つずつコンフィグレーションします。CrossDomainConnector セキュリティ ロールに属する資格は、ドメイン ペアごとに異なっていても構いません。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「クロスドメイン ユーザのコンフィグレーション」を参照してください。
『Oracle Fusion Middleware 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-3 です。表のセルに「必要」と記されているのは、それに対応するドメインの組み合わせに対してクロス ドメイン セキュリティをコンフィグレーションする必要があることを表したものです。
表 3-3 参加ドメインが 3 つの場合のクロス ドメイン セキュリティの設定
| -- | DomainA | DomainB | DomainC | DomainD |
|---|---|---|---|---|
|
DomainA |
不要 |
必要 |
必要 |
不要 |
|
DomainB |
必要 |
不要 |
必要 |
不要 |
|
DomainC |
必要 |
必要 |
不要 |
不要 |
|
DomainD |
不要 |
不要 |
不要 |
不要 |
その上でクロスドメイン セキュリティのコンフィグレーションに DomainD を追加し、さらに DomainE も追加する場合、クロスドメインの資格マップは表 3-4 のようになります。表のセルに「必要」と記されているのは、それに対応するドメインの組み合わせに対してクロス ドメイン セキュリティをコンフィグレーションする必要があることを表したものです。
クロス ドメイン セキュリティがコンフィグレーションされていないドメインのサーバが、クロス ドメイン セキュリティがコンフィグレーションされているドメインのサーバとのトランザクションに参加する場合、クロス ドメイン セキュリティがコンフィグレーションされているドメインの除外リストにその参加ドメインを追加する必要があります。
クロス ドメイン セキュリティがコンフィグレーションされているドメインすべての除外リストにドメインを追加する必要はありません。ただし、除外リストへ追加する必要があるケースでは、ドメインとのトランザクションへの参加を明示的に行う必要があります。
以下のシナリオについて考察します。
トランザクション #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 Fusion Middleware Oracle WebLogic Server のセキュリティ』の「クロスドメイン セキュリティ用の資格マッピングのコンフィグレーション」を参照してください。
介在者の攻撃 (man-in-the-middle attack) からトランザクションを保護するには、一方向 SSL をコンフィグレーションして通信のセキュリティを強化する。
クロス ドメイン セキュリティをサポートしない (またはクロス ドメイン セキュリティが無効になっている) WebLogic ドメインと相互運用するには、それらのドメインを、クロス ドメイン セキュリティが有効になっているすべての参加 WebLogic Server ドメインの [除外するドメイン名] リストに追加する必要がある。[除外するドメイン名] リストおよび CrossDomainSecurityEnabled フラグのコンフィグレーションが、すべての参加ドメインで統一されていない場合、トランザクションのブランチは失敗します。
CrossDomainSecurityEnabled フラグが無効になっているか、ドメインが [除外するドメイン名] リストに含まれている場合は、セキュリティの相互運用モードで参加ドメインとの通信チャネルが確立される。
CrossDomainSecurityEnabled フラグの有効/無効の設定を切り替えると、しばらくの間トランザクションや他のリモート呼び出しが失敗することがある。トランザクションにおいてコミット リクエストが失敗した場合は、コンフィグレーションの変更が完了した後にコミットが再試行されます。トランザクションの RMI 呼び出しが失敗した場合は、トランザクションがタイムアウトしてロールバックされます。ロールバックは、AbandonTimeoutSeconds が経過するまで再試行されます。
[セキュリティの相互運用モード] を使用すると、グローバル トランザクション内のサーバ間に、互換性のある通信チャネルをコンフィグレーションできます。次の手順に従って、セキュリティの相互運用モードをコンフィグレーションします。
ドメインの信頼関係を確立します。
表 3-2 の値を使用して、セキュリティの相互運用モードをコンフィグレーションします。
|
注意 : [ |
すべての参加ドメインのセキュリティ資格を同じ値に設定します。これにより、ドメインの信頼関係が確立します。
8.x ドメインについては、『WebLogic Security の管理』の「WebLogic Server ドメイン間の信頼関係の有効化」(http://otndnld.oracle.co.jp/document/products/wls/docs81/secmanage/domain.html#domain_interop) を参照してください。
9.x ドメインについては、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ドメイン間のクロス ドメイン セキュリティの有効化」(http://otndnld.oracle.co.jp/document/products/wls/docs92/ConsoleHelp/taskhelp/security/EnableTrustBetweenDomains.html) を参照してください。
10.x ドメインについては、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ドメイン間のクロス ドメイン セキュリティの有効化」(http://otndnld.oracle.co.jp/document/products/wls/docs100/ConsoleHelp/taskhelp/security/EnableTrustBetweenDomains.html) を参照してください。
参加しているすべてのサーバの [セキュリティの相互運用モード] パラメータを同じ値に設定する必要があります。
有効な値は以下のとおりです。
[デフォルト] - トランザクション コーディネータでは、カーネル ID を使用し、管理チャネル (有効化されている場合) を介して呼び出しを行います。管理チャネルが有効化されていない場合は anonymous を使用します。管理チャネルが有効化されていないと、介在者による攻撃のおそれがあります。
[パフォーマンス] - トランザクション コーディネータでは、常に anonymous を使用して呼び出しを行います。この設定では、悪意のあるサード パーティが介在者の攻撃を通じてトランザクションの結果に影響を与える可能性があるため、セキュリティ上、リスクを伴います。
[互換性] - トランザクション コーディネータでは、カーネル ID で非セキュアなチャネルを使用して呼び出しを行います。この設定では、介在者の攻撃が成功すると、攻撃者は双方のドメインに対する管理制御権を得ることができるため、セキュリティ上のリスクが高くなります。この設定は、強固なネットワーク セキュリティが確立されている場合にのみ使用してください。
参加しているサーバのセキュリティの相互運用モードをコンフィグレーションする場合は、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの以下の各節を参照してください。
WebLogic Server 10.x ドメイン内のサーバについては、「セキュリティの相互運用性モードのコンフィグレーション」(http://otndnld.oracle.co.jp/document/products/wls/docs100/ConsoleHelp/taskhelp/jta/ConfigureInteropMode.html)
WebLogic Server 9.x ドメイン内のサーバについては、「XA トランザクションのセキュリティ モードのコンフィグレーション」(http://otndnld.oracle.co.jp/document/products/wls/docs92/ConsoleHelp/taskhelp/jta/ConfigureInteropMode.html)
WebLogic Server 8.1 ドメイン内のサーバについては、「互換性モードの使用」(http://otndnld.oracle.co.jp/document/products/wls/docs81/ConsoleHelp/jta.html#CR241279)
以下では、管理ユーザを必要とする JNDI ルックアップをトランザクションが使用する際にセキュリティの相互運用モードをコンフィグレーションする方法について説明します。
WebLogic Server ドメインが 9.0、9.1、9.2 および MP 以上、または 10.x および MP 以上の場合は、以下のいずれかを行う。
セキュリティの相互運用モードを [デフォルト] に設定し、管理チャネルをコンフィグレーションし、ドメインの信頼関係を有効にする。
セキュリティの相互運用モードを [互換性] に設定し、ドメインの信頼関係を有効にする。
WebLogic Server ドメインが 7.0sp7 以上か 8.1sp5 以上の場合は、セキュリティの相互運用モードを [互換性] に設定し、ドメインの信頼関係を有効にする。
セキュリティの相互運用モードを [互換性] に設定すると、介在者の攻撃 (man-in-the-middle attack) を受ける可能性があります。
セキュリティの相互運用モードを使用して、同じドメイン内のトランザクションに参加するサーバ間に、互換性のある通信チャネルを正しくコンフィグレーションする必要があります。「セキュリティの相互運用モードのコンフィグレーション」を参照してください。
ドメイン内トランザクション用にどのタイプの通信チャネルをコンフィグレーションする必要があるかについては、以下の情報を参考に判断してください。
WebLogic Server 10.x ドメインのサーバの場合は、参加サーバを [デフォルト] または [パフォーマンス] に設定する。
WebLogic Server 9.x ドメインのサーバの場合は、参加サーバを [デフォルト] または [パフォーマンス] に設定する。
WebLogic Server 8.1 SP5 以降のドメインのサーバの場合は、参加サーバを [パフォーマンス] に設定する。
WebLogic Server 8.1 SP4 以下のドメインのサーバの場合は、セキュリティの相互運用モードを使用することはできない。
各サーバには、そのサーバで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション ログが備わっています。WebLogic Server では、システムのクラッシュやネットワーク障害からの回復時にトランザクション ログを使用します。トランザクション ログを直接見ることはできません。レコードはバイナリ形式で、サーバのデフォルト永続ストアに格納されます。
クラスタ内のサーバに対するトランザクション回復サービスの移行機能を利用するには、トランザクション ログをサーバとそのバックアップ サーバが使用できる場所 (デュアルポート SCSI ディスクまたは SAN (Storage Area Network) を推奨) に格納する必要があります。詳細については、「デフォルト永続ストアへのパスの設定」を参照してください。
デフォルトのストアがトランザクション ログ レコードの保存先とするファイル システムで領域が不足したり、アクセス不能になったりすると、commit() により SystemException が送出され、トランザクション マネージャによってシステム エラー ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。
管理サーバを含む、各サーバ インスタンスには、デフォルトの永続ストアがあります。これは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ メカニズムを使用することで最適に動作するサブシステムから使用することができる、ファイルベースのストアです。トランザクション マネージャは、デフォルト永続ストアを使用して、トランザクション ログ レコードを格納します。多くの場合、デフォルトの永続ストアは、コンフィグレーションを必要としません。ただし、トランザクション回復サービスの移行を有効化するには、オリジナルのサーバで障害が発生した場合に、クラスタ内の別のサーバで使用できる、永続ストレージ ソリューションに、データ ファイルを格納するよう、デフォルトの永続ストアをコンフィグレーションする必要があります。
手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「トランザクション回復サービスの移行のためのデフォルト永続ストアのコンフィグレーション」を参照してください。
WebLogic Server は、デフォルト永続ストアを使用して、トランザクション ログ レコードを格納します。デフォルト ストアの書き込みポリシーを選択することで、WebLogic Server がレコードをディスクに書き込む方式を変更できます。以下のいずれかのオプションを選択できます。
[Cache-Flush] - ストアにエントリが追加されるたびにオペレーティング システムのキャッシュとオンディスク キャッシュをフラッシュします。コミット レコードが安定したストレージに書き込まれるまでトランザクションはコミットされません。
[無効] - 書き込みがメモリにキャッシュされると、ディスクに正常に格納されるまで待機せず、すぐにトランザクションが完了します。このポリシーは最も高速ですが、トランザクションの安全性は低くなります。停電やオペレーティング システムの障害によってエントリが消失したり重複したりするおそれがあります。
|
注意 : 無効化された同期書き込みポリシーでは、トランザクションの安全性が低くなります。アプリケーションでグローバル トランザクションを使用する場合は、このオプションを選択しないでください。 |
[Direct-Write] - オペレーティング システムでの書き込みが常に、直接ディスクに対して行われます。このオプションは、Windows、Solaris、および HP-UX の各プラットフォームで使用できます。
|
注意 : Windows では [Direct-Write] トランザクション ログ ファイル書き込みポリシーが指定されていても、トランザクション データがディスクに直接書き込まれずにオンディスク キャッシュに残される場合があります。この場合、停電などによってオンディスク キャッシュのデータが失われるおそれがあり、トランザクションとしては安全とはいえません。Windows で [Direct-Write] トランザクション ログ ファイル書き込みポリシーを使用している場合にキャッシュ データの消失を回避するには、ディスクの書き込みキャッシュをすべて無効にするか (デフォルトでは有効)、またはシステムのバッテリー バックアップを使用してください。 |
手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「トランザクション回復サービスの移行のためのデフォルト永続ストアのコンフィグレーション」を参照してください。
