| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 12cリリース1 (12.1.1) B65892-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理 12cリリース1 (12.1.1) B65892-02 |
|
前 |
次 |
この章では、WebLogicデータ・ソースのXA、XA以外およびグローバル・トランザクションのオプションについて説明します。
管理コンソールを使用してJDBCデータ・ソースを構成すると、WebLogic ServerはJDBCドライバの種類に基づき、自動的に特定のトランザクション・オプションを選択します。
XAドライバの場合、システムは自動的に、グローバル・トランザクション処理のための2フェーズ・コミット・プロトコルを選択します。
非XAドライバの場合、ローカル・トランザクションは定義によってサポートされており、WebLogic Serverは以下のオプションを提供します。
「グローバル・トランザクションのサポート」 : (デフォルトで選択) XAドライバを選択していなくても、グローバル・トランザクションでデータ・ソースからの接続を使用する場合には、このオプションを選択します。詳細については、「非XA JDBCドライバでのグローバル・トランザクションのサポートの有効化」を参照してください。
「グローバル・トランザクションのサポート」を選択した場合は、グローバル・トランザクションを処理するときに、WebLogic Serverがトランザクション・ブランチに使用するプロトコルも選択する必要があります。
「ロギング・ラスト・リソース」 :このオプションを使用すると、接続が使用されているトランザクション・ブランチが、トランザクションの最後のリソースとして処理され、ローカル・トランザクションとして処理されます。2フェーズ・コミット(2PC)トランザクションのコミット・レコードは、リソース自体の表に挿入され、その結果によって、グローバル・トランザクションの準備フェーズの成功または失敗が決定されます。このオプションでは、「2フェーズ・コミットのエミュレート」よりもパフォーマンス上のメリットとデータの安全性が得られますが、いくつかの制限事項もあります。「ロギング・ラスト・リソース・トランザクション・オプションについて」を参照してください。
|
注意: ロギング・ラスト・リソースは、マルチ・データ・ソースで使用されるデータ・ソースについてはサポートされていません。ただし、「LLRデータ・ソースに関する管理上の考慮事項と制限事項」で説明するように、Oracle RACバージョン10Gリリース2 (10GR2)以降と一緒に使用する場合を除きます。 |
2フェーズ・コミットのエミュレート: このオプションを使用すると、接続が使用されているトランザクション・ブランチは、トランザクションの準備フェーズに対して常に成功を戻します。パフォーマンス上のメリットはありますが、いくつかの失敗の状況ではデータにリスクがあります。このオプションは、アプリケーションがヒューリスティックな状況を許容できる場合にのみ選択します。「2フェーズ・コミットのエミュレート・トランザクション・オプションについて」を参照してください。
1フェーズ・コミット: (デフォルトで選択済み)このオプションを使用すると、データ・ソースからの接続がグローバル・トランザクションの唯一の参加者となることができ、トランザクションは1フェーズ・コミットの最適化を使用して完了します。トランザクションに複数のリソースが参加している場合、トランザクション・マネージャが1PCリソースに対してXAResource.prepareを呼び出すと、例外がスローされます。
この項は、次の情報を含みます。
アプリケーションでグローバル・トランザクションを使用する場合、JDBCデータ・ソース内にデータベース接続を作成するのにXA JDBCドライバを使用する必要があります。XAドライバが使用できないデータベースの場合、またはXAドライバを使用しないことを選択した場合は、データ・ソース内でグローバル・トランザクションのサポートを有効化する必要があります。また、アプリケーションが、以下の条件に適合する場合も、グローバル・トランザクションのサポートを有効化する必要があります。
トランザクションの管理にWebLogic ServerのEJBコンテナを使用します。
1回のトランザクション中に複数のデータベース更新を含みます。
トランザクション中にデータベース、Java Messaging Service (JMS)など複数のリソースにアクセスします。
複数のサーバー(クラスタリングされた、または、クラスタリングされていない)上で同一のデータ・ソースを使用します。
EJBアーキテクチャでは、データベース処理を行っている複数のEJBが単一のトランザクションの一部として呼び出されるのは、よくあることです。XAがない場合、これを行う唯一の方法は、すべてのトランザクション参加者がまったく同じデータベース接続を使用することです。グローバル・トランザクションを有効化して、「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」のどちらかを選択すると、WebLogic Serverは内部的にJTSドライバを使用して、EJB間で接続を明示的に渡さなくても、すべてのEJBが同じトランザクション・コンテキスト内で確実に同じデータベース接続を使用するようにします。
複数のEJBが1つのトランザクションに参加しており、かつ、データベース接続にXA JDBCドライバを使用しない場合は、以下のオプションを使用してデータ・ソースを構成します。
「グローバル・トランザクションのサポート」を選択
「ロギング・ラスト・リソース」または「2フェーズ・コミットのエミュレート」が選択されています
このように構成することによって、同じトランザクション内のすべてのデータベース作業で同じデータベース接続を内部的に使用することがJTSドライバに強制されます。
XA (XAドライバが必須)では、EJBはトランザクションの各部分に対して、別々のデータベース接続を使用できます。WebLogic Serverは、2フェーズ・コミット・プロトコルを使用してトランザクションを調整します。それにより、トランザクションがすべて完了するか、まったく完了しないかであることが保証されます。
WebLogic Serverでは、JDBCデータ・ソースを通じてのロギング・ラスト・リソース(LLR)トランザクションの最適化をサポートしています。LLRは、1つの非XAリソースが、XAと同じACID保証を伴ってグローバル・トランザクションに参加できるようにする、パフォーマンス向上のためのオプションです。LLRは、「最後のエージェントによる最適化」を改良したものです。最後のエージェントによる最適化との相違点は、トランザクションとしては安全であるということです。LLRリソースは、トランザクション処理にローカル・トランザクションを使用します。WebLogic Serverトランザクション・マネージャは、トランザクションの他のすべてのリソースを準備し、その後、LLRリソースのローカル・トランザクションの結果に基づいて、グローバル・トランザクションに対するコミットの決定を下します。
LLRの最適化により、次のようにしてパフォーマンスが向上します。
XA JDBCドライバがデータベースに接続する必要がなくなります。XA JDBCドライバは、一般的に、非XA JDBCドライバに比べて効率が低くなります。
トランザクションを完了させるまでの処理手順の数が少なくなり、それによりネットワーク・トラフィックとディスクI/O数も減少します。
データベース・レベルでのXA処理の必要性がなくなります。
LLR用に構成されたデータ・ソースからの接続が、2フェーズ・コミット(2PC)グローバル・トランザクションに参加している場合、WebLogic Serverトランザクション・マネージャは次の処理によって、トランザクションを完了させます。
他のすべての(XA対応の)トランザクション参加リソースに対するprepareの呼出し。
(ファイル・ベースのトランザクション・ログではなく) LLR参加リソースの表へのコミット・レコードの挿入。
LLR参加リソースのローカル・トランザクション(トランザクション・コミット・レコードの挿入とアプリケーションのSQL処理の双方を含む)のコミット。
その他すべてのトランザクション参加リソースに対するcommitの呼出し。
1フェーズ・コミット(1PC)のグローバル・トランザクションの場合、LLRはローカル・トランザクションを使用してデータベース操作を完了させることによって、XAオーバーヘッドを排除しますが、2PCトランザクション・レコードはデータベースへ書き込まれません。
ロギング・ラスト・リソースの最適化により、LLR参加リソースに対するコミット・レコードが書き込まれ、データの整合性が維持されます。ローカル・トランザクション・コミットの最中にトランザクションが失敗した場合、WebLogic Serverトランザクション・マネージャは、他のすべてのトランザクション参加リソースに対してトランザクションをロールバックします。失敗からリカバリするため、WebLogic Serverトランザクション・マネージャはデフォルトのストアにある他のトランザクション・ログ・ファイルと一緒にLLRリソース上のトランザクション・ログを読み取り、必要なすべてのトランザクション処理を完了させます。XA参加リソースと関連付けられた処理は、コミット・レコードが存在すればコミットされます。そうでなければ、処理はロールバックされます。
LLR対応のJDBCデータ・ソースを作成する方法については、Oracle WebLogic Server管理コンソール・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。ロギング・ラスト・リソース・トランザクション処理の詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。
使用している環境によっては、パフォーマンス上の利点を得るために、トランザクション処理用として、2フェーズ・コミット・プロトコルのかわりにLLRトランザクション・プロトコルを検討する必要があります。LLRトランザクション・プロトコルには、次の利点があります。
非XA JDBCドライバ、そしてXA対応でないデータベースも、2フェーズ・コミット・トランザクションに安全に参加できるようになります。
XAプロトコルがデータベースで使用されなくなります。
JDBC XA接続よりもパフォーマンスが向上します。
データベースの行ロックが保持される時間が短縮されます。
他のXA作業より常に先に、データベース作業をコミットします。XAトランザクションでは、これらの操作は並列にコミットされます。したがって、たとえばJMS送信がトランザクションに参加している場合、JMSメッセージはデータベース処理のコミット前に配信されます。LLRでは、ローカル・トランザクションにおけるデータベース処理は、他のすべてのトランザクション処理より前に完了されます。
JDBCデータ・ソースの「2フェーズ・コミットのエミュレート」オプションと異なり、ヒューリスティック障害のリスクが増大しません。
|
注意: LLR最適化により、挿入、更新、および削除の操作において、著しいパフォーマンスの向上がもたらされます。しかし、LLRでの読取り操作では、XAでの読取り操作と比べて、若干パフォーマンスが低下します。 LLRパフォーマンス・チューニングの詳細は、『Oracle WebLogic Server JTAのプログラミング』のLLRによるパフォーマンス最適化に関する項を参照してください。 |
LLRトランザクション最適化を有効化するには、JDBCデータ・ソースをロギング・ラスト・リソース・トランザクション・プロトコルで作成して、アプリケーション内のデータ・ソースからデータベース接続を使用します。WebLogic Serverは、データベース上に必要な表を自動作成します。
Oracle WebLogic Server管理コンソール・ヘルプのLLR対応のJDBCデータ・ソースの作成に関する項を参照してください。
アプリケーションで、LLRを利用可能なデータ・ソースからのJDBC接続を、その他の任意のデータ・ソースからのJDBC接続と同じように使用します。トランザクションの開始後、JNDIツリーでデータ・ソースをルックアップし、その後データ・ソースからの接続をリクエストします。ただし、LLR最適化が行われていると、WebLogic Serverは接続のリクエストを内部で管理し、トランザクション処理をXAトランザクションとは異なったやり方で扱います。ロギング・ラスト・リソースがどのように機能するかについての詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。
次に注意してください。
LLRデータ・ソースでプログラミングを行う場合は、LLRデータ・ソースに対してgetConnectionを呼び出す前に、グローバル・トランザクションを開始する必要があります。グローバル・トランザクションを開始する前にgetConnectionを呼び出した場合、接続は独立したものとなり、その後で開始されるグローバル・トランザクションに関連付けされません。接続はautoCommit(true)モードで動作します。このモードでは、すべての更新がそのまま自動的にコミットされます。アプリケーション・コードでautoCommitの状態を明示的にfalseに設定して、独自のローカル・トランザクションを明示的に管理しない限り、更新をロールバックする方法はありません。
1つのトランザクションには、1つの内部JDBC LLR接続しか予約されません。その接続が、トランザクション処理全体を通して使用されます。
予約済みの接続は、常にトランザクションのコーディネータ・サーバーにホストされています。データ・ソースのターゲットには、必ずコーディネートしているサーバーまたはクラスタを指定してください。また、『Oracle WebLogic Server JTAのプログラミング』のLLRによるパフォーマンス最適化に関する項を参照してください。
同一名のデータ・ソースからのトランザクションでの追加のJDBC接続リクエストについては、後続の接続リクエストが、データ・ソースの別のインスタンス(つまり、最初のリクエストに対する接続を供給した元のデータ・ソースとは異なるサーバー上にデプロイされているデータ・ソース)に対して行われていたとしても、操作は予約された接続から元の接続リクエストにルーティングされます。次に注意してください。
ルーティングされたLLR接続は、ローカルでホストされているXA接続よりも、機能やパフォーマンスの点で劣ります。(「複数サーバー構成における非XAリソースのパフォーマンス低下の可能性」を参照)。
接続リクエストをルーティングすると、同時トランザクションの数が制限されます。同時LLRトランザクションの最大数は、コーディネータのJDBC LLRデータ・ソースの構成済サイズ(MaxCapacity)と同じです。
ルーティングされた接続は、ローカル接続より機能が低下しており、その結果、失敗する可能性があります。特に、問合せResultSet内のシリアライズできないカスタム・データ型は失敗する可能性があります。
単一LLRデータ・ソースのインスタンスのみが、特定のトランザクションに参加できます。単一LLRデータ・ソースは、複数のWebLogicサーバーに対してインスタンスを持つ場合があり、2つのデータ・ソースは、構成された名前が同じ場合、同一とみなされます。複数のLLRデータ・ソース・インスタンスが検出され、それらが同じデータ・ソースのインスタンスでない場合、トランザクション・マネージャはトランザクションをロールバックします。
weblogic.transaction.nonxa.NonXAResourceインタフェースを実装するリソース・アダプタ(コネクタ)は、LLRリソースもまた参加しているグローバル・トランザクションには参加できません。どちらも、トランザクションの最後のリソースである必要があるからです。双方のリソース・タイプが同じトランザクションに参加している場合、競合が検出されると、トランザクションのcommit()メソッドが、javax.transaction.RollbackExceptionをスローします。
LLR接続では、データベース処理に別個のローカル・トランザクションを使用するため、XA接続を使用して同じデータベースに加えられた変更(および保持されるロック)はすべて、全処理が同じグローバル・トランザクション内で発生するとしても、LLR処理の最中には認識されません。場合によっては、これによりデータベースにデッドロックが発生します。単一のグローバル・トランザクションにおいて、同一データベース内でXA処理とLLR処理を組み合わせることはできません。
LLRデータ・ソースからの接続は、リモート・オブジェクト・リクエスト・ブローカやTuxedoによって開始されたトランザクションなど、外部トランザクション・マネージャが調整するトランザクションには参加できません。
グローバル・トランザクションは、LLRデータ・ソースと同じ名前のデータ・ソースを含む別の従来ドメインまで及ぶようにはできません。
JDBC LLR 2PCトランザクションでは、トランザクション・データがLLR表内に収まるには大きすぎる場合、トランザクションはコミット中にロールバック例外がスローされて失敗します。これが起こり得るのは、アプリケーションがトランザクション処理中に多くのトランザクション・プロパティを追加した場合です。(『Oracle WebLogic Server JTAのプログラミング』のOracle WebLogic JTAの拡張に関する項を参照してください)。これが起こった場合、データベース管理者はより大規模な列を持つ表を手動で作成できます。
LLR対応のJDBCデータ・ソースを構成する際は、次の要件と制限を考慮してください。ロギング・ラスト・リソースがどのように機能するかについての詳細は、『Oracle WebLogic Server JTAのプログラミング』のロギング・ラスト・リソース・トランザクション最適化に関する項を参照してください。
1つのサーバーにつき、LLR表は1つです。
複数のLLRデータ・ソースが1つの表を共有することがあります。
表が見つからない場合、WebLogic Serverは自動的に表を作成します。
デフォルト名はWL_LLR_SERVERNAMEです。表名を構成するには、管理コンソールの詳細オプションの「サーバー」>「構成」>「一般」を選択してください。Oracle WebLogic Server管理コンソール・ヘルプの「サーバー」:「構成」:「一般」を参照してください。
データベースが停止している場合や、起動中にLLR表にアクセスできない場合、サーバーは起動しません。
複数のサーバーが同じLLR表を共有することは許されません。起動の際には、ドメインおよびサーバーの名前が、作成された時点の表に格納されたドメインおよびサーバーの名前と一致するかどうかが確認されます。WebLogic Serverは、複数のサーバーが同じLLR表を共有していることを検出すると、1つまたは複数のサーバーを停止します。
LLRでは、サーバー移行およびトランザクション・リカバリ・サービス移行がサポートされます。トランザクション・リカバリ・サービス移行を使用するには、各LLRリソースが、クラスタまたはクラスタ内の候補サーバーのセットに対してターゲット指定されている必要があります。『Oracle WebLogic Server JTAのプログラミング』の失敗したクラスタ化サーバーのトランザクションのリカバリに関する項を参照してください。
LLRトランザクション・オプションは、JDBCアプリケーション・モジュールでは使用できません。
マルチ・データ・ソースを使用する場合は、LLRトランザクション・オプションはOracle RACバージョン10Gリリース2 (10GR2)以降で、次の設定でのみ使用できます。
すべてのWebLogicアプリケーション・データベースのJDBCの対話でREAD_COMMITTEDトランザクション分離レベル(デフォルト)を使用する必要があります。
Oracle RACのMAX_COMMIT_PROPAGATION_DELAYの値は0 (デフォルト)に設定する必要があります。
マルチ・データ・ソースでのLLRの使用はOracle RACでのみサポートされます。それ以外のマルチ・データ・ソース構成ではLLRはサポートされません。
LLRデータ・ソース上で資格証明マッピングを使用する場合、マップされるユーザーはすべて、LLR表への書込み権限を持っている必要があります。
JDBC XAドライバを使用して、JDBC LLRデータ・ソース内にデータベース接続を作成することはできません。JDBC LLRデータ・ソースで使用されるJDBCドライバがXAをサポートしている場合、警告メッセージがログに記録され、データ・ソースはLLRリソースではなく、完全なXAリソースとして、トランザクションに参加します。
LLRリソース用トランザクション統計は、「NonXAResource」の下に記録されます。Oracle WebLogic Server管理コンソール・ヘルプの非XAリソース用トランザクション統計の表示に関する項を参照してください。
Sybase DBMSでLLRを使用する場合、SybaseのJDBCドライバでは、標準のJDBCメタデータ・メソッドを実装するために、特定のJDBCストアド・プロシージャをDBMSにインストールする必要があります。詳細は、Sybase jConnectのドキュメントを参照してください。
JDBCデータ・ソースで分散トランザクションのサポートが必要であるにもかかわらず、DBMSで利用できるXA対応のドライバがない場合は、データ・ソースに対して非XAドライバ用の2フェーズ・コミットのエミュレートオプションを選択することにより、データ・ソースからの接続が参加しているトランザクションについて、データ・ソースが2フェーズ・コミットをエミュレートするようになります。このオプションは、データ・ソース構成の「構成」>「全般」タブの詳細オプションです。
「2フェーズ・コミットのエミュレート」が選択されている(EnableTwoPhaseCommitがtrueに設定されている)場合、非XA JDBCリソースはXAResource.prepare()メソッド呼出し中に常にXA_OKを返します。リソースは、後続のXAResource.commit()またはXAResource.rollback()の呼出しに応答して、ローカル・トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティック失敗の結果、アプリケーション・データは矛盾した状態のまま残される場合があります。
「2フェーズ・コミットのエミュレート」オプションが管理コンソールで選択されていない(EnableTwoPhaseCommitがfalseに設定されている)場合、非XA JDBCリソースにより、XAResource.prepare()が失敗します。トランザクションに参加するリソースが1つだけの場合、1フェーズの最適化がXAResource.prepare()をバイパスし、トランザクションはほとんどのインスタンスで正常にコミットされます。
|
注意: 「非XAドライバ用の2フェーズ・コミットのエミュレート」オプションを使用していると、データの整合性が損なわれるおそれがあります。「2フェーズ・コミットのエミュレート」オプションを使用するかわりに、XA対応のJDBCドライバ、または「ロギング・ラスト・リソース」オプションを使用することをお薦めします。このオプションを有効にする前に、必ず以下のリスクを考慮してください。 |
この非XAのJDBCドライバのサポートは、WebLogic Serverがその機能をサポートするために内部的にWebLogic JTSドライバを使用するので、多くの場合、「JTSドライバ」と呼ばれます。WebLogic JTSドライバの詳細は、『Oracle WebLogic Server JDBCのプログラミング』のWebLogic JTSドライバの使用に関する項を参照してください。
WebLogic Serverでは、「2フェーズ・コミットのエミュレート」データ・ソース・トランザクション・オプションで非XA JDBCリソースのグローバル・トランザクションへの参加をサポートしていますが、このリソースを使用するためにアプリケーションを設計する際に考慮すべき制限事項があります。非XAドライバはXA/2PCに従わず、1フェーズのコミットおよびロールバック処理のみをサポートするため、WebLogic Serverは(JTSドライバを介して)、トランザクション・マネージャによって制御されるトランザクションにリソースが参加できるように、譲歩する必要があります。
「2フェーズ・コミットのエミュレート」オプションを使用する前に、以下の制限およびリスクを考慮してください。
非XAリソースで2フェーズ・コミットのエミュレートを選択する場合(enableTwoPhaseCommit = true)、非XAリソースに対するトランザクションの準備フェーズは常に成功します。したがって、非XAリソースは2フェーズ・コミット(2PC)プロトコルに実際には参加していないため、失敗しやすくなります。準備フェーズ後に非XAリソースで失敗が発生した場合、XAトランザクションの参加コンポーネントがトランザクションをコミットする一方で、非XAリソースはトランザクションをロールバックする可能性があり、ヒューリスティックな終了とデータの矛盾を招きます。
データの整合性が失われるおそれがあるため、2フェーズ・コミットのエミュレートのオプションは、ヒューリスティックな状況に耐えられるアプリケーションでのみ使用してください。
非XAドライバはローカル・データベースのトランザクションのみを操作するため、外部トランザクション・マネージャに関して、トランザクションがデータベース内で保留中の状態にあるという概念はありません。非XAリソースのXAResource.recover()が呼び出されると、コミットまたはロールバックする必要のあるトランザクションが存在する場合でも、常にXid (トランザクションID)の空のセットが返されます。そのため、グローバル・トランザクションで非XAリソースを使用するアプリケーションは、システムの障害から回復してデータの整合性を維持することができません。
WebLogic Serverは特定のJDBC接続に関連付けられたデータベース・ローカル・トランザクションに依存して、非XAリソースのグローバル・トランザクションへの参加をサポートしているため、同じJDBCデータ・ソースが、複数のWebLogic Serverインスタンス上にグローバル・トランザクション・コンテキストを持つアプリケーションからアクセスされる場合、JTSドライバは常に、トランザクション内のアプリケーションによって確立される最初の接続にJDBCの処理をルーティングします。たとえば、あるサーバーでアプリケーションがトランザクションを開始して非XA JDBCリソースにアクセスし、別のサーバーにRMI (Remote Method Invocation)呼出しを行って、同じ基底のJDBCドライバを使用するデータ・ソースにアクセスすると、JTSドライバは、そのリソースには別のサーバー上のトランザクションに関連付けられた接続があることを認識して、RMIのリダイレクトを最初のサーバーの実際の接続に設定します。接続に対するすべての操作は、最初のサーバーで確立された1つの接続上で行われます。この動作では、リモート接続を設定してRMI呼出しを物理的な接続に対して行うことに関するオーバーヘッドが生じるため、パフォーマンスが低下する可能性があります。
