| Oracle® Fusion Middleware Oracle WebLogic Server JTAアプリケーションの開発 12c (12.1.2) E48087-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JTAアプリケーションの開発 12c (12.1.2) E48087-03 |
|
前 |
次 |
この章では、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 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 WebLogic Server管理コンソール・オンライン・ヘルプのLLRを利用可能なJDBCデータ・ソースの作成に関する項を参照してください。また、『Oracle WebLogic Server JDBCデータ・ソースの管理』のロギング・ラスト・リソースのトランザクション・オプションの理解に関する項も参照してください。
データ・ソースの構成および使用上の要件と制限事項のリストは、『Oracle WebLogic Server JDBCデータ・ソースの管理』の次のトピックを参照してください。
LLRデータ・ソースに関するプログラミング上の考慮事項と制限事項
LLRデータ・ソースに関する管理上の考慮事項と制限事項
各WebLogicサーバー・インスタンスは、JDBC LLRデータ・ソースがデータベース接続をプールするデータベース上に、データベース「LLR」表を保持します。これらの表は、トランザクション・ログ・レコードの格納に使用されるもので、自動的に作成されます。複数のLLRデータ・ソースが同じWebLogicサーバー・インスタンス上にデプロイされて同じデータベース・インスタンスおよびデータベース・スキーマに接続されている場合、これらのデータ・ソースも同じLLR表を共有します。
LLR表名は、管理者が構成することを選択しない限り、自動的に生成されます。デフォルトの表名は、WL_LLR_SERVERNAMEです。一部のDBMSシステムでは、表名の長さが最大18文字に制限されます。環境を構成する際には、表名の最大長を考慮に入れてください。
LLRデータベース表に関しては、次の制限事項があります。
起動時にLLR表にアクセスできなかった場合、サーバーは起動しません。サーバー起動時に自動的に実行されるリカバリの期間中に、疑わしいトランザクションを正しく解決するには、LLRトランザクション・レコードが使用できなければなりません。
複数のサーバーで同じLLR表を共有することはできません。サーバー起動時に、WebLogic ServerはJDBCデータ・ソースのドメイン名とサーバー名が、表作成時に表に格納されたドメイン名とサーバー名に一致することを確認します。複数のサーバーが同じLLR表を共有していることを検出すると、WebLogic Serverは1つまたはそれ以上のサーバーを停止します。
リソースのトランザクション・ログ・レコードの格納に使用される表名を変更するには、次の手順に従います。
管理コンソール画面の左上の隅にある「チェンジ・センター」で、「ロックして編集」をクリックして、構成編集セッションを開始します。
「サーバー: 構成: 全般」ページで、「詳細」をクリックして、詳細構成のオプションを表示します。次を参照
「JDBC LLR表名」に、リソースのトランザクション・レコードの格納に使用する表の名前を入力し、その後「保存」をクリックします。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: 全般に関する項を参照してください。
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データ・ソースを構成する必要があります。
Oracle RACを使用する環境のパフォーマンスを改善するには、各サーバーに対してではなく各データ・ソースに対してLLR表を指定することで、Oracle RACクラスタでのローカル・ノード・キャッシュの利用効率が上がります。
WebLogic Serverインスタンスの起動時にデータ・ソースごとにLLR表の指定を設定するには、次のシステム・プロパティを使用します。
-Dweblogic.llr.table.datasourcename=tablename
ここで、datasourcenameはデータ・ソースの名前、tablenameは、datasourcenameにマップするLLR表の名前です。
たとえば、次のシステム・プロパティを使用するとします。
-Dweblogic.llr.table.LLRDS1=myllrtable1
サーバーが起動すると、次の操作が行われます。
INFOメッセージがstdoutに書き込まれます。
LLR data source LLRDS1 using LLR table myllrtable1
データ・ソースLLRDS1を使用するサーバー用のすべてのLLRエントリは、mylltable1というLLR表に格納されます。
データ・ソースがターゲット指定される各サーバーの各データ・ソースに対して1つの表を定義します。異なるWLSインスタンスで同じ表を共有することはできません。LLRDS1が2つのWebLogic ServerインスタンスS1およびS2にターゲット指定される場合、2つの表S1_LLRDS1とS2_LLRDS1を作成し、各サーバーに適切なシステム・プロパティを指定します。
例:
S1の場合、-Dweblogic.llr.table.LLRDS1=S1_LLRDS1を使用します。
S2の場合、-Dweblogic.llr.table.LLRDS1=S2_LLRDS1を使用します。
|
注意: 次のリリースのWebLogic Serverでは、 |
