Oracle® Fusion Middleware Oracle WebLogic Server JTAアプリケーションの開発 12c (12.2.1) E72527-01 |
|
前 |
次 |
この章では、トランザクション関連の基本的な構成タスクについて説明します。これらのタスクとしては、JTAの使用、セキュアなトランザクション通信の構成、トランザクション・ログ(TLog)ファイルの使用、読取り専用1フェーズ・コミットの最適化の使用があります。
この章には次の項が含まれます:
管理コンソールは、WebLogic JTAなどのWebLogic Serverの機能を構成するために使用するインタフェースを備えています。構成プロセスでは、属性の値を指定する必要があります。それらの属性によって、以下のようなトランザクション環境が定義されます。
トランザクションのタイムアウトと制限
トランザクション・マネージャの動作
また、EJB、JDBCデータ・ソース、JMSなど、トランザクションに参加可能なJava EEコンポーネントの管理についてもよく理解しておく必要があります。
注意: トランザクション関連の構成には、WebLogic Scripting Tool (WLST)(『WebLogic Scripting Toolの理解』を参照)またはJMX(『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照)を使用することもできます。 |
WebLogic JTAおよび任意のトランザクション参加コンポーネントを構成すると、システムはJTA APIおよびWebLogic JTA拡張機能を使用してトランザクションを管理できます。次の点に注意してください。
JTA (トランザクション)の構成設定は、次のように、ドメイン・レベルおよびクラスタ・レベルで適用できます。
ドメイン・レベルでは、属性の設定はドメイン内のすべてのサーバーに適用されます。これらの設定は、クラスタ・レベルの設定に差し替えられます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「ドメイン: 構成: JTA」を参照してください。
クラスタ・レベルでは、属性の設定はドメイン内の1つのクラスタに適用されます。これらの設定は、ドメイン・レベルの設定に優先します。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では次の構成属性が用意されています。
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トランザクション・アフィニティにより、サーバー・インスタンスで、関連リクエストを他のメンバー・サーバーにロード・バランシングするのではなく、グローバル・トランザクションへの参加によってこれらのリクエストを処理できます。Enable Transaction Affinity=true
に設定すると、次のような理由から、クラスタのスループットが向上します。
サーバー間のトランザクション調整トラフィックの軽減
JDBC接続の減少など、リソース使用率の改善
トランザクションの非同期処理の簡素化
そのトランザクションに参加しているメンバーがクラスタにない場合、リクエストは利用可能なクラスタ・メンバーへロード・バランシングされます。選択したクラスタ・メンバーに障害が発生した場合は、『Oracle WebLogic Serverクラスタの管理』のJTAトランザクション・リカバリ・サービスの自動移行を構成するためのロードマップに関する項の説明に従って、JTAトランザクション・リカバリ・サービスを移行できます。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプでクラスタの構成に関する項を参照してください。コマンド行での-Dweblogic.cluster.TxnAffinityEnabled=true
の使用によって、XAトランザクション・アフィニティを有効にすることもできます。
各サーバーには、そのサーバーで調整されてコミットされたが、未完了の可能性があるトランザクションの情報を格納するトランザクション・ログが備わっています。WebLogic Serverでは、システムのクラッシュやネットワーク障害からのリカバリ時にトランザクション・ログ(TLog)が使用されます。トランザクション・ログは直接は表示できません。それらのレコードはバイナリ形式であり、サーバーのデフォルト永続ストアまたはJDBC TLogストアに格納されます。
クラスタ内のサーバーに対するトランザクション・リカバリ・サービスの移行機能を利用するには、トランザクション・ログをサーバーとそのバックアップ・サーバーが使用できる場所(デュアル・ポートSCSIディスクまたはSAN (Storage Area Network)を推奨)に格納する必要があります。詳細については、「デフォルト永続ストアへのパスの設定」を参照してください。
デフォルトのストアがトランザクション・ログ・レコードの保存先とするファイル・システムで領域が不足したり、アクセス不能になったりすると、commit()
によりSystemException
がスローされ、トランザクション・マネージャによってシステム・エラー・ログにメッセージが書き込まれます。使用できる領域が増えるまで、トランザクションはコミットされません。
管理サーバーを含む、各サーバー・インスタンスには、デフォルトの永続ストアがあります。これは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができる、ファイル・ベースのストアです。トランザクション・マネージャは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。多くの場合、デフォルトの永続ストアは、構成を必要としません。ただし、トランザクション・リカバリ・サービスの移行を有効化するには、オリジナルのサーバーで障害が発生した場合に、クラスタ内の別のサーバーで使用できる、永続ストレージ・ソリューションに、データ・ファイルを格納するよう、デフォルトの永続ストアを構成する必要があります。
手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
WebLogic Serverは、デフォルト永続ストアを使用して、トランザクション・ログ・レコードを格納します。デフォルト・ストアの書込みポリシーを選択することで、WebLogic Serverがレコードをディスクに書き込む方式を変更できます。「WebLogic永続ストアの管理」を参照してください。
手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービス移行のためのデフォルト永続ストアの構成に関する項を参照してください。
トランザクション・ログがデータベース内に永続的に保持されるようJDBC TLogストアを構成できます。これにより、基礎となるデータベースのレプリケーションやHA特性の活用、障害回復の簡潔化、およびトランザクション・リカバリ・サービスの移行の改善が可能になります。WebLogic永続ストアの管理を参照してください。
LLRは、1つの非XAリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。「ロギング・ラスト・リソース・トランザクションの最適化」を参照してください。
「トランザクションのリカバリのためのトランザクション・ログ・ファイルの使用」で説明されているように、TLogは、インダウト・トランザクションを解決するために使用されます。ただし、これらのファイルの作成と維持に関連するパフォーマンス・コストは、非常に高くなる可能性があります。たとえば、読取りと書込み、リソース・マネージャ間のネットワーク呼出し、およびHA記憶域などのコストがあります。
注意: XAトランザクション内のサーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。これらのチェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。 |
次の項では、XAトランザクションの範囲が複数のトランザクション・マネージャ(TM)またはドメインである場合、TLogを除去することによりXAトランザクションのパフォーマンスが向上させる方法についての情報を提供します。
決定子は、JDBC XAリソースおよびJMS XAリソースで、TLogが存在しない場合に、トランザクション・リカバリにおいてそのリソースのインダウト・トランザクション・レコードが使用されます。
次の項では、グローバル・トランザクションで決定子リソースを使用するためのベスト・プラクティスを紹介します。
決定子リソースのターゲットは、グローバル・トランザクションを実行するサーバーである必要があります。クラスタ環境では、サービスまたはサーバーの移行時に高可用性を確保するため、決定子リソースのターゲットはクラスタである必要があります。
トランザクション・リカバリ・サービスの移行をサポートするには:
JDBC XAリソースの場合は、決定子DataSourceのターゲットをクラスタにします。
JMS XAリソースの場合は、JMSサービスのターゲットを、カスタム永続ストアによって使用されるのと同じ移行可能なターゲットにします。詳細は、『Oracle WebLogic Serverクラスタの管理』のJMSサービスで使用できるカスタム・ストアに関する項を参照してください。
最小限の数の決定子リソースを構成します。これにより、リカバリのために使用できる必要があるリソースの数が少なくなります。
次の各項では、ご使用の環境において決定子を構成、更新および削除する方法を説明します。
決定子を構成するには:
決定子リソースとして構成するJDBC XAリソースまたはJMS XAリソースをホストするサーバー上の、すべてのXAトランザクションが完了していることを確認してください。
決定子として使用するJDBC XAリソースをホストする、すべてのサーバーまたはクラスタを停止します。
まだ実行していない場合は、WebLogic Server管理コンソールの「チェンジ・センター」で「ロックして編集」をクリックします(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのチェンジ・センターの使用に関する項を参照)。
1つのドメインまたはクラスタに対して、決定子を構成できます。
ドメインの場合: WebLogic Server管理コンソールの左ペインで、ツリーの一番上のドメイン名を選択します。
クラスタの場合: WebLogic Server管理コンソールの左ペインで「環境」を開き、「クラスタ」を選択します。次に、「クラスタの概要」 表で、構成するクラスタを選択します。
「構成: JTAタブで、「決定子」ボックス内に表示されるデータ・ソースのリストから、1つ以上の決定子を選択します。
WebLogic Serverトランザクション・マネージャで登録したXAリソースが、決定子としてこのリスト・ボックスに表示されます。
WebLogic JMSを決定子として構成するには、"WebLogic JMS"を選択します。WebLogic JMSは、WebLogic JMSがWebLogic Serverトランザクション・マネージャで使用または登録するすべてのJMSストアを表します。
注意: 高可用性が確保されるように決定子リソースのターゲットを指定してください。「決定子リソースを使用する場合のベスト・プラクティス」を参照してください。
必要に応じて、1つ以上の決定子が構成されている場合でもトランザクション・リカバリ・ログを書き込むようにするには、Write recovery logs when determiners configured属性を有効にします。
「保存」をクリックします。
WebLogic Server管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
すべての変更内容がすぐに反映されるわけではなく、再起動するまで有効にならない変更内容もあります(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのチェンジ・センターの使用に関する項を参照)。
構成された決定子リソースをホストするすべてのサーバーまたはクラスタを再起動します。
これで、ご使用の環境でトランザクション処理を再開する準備が整いました。
決定子を削除するには:
決定子リソースとして削除するJDBC XAリソースまたはJMS XAリソースをホストするサーバー上の、すべてのXAトランザクションが完了していることを確認します。
削除する決定子リソースをホストする、すべてのサーバーまたはクラスタを停止します。
まだ実行していない場合は、WebLogic Server管理コンソールの「チェンジ・センター」で「ロックして編集」をクリックします(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのチェンジ・センターの使用に関する項を参照)。
1つのドメインまたはクラスタの決定子を削除できます。
ドメインの場合: WebLogic Server管理コンソールの左ペインで、ツリーの一番上のドメイン名を選択します。
クラスタの場合: WebLogic Server管理コンソールの左ペインで「環境」を開き、「クラスタ」を選択します。次に、「クラスタの概要」 表で、構成するクラスタを選択します。
「構成」: 「JTA」タブで、「決定子」属性で指定されているリストから1つ以上の決定子を削除します。
「保存」をクリックします。
WebLogic Server管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。
すべての変更内容がすぐに反映されるわけではなく、再起動するまで有効にならない変更内容もあります(Oracle WebLogic Server管理コンソール・オンライン・ヘルプのチェンジ・センターの使用に関する項を参照)。
手順2で停止した、すべてのサーバーまたはクラスタを再度起動します。
これで、ご使用の環境でトランザクション処理を再開する準備が整いました。
次の項では、TLogを使用せずにトランザクションを構成する場合の制限と考慮事項に関する重要な情報を示します。
次のような場合には、TLogを使用しないトランザクションの構成はサポートされていません。
グローバル・トランザクションにJTSリソースまたはLLRリソースが含まれる場合
WS-AT、OTS、WLSまたはTuxedoトランザクションなどのトランザクション、および外部のトランザクション・マネージャを含むトランザクションに参加する場合
グローバル・トランザクションの処理の一部として、決定子リソースで読取り操作しか実行されない場合
parallel-xa-enabled
がfalse
に設定されている場合(デフォルト値はtrue
)
サーバーとリソースのチェックポイントは、引き続きTLOGに書き込まれます。チェックポイントは、リソースが最初にグローバル・トランザクションに関与するときに書き込まれ、トランザクション参加者に変更がある場合にのみ更新され、トランザクション参加者が使用されていないか使用不可になった場合にのみパージされます。チェックポイントはトランザクションの早い段階で作成されるため、グローバル・トランザクションで参加者に変更がないかぎり、トランザクション・サービスの移行中や複数サイトまたはデータ・センターにわたるトランザクション・リカバリ中にチェックポイントが同期しなくなる危険はほとんどありません。
Abandon Timeout Seconds
はサポートされていません。インダウト・トランザクションでは、解決されるかリソースが管理者によって削除されるまで、リカバリが試みられます。
XAトランザクションをリカバリできないために決定子リソースを利用できない場合、WebLogic Serverは起動しません。
決定子リソースのターゲット指定を変更するには、次を実行する必要があります。
その決定子リソースをホストするサーバー上の、すべてのXAトランザクションが完了していることを確認します。
その決定子リソースをホストするすべてのサーバーを停止します。
その決定子リソースのターゲットを再指定します。
その決定子リソースをホストするすべてのサーバーまたはクラスタを起動します。
指定された決定子のリストから、複数の決定子リソースが使用可能な場合は、リストされている最初の決定子が暗黙的にトランザクションの決定子に指定されます。
アプリケーションでは、決定子リソースがあるグローバル・トランザクションと、ないグローバル・トランザクションを組み合せて使用できます。決定子リソースがないグローバル・トランザクションのみがTLogに書き込まれます。
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リソースがXA_OK 投票を準備から返し(例: 対象がOracleデータベースではない場合)、その後ロールバックが発生する前にWebLogicインスタンスがクラッシュする場合は、インダウト・レコードが存在し、ロックがリソース・マネージャ(データベース)で保持されるため、手動で解決する必要があります。 |
すべてのJTAドメイン構成オプションの詳細は、Oracle WebLogic管理コンソール・オンライン・ヘルプのJTAドメインの構成に関する項を参照してください。
監視目的のため、JTAの「監視」ページには5つのトランザクション処理統計があります。これらの統計はともに「コミット済みトランザクション総数」統計を分類し、あらゆる読取り専用1フェーズ・トランザクション統計を追跡しやすくします。
リソースのないコミット済みトランザクションの合計数 - サーバーの起動以降コミットされた、リソースが確保されていないトランザクションの合計数。
1リソース1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降1フェーズ・コミットされた、1リソースのみが確保されたトランザクションの合計数。
読取り専用1フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降、読取り専用最適化のために1フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
2フェーズ・コミット済みトランザクション合計数 - サーバーの起動以降2フェーズ・コミットされた、複数のリソースが確保されたトランザクションの合計数。
LLRコミット済みトランザクション合計数 - サーバーの起動以降コミットされたLLRトランザクションの合計数。
注意: JTAトランザクションに列記された唯一のリソースがLLRデータ・ソースの場合、そのトランザクションは「LLRコミット済みトランザクション合計数」カテゴリではなく、「1リソース1フェーズ・コミット済みトランザクション合計数」カテゴリの下に含まれます。
JTA監視統計の詳細は、Oracle WebLogic管理コンソール・オンライン・ヘルプのJTA統計の監視に関する項を参照してください。