|
|
以下の節では、トランザクション関連のコンフィグレーション タスクについて説明します。
Administration Console は、WebLogic JTA などの WebLogic Server の機能をコンフィグレーションするために使用するインタフェースを備えています。コンフィグレーション プロセスでは、属性の値を指定する必要があります。それらの属性によって、以下のようなトランザクション環境が定義されます。
また、EJB、JDBC データ ソース、JMS など、トランザクションに参加可能な Java EE コンポーネントの管理についてもよく理解しておく必要があります。
| 注意 : | WebLogic Scripting Tool (WLST。『WebLogic Scripting Tool ガイド』を参照) または JMX (『JMX によるカスタム管理ユーティリティの開発』を参照) で、トランザクション関連の設定をコンフィグレーションすることもできます。 |
WebLogic JTA および任意のトランザクション参加コンポーネントをコンフィグレーションすると、システムは JTA API および WebLogic JTA 拡張機能を使用してトランザクションを管理できます。以下の点に注意してください。
アプリケーションと一緒にパッケージ化された JDBC データ ソース モジュールなど、必要に応じてアンデプロイしたり再デプロイしたりすることのあるリソースについては、ドメインに対して [リソース登録解除の猶予期間] を設定することで、リソースが登録解除されていたためにトランザクションが破棄される可能性を最小限にできます。猶予期間とは、リソースが登録解除される前に、トランザクション マネージャがトランザクションの完了を待機する秒数です。
指定された猶予期間の間、unregisterResource 呼び出しは自身が返るまでブロックを行い、関連するリソースに対して新しいトランザクションは開始されません。リソースに対して未処理のトランザクションの数が 0 になると、unregisterResource 呼び出しは即座に返ります。
猶予期間の終わりに、まだリソースに関連する未処理のトランザクションがある場合は、unregisterResource が返り、リソースが以前登録されていたサーバ上にログ メッセージが書き込まれます。
デフォルトでは、グローバル トランザクションに参加している XA リソースが WebLogic Server トランザクション マネージャからの XA 呼び出しに応答しないと、そのリソースに異常があって使用できないことを示すフラグが付加されます。また、リソースのスレッドを保持するため、このリソースに対する以降のすべての呼び出しがブロックされます。障害は、トランザクションに異常がある場合でも、リソースに異常がある場合でも発生する可能性があります。これら 2 つの原因の間に区別はありません。どちらの場合も、リソースに異常があるものとしてマークされます。
この制約を緩和するため、WebLogic Server には表 3-1 に示すコンフィグレーション属性が用意されています。
true に設定すると、リソースのヘルス モニタが有効になる。MaxXACallMillis 属性に指定した期間内に XA リソースが XA 呼び出しへの応答に失敗すると、データ ソースに異常があるものとしてマークされ、リソースに対する以降の呼び出しがすべてブロックされる。
|
||
JDBC データ ソースの [リソース ヘルス モニタ] を除き、これらの属性は、ドメインが非アクティブの時に config.xml ファイルで直接設定します。Administration Console では設定できません。次の例は、これらの属性に関する部分をコンフィグレーション ファイルから抜粋したものです。
...
<JTA
MaxUniqueNameStatistics="5"
TimeoutSeconds="300"
RecoveryThresholdMillis="150000"/>
MaxResourceUnavailableMillis="900000"
MaxResourceRequestOnServer="60"
MaxXACallMillis="180000"
トランザクション マネージャで分散トランザクションを管理する場合、トランザクションを準備し、その後コミットまたはロールバックするために、トランザクション マネージャはすべての参加リソースと通信できる必要があります。これは、WebLogic ドメインが、分散トランザクションにおいて、トランザクション マネージャまたはトランザクション参加コンポーネント (リソース) として機能する場合に当てはまります。以下の節では、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする方法を説明します。
以下の節では、ドメイン間トランザクション用にドメインをコンフィグレーションする方法について説明します。
| 注意 : | グローバル トランザクションでは、非 XA ドライバ (2 フェーズ コミットのエミュレート) ではなく、XA ドライバを使用することをお勧めします。グローバル トランザクションで非 XA ドライバを使用することにはリスクが伴います。『WebLogic JDBC のコンフィグレーションと管理』の「非 XA ドライバを使用して 2 フェーズ コミットをエミュレートする際の制限およびリスク」を参照してください。 |
グローバル トランザクションに参加するすべてのドメインについて、クロス ドメイン セキュリティまたはセキュリティの運用モードを使用し、互換性のある通信チャネルを適切にコンフィグレーションする必要があります。
プロセスで使用されるすべてのドメインについて、クロス ドメイン セキュリティをコンフィグレーションするか、セキュリティの相互運用モードを設定します。どちらの設定もドメイン レベルで設定されるため、ドメインがクロス ドメイン セキュリティとセキュリティの相互運用モードの両方が設定された混在モードになる可能性があります。
以下の節では、グローバル トランザクションの通信チャネルのコンフィグレーションについて説明します。
ドメイン間トランザクション用にどのタイプの通信チャネルをコンフィグレーションする必要があるかについては、次の表を参考に判断してください。
| 注意 : | [セキュリティの相互運用モード] が [パフォーマンス] に設定されている場合、ドメイン間におけるドメインの信頼関係の設定は必須ではありません。 |
クロス ドメイン セキュリティでは、資格マッパーを使用することで、グローバル トランザクション内のサーバ間に、互換性のある通信チャネルをコンフィグレーションすることを可能にしています。トランザクションに参加するすべてのドメイン ペアについて、資格マッパーを 1 つずつコンフィグレーションします。CrossDomainConnector セキュリティ ロールに属す資格群は、ドメイン ペアごとに異なっていても構いません。『WebLogic Server のセキュリティ』の「クロスドメイン セキュリティの有効化」および「クロスドメイン セキュリティ用の資格マッピングのコンフィグレーション」を参照してください。
クロス ドメイン セキュリティをコンフィグレーションする際は、以下の点を考慮に入れてください。
CrossDomainConnector セキュリティ ロールに属す資格群を設定しなければなりません。資格マッピングが正しくないと、参加ドメイン間のトランザクションが失敗します。『WebLogic Server のセキュリティ』の「クロスドメイン セキュリティ用の資格マッピングのコンフィグレーション」を参照してください。CrossDomainSecurityEnabled フラグのコンフィグレーションが、すべての参加ドメインで統一されていない場合は、トランザクションのブランチが失敗します。CrossDomainSecurityEnabled フラグが無効になっているか、ドメインが [除外するドメイン名] リストに含まれている場合は、セキュリティの相互運用モードで参加ドメインとの通信チャネルが確立される。CrossDomainSecurityEnabled フラグの有効/無効の設定を切り替えると、しばらくの間トランザクションや他のリモート呼び出しが失敗することがある。トランザクションにおいてコミット リクエストが失敗した場合は、コンフィグレーションの変更が完了した後にコミットが再試行されます。トランザクションの RMI 呼び出しが失敗した場合は、トランザクションがタイムアウトしてロールバックされます。ロールバックは、AbandonTimeoutSeconds が経過するまで再試行されます。
[セキュリティの相互運用モード] を使用すると、グローバル トランザクション内のサーバ間に、互換性のある通信チャネルをコンフィグレーションできます。次の手順に従って、セキュリティの相互運用モードをコンフィグレーションします。
| 注意 : | [セキュリティの相互運用モード] が [パフォーマンス] に設定されている場合、ドメイン間におけるドメインの信頼関係の設定は必須ではありません。 |
すべての参加ドメインのセキュリティ資格を同じ値に設定します。これにより、ドメインの信頼関係が確立します。
参加しているすべてのサーバの [セキュリティの相互運用モード] パラメータを同じ値に設定する必要があります。
参加しているサーバのセキュリティの相互運用モードをコンフィグレーションするには、以下を参照してください。
セキュリティの相互運用モードを使用して、同じドメイン内のトランザクションに参加するサーバ間に、互換性のある通信チャネルを正しくコンフィグレーションする必要があります。「セキュリティの相互運用モードのコンフィグレーション」を参照してください。
ドメイン内トランザクション用にどのタイプの通信チャネルをコンフィグレーションする必要があるかについては、以下の情報を参考に判断してください。
各サーバには、そのサーバで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション ログが備わっています。WebLogic Server では、システムのクラッシュやネットワーク障害からの回復時にトランザクション ログを使用します。トランザクション ログを直接見ることはできません。レコードはバイナリ形式で、サーバのデフォルト永続ストアに格納されます。
クラスタ内のサーバに対するトランザクション回復サービスの移行機能を利用するには、トランザクション ログをサーバとそのバックアップ サーバが使用できる場所 (デュアルポート SCSI ディスクまたは SAN (Storage Area Network) を推奨) に格納する必要があります。詳細については、「デフォルト永続ストアへのパスの設定」を参照してください。
デフォルトのストアがトランザクション ログ レコードの保存先とするファイル システムで領域が不足したり、アクセス不能になったりすると、commit() が SystemException を送出し、トランザクション マネージャによってシステム エラー ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。
管理サーバを含む、各サーバ インスタンスには、デフォルトの永続ストアがあります。これは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ メカニズムを使用することで最適に動作するサブシステムから使用することができる、ファイルベースのストアです。トランザクション マネージャは、デフォルト永続ストアを使用して、トランザクション ログ レコードを格納します。多くの場合、デフォルトの永続ストアは、コンフィグレーションを必要としません。ただし、トランザクション回復サービスの移行を有効化するには、オリジナルのサーバで障害が発生した場合に、クラスタ内の別のサーバで使用できる、永続ストレージ ソリューションに、データ ファイルを格納するよう、デフォルトの永続ストアをコンフィグレーションする必要があります。
手順については、Administration Console オンライン ヘルプの「トランザクション回復サービスの移行のためのデフォルト永続ストアのコンフィグレーション」を参照してください。
WebLogic Server は、デフォルト永続ストアを使用して、トランザクション ログ レコードを格納します。デフォルト ストアの書き込みポリシーを選択することで、WebLogic Server がレコードをディスクに書き込む方式を変更できます。以下のいずれかのオプションを選択できます。
| 警告 : | 無効化された同期書き込みポリシーでは、トランザクションの安全性が低くなります。アプリケーションでグローバル トランザクションを使用する場合は、このオプションを選択しないでください。 |
Windows では [Direct-Write] トランザクション ログ ファイル書き込みポリシーが指定されていても、トランザクション データがディスクに直接書き込まれずにオンディスク キャッシュに残される場合があります。この場合、停電などによってオンディスク キャッシュのデータが失われるおそれがあり、トランザクションとしては安全とはいえません。Windows で [Direct-Write] トランザクション ログ ファイル書き込みポリシーを使用している場合にキャッシュ データの消失を回避するには、ディスクの書き込みキャッシュをすべて無効にするか (デフォルトでは有効)、またはシステムのバッテリー バックアップを使用してください。
手順については、Administration Console オンライン ヘルプの「トランザクション回復サービスの移行のためのデフォルト永続ストアのコンフィグレーション」を参照してください。
  
|
