| 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 |
|
戻る |
次へ |
WebLogic Server では、JDBC データ ソースを通じてのロギング ラスト リソース (LLR) トランザクションの最適化をサポートしています。LLR は、1 つの XA 以外のリソースが、XA と同じ ACID 保証を伴ってグローバル トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。LLR は、「最後のエージェントによる最適化」を改良したものです。最後のエージェントによる最適化との相違点は、トランザクションとしては安全であるということです。LLR リソースは、トランザクション処理にローカル トランザクションを使用します。WebLogic Server トランザクション マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLR リソースのローカル トランザクションの結果に基づいて、グローバル トランザクションに対するコミットの決定を下します。
LLR 参加リソースによるグローバルな 2 フェーズ コミット (2PC) トランザクションでは、WebLogic Server トランザクション マネージャは次の基本的な手順に従います。
他のすべての (XA 対応の) トランザクション参加リソースに対して prepare を呼び出す。
(ファイル ベースのトランザクション ログではなく) LLR 参加リソースのテーブルへコミット レコードを挿入する。
LLR 参加リソースのローカル トランザクション (トランザクション コミット レコードの挿入とアプリケーションの SQL 処理の双方を含む) をコミットする。
その他すべてのトランザクション参加リソースに対して commit を呼び出す。
トランザクションが正常に終了したら、データベース トランザクション ログ エントリを、今後のトランザクションの一部として、時間をかけて削除する。
以下の節は、WebLogic Server における LLR トランザクション処理の詳細を説明します。
LLR の特長に関する詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「ロギング ラスト リソース トランザクション オプションについて」を参照してください。
多くの場合、グローバル トランザクションが 2 フェーズ コミット (2PC) トランザクションになるのは、データベース操作 (JDBC を使用) と、メッセージ キュー操作 (JMS を使用) などの非データベース操作が関与しているためです。このように、2PC トランザクション内のデータベースへの参加リソースが 1 つの場合、ロギング ラスト リソース (LLR) 最適化トランザクション オプションは、データベース処理の XA オーバーヘッドの一部を除去し、JDBC XA ドライバ (通常は非 XA ドライバよりも効率が悪い) の使用を回避することにより、トランザクションのパフォーマンスを著しく向上させられます。LLR トランザクション オプションでは、[2 フェーズ コミットのエミュレート] JDBC データ ソース オプションや NonXAResource リソース アダプタ (コネクタ) オプションの場合のようにデータがリスクを受けることはありません。
サーバ起動時またはデータ ソースのデプロイメント時に、LLR データ ソースは、データベース接続のプールを行うデータベース上に、テーブルをロードまたは作成します。テーブルは、データベース接続を作成するよう指定されたユーザが決定したスキーマ内に作成されます。データベース テーブルが作成またはロードできない場合、サーバの起動は失敗します。
グローバル トランザクション内で、LLR データ ソースから最初に取得された接続が、そのトランザクション専用の内部 JDBC 接続を予約します。内部 JDBC 接続は、トランザクションのコーディネータでもある特定のサーバ上で予約されます。任意のサーバにある同名のデータ ソースから取得された接続に対する後続のトランザクション操作は、すべてこの同じ単一の内部 JDBC 接続にルーティングされます。
LLR トランザクションがコミットされると、WebLogic Server トランザクション マネージャはその処理を透過的に扱います。アプリケーション側から見ると、トランザクション セマンティクスは同じままですが、内部から見ると、トランザクションには標準的な XA トランザクションとは異なった処理が行われています。アプリケーションがグローバル トランザクションをコミットすると、WebLogic Server トランザクション マネージャは、他のトランザクション参加リソースに対してトランザクション作業をコミットする前に、LLR 接続に対して原子性を維持しつつローカル トランザクションをコミットします。2 フェーズ コミット トランザクションの場合、トランザクション マネージャは同じローカル トランザクションの一部として、データベース上に 2PC レコードの書き込みも行います。ローカル トランザクションが正常に完了した後、トランザクション マネージャは他のすべてのグローバル トランザクション参加リソースに対し commit を呼び出します。他のすべてのトランザクション参加リソースがコミット フェーズを完了させると、関連の LLR 2PC トランザクション レコードは、解放されて削除できるようになります。トランザクション マネージャは、短い間隔を置いて、または別のローカル トランザクションで、トランザクション レコードを時間をかけて削除します。
アプリケーションがグローバル トランザクションをロールバックするか、トランザクションがタイムアウトした場合、トランザクション マネージャはローカル トランザクションの作業をロールバックし、データベースに 2PC レコードを格納しません。
LLR トランザクションの最適化を有効化するには、JDBC データ ソースをロギング ラスト リソース トランザクション プロトコルで作成して、アプリケーション内のデータ ソースからデータベース接続を使用します。WebLogic Server は、データベース上に必要なテーブルを自動作成します。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「LLR を利用可能な JDBC データ ソースの作成」を参照してください。また、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「ロギング ラスト リソース トランザクション オプションについて」も参照してください。
データ ソースのコンフィグレーションおよび使用上の要件と制限事項のリストについては、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の以下のトピックを参照してください。
各 WebLogic サーバ インスタンスは、JDBC LLR データ ソースがデータベース接続をプールするデータベース上に、データベース「LLR」テーブルを保持します。これらのテーブルは、トランザクション ログ レコードの格納に使用されるもので、自動的に作成されます。複数の LLR データ ソースが同じ WebLogic サーバ インスタンス上にデプロイされて同じデータベース インスタンスおよびデータベース スキーマに接続されている場合、これらのデータ ソースも同じ LLR テーブルを共有します。
LLR テーブル名は、管理者がコンフィグレーションすることを選択しない限り、自動的に生成されます。デフォルトのテーブル名は、WL_LLR_SERVERNAME です。一部の DBMS システムでは、テーブル名の長さが最大 18 文字に制限されます。環境をコンフィグレーションする際には、テーブル名の最大長を考慮に入れてください。
LLR データベース テーブルに関しては、以下の制限事項があります。
起動時に LLR テーブルにアクセスできなかった場合、サーバは起動しない。サーバ起動時に自動的に実行される回復の期間中に、疑わしいトランザクションを正しく解決するには、LLR トランザクション レコードが使用できなければなりません。
複数のサーバで同じ LLR テーブルを共有することはできない。サーバ起動時に、WebLogic Server は JDBC データ ソースのドメイン名とサーバ名が、テーブル作成時にテーブルに格納されたドメイン名とサーバ名に一致することを確認します。複数のサーバが同じ LLR テーブルを共有していることを検出すると、WebLogic Server は 1 つまたはそれ以上のサーバを停止します。
リソースのトランザクション ログ レコードの格納に使用されるテーブル名を変更するには、次の手順に従います。
Administration Console 画面の左上の隅にある [チェンジ センタ] で、[ロックして編集] をクリックして、コンフィグレーション編集セッションを開始します。
[サーバ : コンフィグレーション : 全般] ページで、[詳細] をクリックして、詳細コンフィグレーションのオプションを表示します。
[JDBC LLR テーブル名] に、リソースのトランザクション レコードの格納に使用するテーブルの名前を入力し、その後 [保存] をクリックします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバ : コンフィグレーション : 全般」を参照してください。
LLR が有効化されたデータ ソースがデプロイされている各サーバに対して、手順 2 および 3 を繰り返します。
[チェンジ センタ] で [変更のアクティブ化] をクリックします。
|
注意 : 変更を有効にするには、すべてのサーバを再起動する必要があります。 |
コミットされた各 2PC LLR トランザクションについて、トランザクション マネージャは LLR データベース テーブルにトランザクション レコードを自動的に挿入します。LLR トランザクションが完了すると、トランザクション マネージャは時間をかけて、トランザクション レコードを削除します。LLR テーブル トランザクション ログ レコードの削除が失敗した場合、サーバは警告メッセージをログに記録し、後で削除を再試行します。
LLR トランザクション レコードが格納されたデータベースを移動する必要がある場合は、トランザクションが正しく完了できるよう、必ず LLR テーブルのコンテンツを新しいデータベースに移動してください。
|
注意 : プロダクション システムでは、LLR トランザクション レコードまたは LLR テーブルを手動で削除しないでください。削除すると、暗黙のヒューリスティックなトランザクションが失敗します。この失敗は、ログには記録されません。 |
一般に、WebLogic トランザクション マネージャは、次のようにしてトランザクションの失敗を処理します。
ローカル トランザクションのコミットが試行される前に発生する 2 フェーズ コミット エラーの場合、トランザクション マネージャは即座にトランザクション ロールバック例外を送出する。
ローカル トランザクションのコミット中に発生する 2 フェーズ コミット エラーの場合、動作はトランザクション レコードがデータベースに書き込まれるかどうかに応じて異なる。
レコードが書き込まれるならば、トランザクション マネージャはトランザクションをコミットする。
レコードが書き込まれないならば、トランザクション マネージャはトランザクションをロールバックする。
レコードが書き込まれるかどうかが分からない場合は、トランザクション マネージャはあいまいなコミット失敗例外を送出し、トランザクション破棄タイムアウトになるまで、5 秒ごとにトランザクションの完了を試行する。トランザクションが未完了のままであれば、トランザクション マネージャは破棄されたトランザクション メッセージをログに記録します。
LLR リソースがトランザクション ログ レコードを格納する前、または LLR リソースがコミットする前に、トランザクションの調整サーバがクラッシュした場合、トランザクションはロールバックされます。LLR リソースがコミットされた後にサーバがクラッシュした場合、トランザクションは最終的には完全にコミットされます。サーバ起動中、トランザクション コーディネータは LLR リソースを使用してデータベースからトランザクション ログ レコードを読み取り、その後、回復された情報を使用して、参加しているすべての非 LLR XA リソース上の未完了の作業をすべてコミットします。
LLR リソースの JDBC 接続が、2PC トランザクション レコードの挿入中に失敗した場合、トランザクション マネージャはトランザクションをロールバックします。
LLR リソースの JDBC 接続が、ローカル トランザクションのコミット中に失敗した場合の結果は、トランザクションが 1 フェーズ コミット (LLR リソースが唯一の参加リソースである、1PC) であるか 2PC であるかによって異なります。
1PC トランザクションの場合、トランザクションは完全にコミットされる、完全にロールバックされる、またはローカル トランザクションの解決の待機をブロックする。トランザクションは最終的に完全にコミットされるか、完全にロールバックされるので、その結果は完全に ACID です。
2 PC トランザクションの場合の結果は、「LLR の障害と回復処理」で説明したようになる。
各 WebLogic サーバのトランザクション マネージャは、サーバ起動時に、サーバによって調整される未完了のトランザクション (LLR トランザクションを含む) を回復する必要があります。そのためには、各サーバは各 LLR データ ソースの LLR データベース テーブルから、トランザクション レコードを読み取ろうとします。サーバが LLR データベース テーブルにアクセスできない場合、または回復が失敗した場合、サーバは起動せず、トランザクション マネージャにより不正な状態 (HealthState.HEALTH_FAILED) としてマークされます。
回復の途中でタイムアウトが生じたとすれば、それは LLR ログ テーブル内の行をロックした未解決のローカル トランザクションが原因である場合があります。そのようなローカル トランザクションを解決して、レコードがロックされた行に格納されているグローバル トランザクションの状態をトランザクション マネージャが判断できるようにする必要があります。ローカル データベース トランザクションは診断および解決するには、各データベースの固有のツールを使用する必要があります (コマンドはデータベースごとに違います)。
LLR でのフェイルオーバに関する以下の注意事項および制限事項を考慮してください。
ファイルベースのトランザクション ログ (TLog) は、LLR トランザクションでも必要。
TLog は引き続きトランザクション マネージャの「チェックポイント」レコードを格納する。
TLog はフェイルオーバでも引き続きアクセス可能である、またはコピーされる。
LLR は、サーバの移行およびトランザクション回復サービスの移行をサポートする。トランザクション回復サービスの移行を使用するには、クラスタまたはクラスタ内の候補サーバのセットのいずれかに各 LLR リソースが対象指定されていることを確認します。「クラスタ化されたサーバで障害が発生した場合のトランザクションの回復」を参照してください。
この節の内容は、以下のとおりです。
LLR 参加リソースでのグローバル トランザクション内では、WebLogic Server はすべての接続操作をトランザクションの調整サーバに自動的にルーティングします。このルーティングが大きな負荷になる場合があります。可能であれば、アプリケーションが調整サーバ上で直接実行されるように、またコーディネータ上で直接ホストされる接続インスタンスを使用するように、最適化を行うと、パフォーマンスが向上すると考えられます。
トランザクションを開始するクライアント アプリケーションに関しては、トランザクションのコーディネータは、クライアントがそのトランザクションの下で呼び出し (RMI、EJB、JDBC、または JMS 呼び出しのどれでも可) を行う最初の WebLogic サーバとなります。JMS の場合、これはクライアントの JMS 接続をホストするサーバです。JMS 送り先をホストするサーバと同じである必要はありません。
サーバサイド アプリケーションの場合、トランザクションのコーディネータは、ローカル リソースが最初に呼び出されたのであれば (JMS 送り先、JDBC 接続など) ローカル サーバとなります。ただし、先にリモート サーバが呼び出されていた場合 (リモートでホストされる JDBC 接続、EJB、RMI 呼び出し、または JMS 接続のいずれか) は、その限りではありません。これには、他のクラスタまたはドメインのリモート サーバが含まれます。
LLR の最適化により、挿入、更新、および削除の操作において、著しいパフォーマンスの向上がもたらされます。しかし、LLR での読み取り操作では、XA での読み取り操作と比べて、幾分パフォーマンスが低下します。最高のパフォーマンスを得るためには、読み取り専用操作のための LLR ではない JDBC データ ソースをコンフィグレーションする必要があります。
