| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1) E70015-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1) E70015-01 |
|
前 |
次 |
この章では、WebLogicデータ・ソースのXA、非XAおよびグローバル・トランザクション・オプションについて説明します。
WebLogic Server管理コンソールを使用して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アプリケーションの開発』のJTAのOracle WebLogic拡張機能に関する項を参照してください。)これが発生した場合、データベース管理者は、より大規模な列を持つ表を手動で作成できます。
LLR対応のJDBCデータ・ソースを構成する場合、次の要件と制限を考慮してください。ロギング・ラスト・リソースの処理方法の詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のロギング・ラスト・リソース・トランザクションの最適化に関する項を参照してください。
1つのサーバーにつき、LLR表は1つです。
複数のLLRデータ・ソースが1つの表を共有することがあります。
表が見つからない場合、WebLogic Serverは自動的に表を作成します。
デフォルト名はWL_LLR_SERVERNAMEです。表名を構成するには、WebLogic Server管理コンソールの「詳細」オプションの「サーバー」→「構成」→「一般」タブを選択してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: 一般に関する項を参照してください。
データベースが停止している場合や、起動中にLLR表にアクセスできない場合、サーバーは起動しません。
複数のサーバーが同じLLR表を共有することは許可されません。起動の際には、ドメインおよびサーバーの名前が、作成された時点の表に格納されたドメインおよびサーバーの名前と一致するかどうか確認されます。WebLogic Serverは、複数のサーバーが同じLLR表を共有していることを検出すると、1つまたは複数のサーバーを停止します。
LLRでは、サーバー移行およびトランザクション・リカバリ・サービス移行がサポートされます。トランザクション・リカバリ・サービス移行を使用するには、各LLRリソースが、クラスタまたはクラスタ内の候補サーバーのセットに対してターゲット指定されている必要があります。『Oracle WebLogic Server JTAアプリケーションの開発』の失敗したクラスタ化サーバーのトランザクションのリカバリに関する項を参照してください。
LLRトランザクション・オプションは、JDBCアプリケーション・モジュールでは使用できません。
LLRでマルチ・データ・ソースを使用する場合、メンバーは、すべて同じデータベースのレプリケートされたコピーである必要があります。レプリケーションは、単一のOracle RACクラスタ、Data GuardまたはGolden Gateの複数のインスタンスを使用するなど、Oracleテクノロジを使用して実行できます。Oracle RACを使用する場合は、LLRトランザクション・オプションはOracle RACバージョン10gリリース2 (10gR2)以降で、次の設定でのみ使用できます。
すべてのWebLogicアプリケーション・データベースのJDBCの対話で、READ_COMMITTEDトランザクション分離レベル(デフォルト)を使用する必要があります。
Oracle RACのMAX_COMMIT_PROPAGATION_DELAYの値は0(ゼロ、デフォルト)に設定する必要があります。
マルチ・データ・ソースでのLLRの使用は、Oracle RACでのみサポートされます。マルチ・データ・ソースのメンバーは、すべてLLRデータ・ソースであるか、すべてそれ以外である必要があります。
Oracle RACを使用する場合、サーバーの起動時またはサーバーの起動失敗時に、MDSの1つ以上のメンバーがリカバリ処理に使用できる必要があります。
Oracle RACを使用しない場合、サーバーの起動時またはサーバーの起動失敗時に、MDSのすべてのメンバーがリカバリ処理に使用できる必要があります
LLRデータ・ソース上で資格証明マッピングまたはIDプールを使用する場合、マップされるユーザーはすべて、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フェーズ・コミットをエミュレートするようになります。このオプションは、データ・ソース構成の「構成」→「一般」タブの詳細オプションです。
「非XAドライバの2フェーズ・コミットのエミュレート」オプションが選択されている場合(EnableTwoPhaseCommitがtrueに設定されている場合)、非XA JDBCリソースはXAResource.prepare()メソッドのコール中に常にXA_OKを返します。リソースは、後続のXAResource.commit()またはXAResource.rollback()コールに応答して、ローカル・トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティックな障害の結果、アプリケーション・データは矛盾した状態のままになる場合があります。
コンソールで「非XAドライバ用の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ドライバを介して)、トランザクション・マネージャによって制御されるトランザクションにリソースが参加できるように、譲歩する必要があります。
「非XAドライバ用の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呼出しを物理的な接続に対して行うことに関するオーバーヘッドが生じるため、パフォーマンスが低下する可能性があります。
非XA接続では、接続のクローズ時に自動コミットがfalseの状態にあれば、setAutoCommit(true)がコールされます。JDBCの仕様に従えば、これにより未処理のローカル・トランザクションはすべて自動的にコミットされます。一部のドライバ(Oracle 10.xおよび11.xのドライバ)では、ローカル・トランザクションがコミットされません。アプリケーションによって、接続のクローズ前にローカル・トランザクションが完了(コミットまたはロールバック)されていない場合、接続は未処理作業とともにプールに返され、未処理作業は完了することがないか、その接続の次回予約によってコミットまたはロールバックされる可能性があります。これを防ぐために、WebLogicデータ・ソースでは、接続がプールに返される際にコミットがコールされます(Oracle 10.xまたは11.xドライバで実行されている場合)。クローズ時に明示的なコミットが必要な場合、システム・プロパティweblogic.datasource.endLocalTxOnNonXaConWithCommit=trueを設定します。
クローズ時にコミットするのではなく、中止したローカル・トランザクションをロールバックすることもできます。次のプロパティを設定すると、ローカル・トランザクションを中止した場合にコミットではなくそれをロールバックできます。
-Dweblogic.datasource.endLocalTxOnNonXaConWithCommit=false -Dweblogic.datasource.endLocalTxOnNonXaConWithRollback=true
|
注意: 中止したトランザクションをそのままにしておくことは、プログラミング上適切ではありません。アプリケーションでローカル・トランザクションを明示的にコミットまたはロールバックすることをお薦めします。 |
XA接続では、WebLogicデータ・ソースによって、接続のクローズ時にローカル・トランザクションが常にロールバックされます。システム・プロパティweblogic.datasource.endLocalTxOnXaConWithCommit=trueを設定することで、トランザクションをロールバックするかわりにコミットできます。
