| Oracle® Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55546-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理 11g リリース 1 (10.3.1) B55546-01 |
|
戻る |
次へ |
この節の内容は、以下のとおりです。
WebLogic Server でデータベース接続をコンフィグレーションするには、データ ソースを WebLogic ドメインに追加します。WebLogic JDBC データ ソースを使うと、データベースにアクセスし、データベース接続を管理できます。各データ ソースには、データ ソース作成時およびサーバ起動時に作成される、データベース接続のプールが含まれています。アプリケーションは、JNDI ツリーまたはローカル アプリケーション コンテキストでデータ ソースをルックアップし、その後 getConnection() を呼び出すことで、データ ソースからのデータベース接続を予約します。接続を使い終わったら、アプリケーションはできるだけ早くに connection.close() を呼び出す必要があります。それにより、データベース接続はプールに戻され、他のアプリケーションで使用できるようになります。
データ ソースおよびその接続プールは、システムの安定稼動を維持するための接続管理プロセスを備えています。データ ソースのこれらのオプションは、アプリケーションや環境に合わせて設定できます。以下の節では、それらのオプションと、それらを有効にする方法について説明します。
WebLogic ドメインに JDBC データ ソースを作成するには、Administration Console または WebLogic Scripting Tool (WLST) を使用できます。詳細については、以下を参照してください。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの作成」
サンプルの WLST スクリプトは SAMPLES_HOME\server\examples\src\examples\wlst\online\jdbc_data_source_creation.py にあります。SAMPLES_HOME は、WebLogic Server のメインのサンプル ディレクトリを表します。『Oracle Fusion Middleware Oracle WebLogic Scripting Tool ガイド』の「WLST オンライン サンプル スクリプト」を参照してください。
|
注意 : weblogic.Admin コマンドライン ユーティリティは、WLST に置き換えられました。任意指定で WebLogic Server と一緒にインストールされる WebLogic Server サンプルには、weblogic.Admin JDBC コマンドの代わりに使用できるサンプル スクリプトが含まれています。インストールした場合、サンプル スクリプトはWL_HOME\samples\server\examples\src\examples\wlst\online にあります。WL_HOME は、メインの WebLogic ディレクトリ (C:\Oracle\Middleware\wlserver_10.3 など) です。 |
JDBC データ ソース属性の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCDataSourceBean」およびそのすべての子 MBean を参照してください。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの JDBC データ ソース リファレンスのページ :
「JDBC データ ソース : セキュリティ : 資格マッピング」
|
注意 : Administration Console の JDBC データ ソース作成ページにリストされている JDBC ドライバは、必ずしも WebLogic Server で使用されるものとして認定されているわけではありません。JDBC データ ソース ページの主旨に沿って、使用可能な多くのデータベース管理システムへの接続を簡単に作成できるように JDBC ドライバの一覧が表示されます。データ ソースで JDBC ドライバを使用してデータベース接続を作成するには、データ ソースをデプロイする各サーバに JDBC ドライバをインストールする必要があります。ドライバは、Administration Console の JDBC データ ソース作成ページに、データ ソースのコンフィグレーションに役立つ、既知の必要なコンフィグレーション オプションと一緒に一覧表示されています。一覧にある JDBC ドライバが必ずしもインストールされているとは限りません。ドライバのインストールでは、システム パス、クラスパス、その他の環境変数の設定を行う場合もあります。「Type 4 サードパーティ JDBC ドライバに対する環境設定」を参照してください。 JDBC ドライバを更新すると、コンフィグレーションの要件が変わる場合があります。Administration Console の JDBC データ ソース作成ページでは、WebLogic Server ソフトウェアがリリースされた時点で知られていたコンフィグレーション要件を使用します。JDBC ドライバのコンフィグレーション オプションが変更されていると、データ ソース作成時、またはデータ ソース作成後にそのプロパティ ページで、コンフィグレーション オプションを手動でオーバーライドすることが必要な場合があります。 |
JDBC データ ソースには、データ ソースの ID、データベース接続でのデータの扱われ方、およびデータ ソースからの接続がグローバル トランザクションで使用される場合のトランザクションの扱われ方を決定するオプションがあります。JDBC データ ソースの全般的なオプションは、Oracle Fusion Middleware Oracle WebLogic Server Administratin Console の [JDBC データ ソース : コンフィグレーション : 全般] ページで参照できます。また、これらのオプションには、JDBCDataSourceBean の子である JDBCDataSourceParamsBean からもアクセスできます。
データベースへの接続に使用する JDBC ドライバを決定する際には、環境内でさまざまなベンダのドライバを試してみることが必要です。通常、JDBC ドライバのパフォーマンスは、アプリケーションで使用する SQL コード、JDBC ドライバの実装など、さまざまな要因によって左右されます。
サポートされる JDBC ドライバの詳細については、「System Requirements and Supported Platforms for Oracle WebLogic Server」の「Supported Database Configurations」(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html) を参照してください。
JDBC データ ソース名は、WebLogic ドメイン内でデータ ソースを識別するために使用されます。システム リソース データ ソースの場合、名前は他のすべての JDBC システム リソース (データ ソースとマルチ データ ソースを含む) に渡ってユニークなものとする必要があります。名前の競合を避けるため、データ ソース名はサーバ、クラスタ、JMS キュー、JMS トピック、JMS サーバなど、他のコンフィグレーション オブジェクト名にまたがってもユニークであることが必要です。アプリケーションをスコープ指定した JDBC アプリケーション モジュールの場合、データ ソース名は同様にスコープ指定された JDBC データ ソースとマルチ データ ソースに渡ってユニークなものとする必要があります。
WebLogic Server 9.0 以降のリリースでは、データ ソースをコンフィグレーションできます。そのため、データ ソースは複数の名前で JNDI ツリーにバインドされることになります。1 つの JDBC 接続プールを指す複数のデータ ソースを含む従来のコンフィグレーションの代わりに、複数の JNDI 名を持つデータ ソースを使用できます。
Administration Console を使用して JNDI 名を既存のデータ ソースに追加するには、各 JNDI 名を別々の行に入れて JNDI 名属性に名前を追加します。変更を行った後にシステムを再起動するか、または変更を行う前にデータ ソースをアンデプロイし、変更を行った後に再デプロイする必要があります。次の手順に従います。
Administration Console の [JDBC データ ソース｜コンフィグレーション｜全般] ページの [JNDI 名] に、データ ソースを JNDI ツリーにバインドするのに使用する名前を、名前ごとに改行して入力します。次に例を示します。
name1 name2 name3
[保存] をクリックします。
変更をアクティベートした後、データ ソースを再デプロイするか、サーバを再起動しないと、変更は有効になりません。
Administration Console を使用して 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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「LLR を利用可能な JDBC データ ソースの作成」を参照してください。ロギング ラスト リソース トランザクション処理の詳細については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「LLR でのパフォーマンス最適化」を参照してください。 |
LLR トランザクションの最適化を有効化するには、JDBC データ ソースをロギング ラスト リソース トランザクション プロトコルで作成して、アプリケーション内のデータ ソースからデータベース接続を使用します。WebLogic Server は、データベース上に必要なテーブルを自動作成します。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「LLR を利用可能な JDBC データ ソースの作成」を参照してください。
アプリケーションで、LLR を利用可能なデータ ソースからの JDBC 接続を、その他の任意のデータ ソースからの JDBC 接続と同じように使用します。トランザクションの開始後、JNDI ツリーでデータ ソースをルックアップし、その後データ ソースからの接続を要求します。ただし、LLR 最適化が行われていると、WebLogic Server は接続の要求を内部で管理し、トランザクション処理を XA トランザクションとは異なったやり方で扱います。ロギング ラスト リソースのしくみの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」を参照してください。
以下の点に注意してください。
LLR データ ソースでプログラミングを行う場合は、LLR データ ソースに対して getConnection を呼び出す前に、グローバル トランザクションを開始する必要があります。グローバル トランザクションを開始する前に getConnection を呼び出した場合、接続は独立したものとなり、その後で開始されるグローバル トランザクションに関連付けされません。接続は autoCommit(true) モードで動作します。このモードでは、すべての更新がそのまま自動的にコミットされます。アプリケーション コードで autoCommit の状態を明示的に false に設定して、独自のローカル トランザクションを明示的に管理しない限り、更新をロールバックする方法はありません。
1 つのトランザクションには、1 つの内部 JDBC LLR 接続しか予約されません。その接続が、トランザクション処理全体に渡って使用されます。
予約された接続は、常にトランザクションのコーディネータ サーバでホストされます。データ ソースは、必ず調整サーバまたはクラスタに対象指定するようにします。『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「JTA に対する Oracle WebLogic の拡張機能」を参照)。その場合データベース管理者は、より大きなカラムを備えたテーブルを手動で作成できます。
LLR を利用可能な JDBC データ ソースをコンフィグレーションする際には、以下の要件および制限事項を考慮してください。ロギング ラスト リソースのしくみの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「ロギング ラスト リソース トランザクションの最適化」を参照してください。
1 つのサーバにつき、LLR テーブルは 1 つです。
複数の LLR データ ソースが 1 つのテーブルを共有することがあります。
テーブルが見つからない場合、WebLogic Server は自動的にテーブルを作成します。
デフォルトの名前は WL_LLR_SERVERNAME です。テーブル名は、Administration Console の [詳細] オプションの下の [サーバ｜コンフィグレーション｜全般] タブでコンフィグレーションできます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバ : コンフィグレーション : 全般」を参照してください。
データベースが停止している場合や、起動中に LLR テーブルにアクセスできない場合、サーバは起動しません。
複数のサーバで同じ LLR テーブルを共有することはできません。起動の際には、ドメインおよびサーバの名前が、作成された時点のテーブルに格納されたドメインおよびサーバの名前と一致することが確認されます。複数のサーバが同じ LLR テーブルを共有していることを検出すると、WebLogic Server は 1 つまたはそれ以上のサーバを停止します。
LLR は、サーバの移行およびトランザクション回復サービスの移行をサポートします。トランザクション回復サービスの移行を使用するには、クラスタまたはクラスタ内の候補サーバのセットのいずれかに各 LLR リソースが対象指定されていることを確認します。『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「非 XA リソースのトランザクション統計の表示」を参照してください。
JDBC データ ソースで分散トランザクションのサポートが必要なのに、DBMS で利用できる XA 対応のドライバがない場合は、データ ソースに対して [2 フェーズ コミットのエミュレート] オプションを選択できます。これにより、データ ソースからの接続が参加しているトランザクションについて、データ ソースは 2 フェーズ コミットをエミュレートするようになります。このオプションは、[JDBC データ ソース｜コンフィグレーション｜全般] タブの詳細設定オプションです。
[2 フェーズ コミットのエミュレート] が選択されている (EnableTwoPhaseCommit が true に設定されている) 場合、非 XA JDBC リソースは XAResource.prepare() メソッド呼び出し中に常に XA_OK を返します。リソースは、後続の XAResource.commit() または XAResource.rollback() の呼び出しに応答して、ローカル トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティック エラーの結果、アプリケーション データは矛盾した状態のまま残される場合があります。
[2 フェーズ コミットのエミュレート] オプションが Administration Console で選択されていない (EnableTwoPhaseCommit が false に設定されている) 場合、非 XA JDBC リソースにより、XAResource.prepare() が失敗します。トランザクションに参加するリソースが 1 つだけの場合、1 フェーズの最適化が XAResource.prepare() をバイパスし、トランザクションはほとんどのインスタンスで正常にコミットされます。
|
注意 : [2 フェーズ コミットのエミュレート] オプションを使用していると、データの整合性が損なわれるおそれがあります。[2 フェーズ コミットのエミュレート] オプションを使用するのではなく、XA 対応の JDBC ドライバ、または [ロギング ラスト リソース] オプションを使用することをお勧めします。このオプションを有効にする前に、必ず以下のリスクを考慮してください。 |
この非 XA JDBC ドライバのサポートを「JTS ドライバ」と呼ぶこともあります。WebLogic Server では WebLogic JTS ドライバを使用してこの機能をサポートしているためです。JTS ドライバの詳細については、『Oracle Fusion Middleware 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 呼び出しを物理的な接続に対して行うことに関するオーバーヘッドが生じるため、パフォーマンスが低下する可能性があります。
非 XA リソース (2 フェーズ コミットのエミュレートを選択) が WebLogic Server トランザクション マネージャに登録される場合は、XAResource インタフェースを実装するクラスの名前と共に登録されます。2 フェーズ コミットのエミュレートを選択したすべての非 XA リソースは XAResource インタフェースに対する JTS ドライバを使用するため、グローバル トランザクションに参加する (2 フェーズ コミットのエミュレートを選択した) すべての非 XA リソースは、同じ名前で登録されます。グローバル トランザクションで複数の非 XA リソースを使用する場合、名前の衝突やヒューリスティックな終了が起きる可能性があります。
各 JDBC データ ソースには、データ ソースのデプロイ時またはサーバ起動時に作成される、JDBC 接続のプールが含まれています。アプリケーションは、プールから接続を使用し、使用し終わると、プールに戻します。接続のプールにより、アプリケーション用にデータベース接続を作成するという費用のかかるタスクがなくなるため、パフォーマンスが向上します。
以下の節では、JDBC データ ソースの接続プールのオプションについて説明します。
以下で、これらのオプションおよびその他の関連オプションの詳細を参照し、設定できます。
Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソース : コンフィグレーション : 接続プール」を参照してください。
JDBCDataSourceBean の子 MBean である、JDBCConnectionPoolParamsBean
Administration Console を使用して JDBC データ ソースを作成する際、JDBC ドライバ クラスを選択するよう求められます。Administration Console では大部分の一般的なドライバ クラス名が表示され、ほとんどの場合、ドライバに必要な URL の作成も支援されます。ただし、コンソールに URL のテストを要求する前に、URL が適切であることを確認してください。選択したドライバは、データ ソースをデプロイするすべてのサーバのクラスパスに入っている必要があります。ただし、Administration Console で一覧表示されるすべての JDBC ドライバが WebLogic Server に付属している (または、クラスパスに既に含まれている) わけではありません。
Oracle Thin Driver
Oracle Thin Driver XA
Oracle Thin Driver 非 XA
サードパーティの JDBC ドライバ (「WebLogic Server での JDBC ドライバの使い方」を参照) :
Sybase jConnect
PointBase
MySQL (非 XA)
以下のデータベース管理システム用の DataDirect の WebLogic Type 4 JDBC ドライバ (『Oracle Fusion Middleware Oracle WebLogic Server Type 4 JDBC ドライバ ガイド』を参照) :
DB2
Informix
Microsoft SQL Server
Sybase
これらのドライバはすべて、weblogic.jar マニフェスト ファイルによって参照され、サーバのクラスパスで明示的に定義される必要はありません。
WebLogic JDBC データ ソースは、JDBC ドライバで実装される javax.sql.ConnectionPoolDataSource インタフェースをサポートしています。JDBC データ ソース内の Properties 属性にプロパティおよびその値を追加して、ドライバ レベルの機能を有効化できます。Properties 属性におけるドライバ レベルのプロパティは、ドライバの ConnectionPoolDataSource オブジェクトで設定されます。
WebLogic Server では、データ ソースにおけるデータベース接続の作成時に、自動的に SQL コードを実行して、データベース接続を初期化できます。この機能を有効にするには、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページの [初期化 SQL] 属性に「SQL」と入力し、その直後にスペース、次に実行する SQL コードを入力します。この属性を空白のままにしておくと (デフォルト)、データベース接続を初期化するコードは実行されません。
サーバの起動時、接続プールの拡張時、接続の更新時など、データ ソースにおけるデータベース接続の作成時には常にここで指定したコードが実行されます。
この機能を使って、接続ごとの DBMS 固有の動作を設定したり、要求されたアクションを実行できるメモリやパーミッションを接続が備えているかを確認したりできます。
コードは、「SQL」で開始し、その後にスペースを入れます。次に例を示します。
SQL alter session set NLS_DATE_FORMAT='YYYY-MM-DD HH24:MI:SS'
または
SQL SET LOCK MODE TO WAIT
InitSQL によって設定できるオプションは、DBMS ごとに異なります。
|
注意 : Init SQL は、動的な属性ではありません。Init SQL の値を変更する際には、データ ソースをアンデプロイしてから再デプロイするか、またはサーバを再起動する必要があります。 |
以下の節では、セキュリティ資格を DBMS に渡す方法についての情報を提供します。
Weblogic Server では、セキュリティ権限に基づいて、次の 2 種類のデータ ソース プールが提供されます。
同種 - アプリケーションのエンド ユーザに関係なく、プール内のすべての接続で同じセキュリティ資格を使用して DBMS にアクセスする。
異種 - アプリケーションは、別の DBMS 資格で物理的な接続をプールすることによって、特定の DBMS 資格で JDBC 接続を使用できる。
ここでは、セキュリティ資格を DBMS に渡す方法を比較します。
資格を渡すための最も単純な方法は、DBMS のユーザ アカウント名とパスワードを接続プールに提供する方法です。この場合、プール内のすべての接続で同じ資格を使用して DBMS にアクセスします。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの作成」を参照してください。
|
注意 : パスワードは [プロパティ] フィールド (プロダクション環境では不可) に名前と値の組み合わせとして入力することも、[パスワード] フィールドに入力することも可能です。[パスワード] フィールドの値は、物理的なデータベース接続を作成するときに JDBC ドライバに渡される Properties で定義されている、いかなる password 値をもオーバーライドします。プロパティ文字列でパスワード プロパティの代わりに Password 属性を使用することをお勧めします。なぜなら、Password 値はコンフィグレーション ファイル内で暗号化 (モジュール ファイルの jdbc-driver-params タグで password-encrypted 属性として保存) され、Administration Console では表示されなくなるからです。 |
データ ソースで [接続時にクライアント ID を設定] 属性が有効になっている場合は、アプリケーションによってデータ ソースのデータベース接続が要求されたときに、WebLogic Server インスタンスが現在の WebLogic ユーザ ID を判別し、マップされているデータベース ID を軽量なクライアント ID として設定します。この場合も、プール内のすべての接続で同じ資格を使用して DBMS にアクセスします。基本的なコンフィグレーション手順は次のとおりです。
[接続時にクライアント ID を設定] を選択します。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースに対する [接続時にクライアント ID を設定] の有効化」を参照してください。
WebLogic ユーザ ID をデータベース ID にマップします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの資格マッピングのコンフィグレーション」を参照してください。
この機能は、JDBC ドライバおよび DBMS の機能に依存します。Oracle および DB2 データベースで、ベンダ提供の拡張メソッドを使用する場合にのみサポートされます。
oracle.jdbc.OracleConnection.setClientIdentifier(String id)
com.ibm.db2.jcc.DB2Connection.setDB2ClientUser(String user)
|
注意 : [接続時にクライアント ID を設定] と [ID ベースの接続プールを有効化] は相互に排他的です。アプリケーション環境でセキュリティ資格を渡すために両方のメカニズムが必要な場合は、別々のデータ ソースを作成して、一方は [接続時にクライアント ID を設定] を指定し、もう一方は [ID ベースの接続プールを有効化] を指定してください。 |
ID ベースの接続プールを使用すると、アプリケーションごとに異なる DBMS 資格で物理的な接続をプールすることによって、特定の DBMS 資格で JDBC 接続を使用できます。
データ ソースで [ID ベースの接続プールを有効化] 属性が有効になっている場合は、アプリケーションによってデータ ソースのデータベース接続が要求されたときに、WebLogic Server インスタンスは既存の物理的接続を選択するか、または WebLogic ユーザの資格および DBMS 資格のマップに基づき、要求された DBMS ID との新しい物理的接続を作成します。基本的なコンフィグレーション手順は次のとおりです。
[ID ベースの接続プールを有効化] を選択します。詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの ID ベースの接続プールの有効化」を参照してください。
WebLogic ユーザ資格と DBMS 資格をマップします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの資格マッピングのコンフィグレーション」を参照してください。
|
注意 : [接続時にクライアント ID を設定] と [ID ベースの接続プールを有効化] は相互に排他的です。アプリケーション環境でセキュリティ資格を渡すために両方のメカニズムが必要な場合は、別々のデータ ソースを作成して、一方は [接続時にクライアント ID を設定] を指定し、もう一方は [ID ベースの接続プールを有効化] を指定してください。 |
次に、異種接続が作成されるプロセスについて説明します。
接続プールの初期化時に、データ ソースのデフォルト DBMS 資格で物理的な JDBC 接続が作成されます。
アプリケーションは、データ ソースからの接続の取得を試行します。
現在のサーバ インスタンス資格が、DBMS 資格にマッピングされます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの資格マッピングのコンフィグレーション」を参照してください。
一致する資格が見つからない場合、デフォルトの DBMS 資格が使用されます。
|
注意 : デフォルトの DBMS 資格は、XA トランザクションを実行したり、接続テスト操作を実行できる最低限の DBMS 権限を持つ必要があります。 |
一致する資格が見つかった場合、DBMS 資格に一致する物理的な接続の検出にその資格が使用されます。
一致する接続が見つかった場合、その接続が予約されてアプリケーションに返されます。
一致する接続が見つからない場合、プールの最大容量に基づいて 1 つの接続が作成されるか、再利用されます。
最大容量にまだ達していない場合、DBMS 資格で新しい接続が作成され、予約されてから、アプリケーションに返されます。
プールが最大容量に達している場合、最長時間未使用 (LRU) アルゴリズムに基づいて、物理的な接続がプールから選択され、破棄されます。DBMS 資格で新しい接続が作成され、予約されてから、アプリケーションに返されます。
物理的な接続がどのように作成されるかに関係なく、プール内の物理的な各接続は、プールによって維持される独自の DBMS 資格情報を持ちます。物理的な接続がプールによっていったん予約されると、現在のスレッドが WebLogic ユーザの資格を変更しても、その DBMS 資格は変更されず、同じ接続が使い続けられます。
グローバル トランザクションの中で実行される場合、アプリケーションは現在のスレッド上の資格を変更して、別の資格に基づき複数の JDBC 接続を取得することができます。ただし、ID ベースのプール機能では、グローバル トランザクションの中での WebLogic JDBC データ ソースの複数の論理 JDBC 接続を、単一の物理 JDBC 接続にマップします。つまり、WebLogic サーバ インスタンスに対する 1 つの WebLogic JDBC データ ソースにつき、ただ 1 つの DBMS 資格のみが、グローバル トランザクションについて尊重されるということです。
ID ベースのプールにおいてロギング ラスト リソース (LLR) トランザクションの最適化を利用するには、以下の変更を行う必要があります。
完全修飾 LLR テーブル名を使用して、LLR のカスタム スキーマをコンフィグレーションすることが必要。これで、すべての LLR 接続が、LLR トランザクション テーブルへのアクセス時に、デフォルトのスキーマではなく指定されたスキーマを使用します。
データベース固有の管理ツールを使用して、指定された LLR テーブルへのアクセス許可を、すべてのユーザに付与。デフォルトでは、LLR テーブルはデータ ソース内で接続に対してコンフィグレーションされたユーザによって、起動の際に作成されます。大半の場合、データベースはこのユーザに対してのみアクセスを許可し、マップされたユーザには許可しません。
WebLogic Server ドメインの JDBC データ ソース内の接続プール属性を正しくコンフィグレーションすることで、アプリケーションおよびシステムのパフォーマンスを向上させることができます。以下の節では、JDBC データ ソースの接続プールのチューニング オプションについて説明します。
アプリケーションまたは EJB でプリペアド ステートメントや呼び出し可能ステートメントを使用すると、アプリケーション サーバとデータベース サーバの間の通信およびデータベース サーバ自体においてかなりの処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WebLogic Server ではアプリケーションで使用するプリペアド ステートメントおよび呼び出し可能ステートメントをキャッシュできます。アプリケーションまたは EJB が、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Server はキャッシュ内に格納されている文を再利用します。プリペアド ステートメントや呼び出し可能ステートメントを再利用することで、データベース サーバの CPU の使用率が下がり、現在のステートメントのパフォーマンスが向上するため、CPU サイクルを他のタスクに割り当てることができます。
データ ソースの各接続には、接続に使用するプリペアド ステートメントおよび呼び出し可能ステートメントのキャッシュが個別に備わっています。しかし、ステートメント キャッシュのコンフィグレーションは、データ ソースごとに行います。つまり、データ ソース内の各接続のステートメント キャッシュは、そのデータ ソースについて指定されたステートメント キャッシュ オプションを使用しますが、各接続は、独自に文をキャッシュします。ステートメント キャッシュのコンフィグレーション オプションには、次のようなものがあります。
[ステートメント キャッシュの種類] - ステートメント キャッシュ内に格納する文を決定するアルゴリズム。「ステートメント キャッシュのアルゴリズム」を参照してください。
[ステートメント キャッシュ サイズ] - 各接続のキャッシュに格納する文の数。デフォルト値は 10 です。「ステートメント キャッシュのサイズ」を参照してください。
データ ソースのステートメント キャッシュ オプションの設定には、Administration Console を使用できます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC 接続プールのステートメント キャッシュのコンフィグレーション」を参照してください。
ステートメント キャッシュのタイプ (つまりアルゴリズム) は、データ ソースの各接続のキャッシュに格納するプリペアド ステートメントと呼び出し可能ステートメントを決定します。次のオプションから選択できます。
[LRU] (最長時間未使用。デフォルト) をステートメント キャッシュのタイプとして選択すると、WebLogic Server は接続で使用されるプリペアド ステートメントおよび呼び出し可能ステートメントを、ステートメント キャッシュのサイズに到達するまでキャッシュします。アプリケーションが Connection.prepareStatement() を呼び出すと、WebLogic Server はその文がステートメント キャッシュに格納されているかどうかを確認します。格納されていた場合、WebLogic Server はキャッシュされていた文を (それがすでに使用されていなければ) 返します。文がキャッシュ内に存在せず、キャッシュがいっぱい (キャッシュ内の文の数 = ステートメント キャッシュのサイズ) であった場合、WebLogic Server はキャッシュ内の既存の文のうち未使用時間の最も長いものを判断し、キャッシュ内のその文と新しい文を入れ替えます。
WebLogic Server の LRU ステートメント キャッシュ アルゴリズムは、近似 LRU 方式を使用します。
[固定] をステートメント キャッシュのタイプとして選択すると、WebLogic Server は接続で使用されるプリペアド ステートメントおよび呼び出し可能ステートメントを、ステートメント キャッシュのサイズに到達するまでキャッシュします。追加の文が使用された場合、これらはキャッシュされません。
このステートメント キャッシュ アルゴリズムでは、ほとんど使われない文を意図せずキャッシュしてしまうことがあります。多くの場合、LRU アルゴリズムが使用されます。ほとんど使われない文が、キャッシュ内で最終的には頻繁に使われる文に置き換えられるからです。
[ステートメント キャッシュ サイズ] 属性は、データ ソースの各インスタンスの各接続にキャッシュするプリペアド ステートメントと呼び出し可能ステートメントの総数を決定します。文をキャッシュすることで、システムのパフォーマンスが向上します。ただし、DBMS でオープンなプリペアド ステートメントと呼び出し可能ステートメントがどのように処理されるかを考慮する必要があります。多くの場合、DBMS は開いている各文について、カーソルを保持します。これは、ステートメント キャッシュ内のプリペアド ステートメントおよび呼び出し可能ステートメントに対して適用されます。キャッシュされた文の数が多すぎると、データベース サーバ上のオープン カーソル数の上限を超えてしまうことがあります。
たとえば、10 個の接続があるデータ ソースが 2 つのサーバにデプロイされている場合、[ステートメント キャッシュ サイズ] を 10 (デフォルト値) に設定すると、キャッシュされた文に対してデータベース サーバ上で 200 個 (10 x 2 x 10) のカーソルを開く可能性があります。
ステートメント キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。ステートメント キャッシュを使用する場合は、以下の制限に留意してください。
ここに示す以外にも、文のキャッシングに関連した問題が存在する可能性があります。プリペアド ステートメントまたは呼び出し可能ステートメントに関連するシステムでエラーが見つかった場合は、ステートメント キャッシュのサイズを 0 に設定して文のキャッシングをオフにし、問題がプリペアド ステートメントのキャッシングに起因するものかどうかをテストする必要があります。
キャッシュ内に格納されたプリペアド ステートメントは、プリペアド ステートメントのキャッシュ時に特定のデータベース オブジェクトを参照します。キャッシュに格納されたプリペアド ステートメントで参照されるデータベース オブジェクトに対して、何らかの DDL (データ定義言語) 処理を実行すると、それらの文は次に実行したときに失敗する可能性があります。たとえば、select * from emp などの文をキャッシュしてから、emp テーブルを削除して再作成した場合、その文が準備されたときに存在した emp テーブルはなくなるため、キャッシュされた文を次に実行すると、その文は失敗します。
同様に、プリペアド ステートメントは、キャッシュされた時点でデータベース内のテーブルの各カラムのデータ型にバインドされます。テーブルのカラムを追加、削除、または再配列すると、キャッシュに格納されているプリペアド ステートメントは、再び実行されたときに失敗するおそれがあります。
これらの制限は、DBMS の動作に依存します。
setNull バインド変数を使用するプリペアド ステートメントをキャッシュする場合、変数を適切なデータ型に設定する必要があります。次の例で示すような汎用のデータ型を使用すると、null 以外の値で実行したときにデータが切り捨てられたり、文が失敗したりするおそれがあります。
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)// これは正しくない
else
setLong(2,sal)
代わりに、以下を使用します。
if (sal == null) setNull(2,long)// これは正しい else setLong(2,sal)
データ ソース内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Server には、2 種類の基本的なテスト方法があります。
WebLogic Server がデータベース接続の正常な状態を確認できるよう、データ ソースのオプションでコンフィグレーションする、自動テスト。
データ ソースのトラブルシューティング用に行える、手動テスト。
次の節では、自動接続テストのオプションについて説明します。手動接続テストの詳細については、「データ ソースおよびデータベース接続のテスト」を参照してください。
データ ソースの自動テスト オプションをコンフィグレーションするには、JDBCConnectionPoolParamsBean を使用して、Administration Console または WLST から以下のオプションを設定します。
[テスト頻度] - (JDBCConnectionPoolParamsBean の TestFrequencySeconds) この属性では、未使用の接続がテストされる秒間隔を指定します。WebLogic Server は未使用の接続をテストして閉じ、障害のある接続と置き換えます。[テスト対象のテーブル名] も設定しておく必要があります。
[予約時に接続をテスト] - (JDBCConnectionPoolParamsBean の TestConnectionsOnReserve) このオプションを選択すると、各接続はテスト後にクライアントに提供されます。このテストを行うと、要求に対して短い遅延が生じることもありますが、正常な接続の提供が保証されます。[テスト対象のテーブル名] も設定しておく必要があります。
[テスト対象のテーブル名] - (JDBCConnectionPoolParamsBean の TestTableName) この属性では、接続テストで使用されるテーブル名を指定します。標準的なテストの代わりに、テストとして実行する SQL コードを指定することもできます。「SQL」と入力し、その直後にスペース、次に実行する SQL コードを入力します。[テスト対象のテーブル名] は、データベース接続のテストを有効にするための必須の属性です。
[アイドル プール接続を信頼する秒数] - (JDBCConnectionPoolParamsBean の SecondsToTrustAnIdlePoolConnection) このオプションは、接続がアプリケーションに渡される前、または定期的な接続テストの処理中に、その接続がまだ有効であると WebLogic Server が信頼し、接続テストをスキップしてもよいと証明されてからの秒数を指定するのに使用します。これは、特に大量のトラフィックが発生している場合に接続テストがパフォーマンスに及ぼす影響を最小限に抑える最適化オプションです。「アイドル プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。
これらのオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCConnectionPoolParamsBean」を参照してください。
接続テスト オプションを設定する手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースのテスト オプションのコンフィグレーション」を参照してください。
WebLogic Server はデータ ソースのデータベース接続をテストする際、データ ソースからの接続を予約し、接続に対して小さなクエリを実行し、その後データ ソースのプールに接続を戻します。サーバ インスタンスは、プールの状態に関する統計情報 (接続テストの所要時間、接続を待機している接続数、テストされた接続数など) を追跡します。最近実施された接続動作テストの履歴は、接続テストが失敗したとサーバ インスタンスが判断するまでの待機時間を計算するために使用されます。
スレッドの接続に通常よりも時間がかかっている場合、サーバ インスタンスはそのテストが完了するまで、他のスレッドのテストを遅延させる場合があります。接続テスト中 (デフォルトでは 10 秒) のスレッドのハングが長すぎる場合、プールは DBMS の接続エラーを宣言して自身を無効にし、予約されてない接続も、アプリケーションが使用中の接続も、すべての接続を強制終了します。
これは非常にまれなケースですが、ネットワーク ケーブルの切断やその他の問題によって引き起こされる無限のハング状態を緩和することを意図しています。このようなハングに陥ると、ソケット読み取りで JDBC 呼び出しを行っている JVM スレッドがロックされ、OS の TCP 制限 (通常は 10 分間) に達するまで JVM が解除されなくなる可能性があります。この方法で自身を無効化した場合、プールは定期的に (デフォルトでは 5 秒おきに) DBMS に再接続しようとします。新しい接続を作成できた場合、プールは自身を再び有効にして、以降の接続要求は通常通りに処理します (プールは負荷の必要性に応じて再び接続を格納します)。
テストで使用するクエリは、[テスト対象のテーブル名] の値によって決定されます。値がテーブル名の場合、クエリは select 1 from table_name となります。[テスト対象のテーブル名] に、先頭が SQL で直後にスペースとクエリが続く完全なクエリが含まれていれば、WebLogic Server はデータベース接続のテスト時に、そのクエリを使用します。
接続がテストに失敗すると、WebLogic Server は接続を閉じて再作成し、その後、新しい接続をテストします。
接続テストのセマンティクスの詳細については、以下の節で説明しています。
データ ソース内に接続が作成されると、WebLogic Server は [テスト対象のテーブル名] の値で定義されたクエリを使用して、各接続をテストします。接続の作成は、サーバ起動時かデータ ソース作成時にデータ ソースがデプロイされる場合、接続の要求を満たすために容量を増大させる場合、または接続テストに失敗した接続を再作成する場合に、行われます。
このテストの目的は、アプリケーションが接続を要求したときに、必ず新しい有効な接続がすぐに使用できるようにしておくことです。
[テスト頻度] が 0 より大きい場合、WebLogic Server は現在アプリケーションで予約されていないプール済みの接続を定期的にテストします。テストは、[テスト対象のテーブル名] で定義されたクエリに基づいています。接続がテストに失敗した場合、WebLogic Server は接続を閉じ、接続を再作成し、新しい接続をテストしてから、その接続をプールに戻します。
[予約時に接続をテスト] が有効化されている場合、アプリケーションがデータ ソースからの接続を要求すると、WebLogic Server はアプリケーションに渡す前に、その接続を [テスト対象のテーブル名] で指定されたクエリを使用してテストします。
予約済みの接続のテストは、接続リクエストに応じるにあたり遅延を生じさせる可能性がありますが、アプリケーションが接続を取得した時点で、その接続は確実に有効です。[アイドル プール接続を信頼する秒数] をチューニングすることで、予約済みの接続のテストの影響を最小限に抑えることができます。「アイドル プール接続を信頼する秒数の設定による接続リクエスト遅延の最小化」を参照してください。
DBMS への接続がたとえ一瞬でも失われると、通常、データ ソースにおける JDBC 接続の一部またはすべてが切断されます。データ ソースが予約時の接続テストを行うようにコンフィグレーションされている場合、あるアプリケーションによってデータベース接続がリクエストされると、WebLogic Server はその接続をテストし、その接続が切断されていることが分かると、リクエストに応えるため、新しい接続と置き換えようとします。通常、DBMS がオンラインに復帰すると更新プロセスは成功しますが、場合によって (障害の一部のモードにおいては)、切断された接続のテストによって、長時間の遅延を強いられる可能性があります。
この遅延を最小限に抑えるため、WebLogic データ ソースには、何度か連続してテストが失敗すると、データ ソース内のすべての接続を切断されているものと見なして閉じるロジックが含まれています。すべての接続が閉じられた後に、アプリケーションが接続を要求すると、データ ソースは先に切断された接続のテストを行うことなく、接続を作成します。この動作によって、データ ソースの接続プールのフラッシュに続く接続リクエストの遅延が最小化されます。
WebLogic Server は、データ ソースの [テスト頻度] の設定に基づいてすべての接続を閉じるまでのテストの失敗回数を決定します。
[テスト頻度] が 0 より大きければ、すべての接続を閉じるまでのテスト失敗回数は 2 に設定されます。
[テスト頻度] が 0 に設定されている (定期テストが無効化されている) 場合、すべての接続を閉じるまでのテスト失敗回数は、データ ソースの [最大容量] の 25% に設定されます。
DBMS が使用できなくなると、データ ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ ソースが迅速に対処できるため、有効です。ただし、切断されたデータベースをテストすることによって、ネットワークのタイムアウトが生じ、クライアントに長時間の遅延を強いる可能性があります。
この遅延を最小限に抑えるため、WebLogic データ ソースには、2 回連続して失敗が生じたらデータ ソースを無効化して、切断されている接続を置き換えるロジックが含まれています。アプリケーションが、無効化されたデータ ソースから接続をリクエストすると、即座に PoolDisabledSQLException が送出され、接続が使用できないことがクライアントに知らされます。
この方法で無効化されたデータ ソースについては、定期的に更新プロセスが実行されます。更新プロセスでは、次のことが実行されます。
サーバ インスタンスによる、データベース サーバに対する 5 秒ごとのヘルス チェック。この設定はコンフィグレーションできない。
データベースが回復されたことがサーバ インスタンスによって認識された場合の、サーバ インスタンスによる新しいデータベース接続の作成およびデータ ソースの有効化。
また、Administration Console を使用して手動でデータ ソースを有効化することもできます。
DBMS が使用できなくなると、データ ソースは、接続リクエストに応えようとしながら、切断された接続を持続的にテストし、置き換えようとします。この動作は、データベースが使用できるようになった時に、データ ソースが迅速に対処できるため、有効です。ただし、切断された接続をテストして、無駄に置き換えようとすると、OS ネットワーク タイムアウト (数分間) の時間がかかり、予期されるエラー メッセージを取得するまでにクライアントで長時間の遅延を引き起こす可能性があります。
|
注意 : データ ソースをマルチ データ ソースに追加している場合は、マルチ データ ソースがデータ ソースの無効化と再有効化を引き継ぎます。デフォルトでは、マルチ データ ソースは 2 分おきにチェックして (この時間はコンフィグレーション可能)、接続を再確立できるデータ ソースがあれば再有効化します。 |
DBMS 接続を非常に短いサイクルで使用するアプリケーションの場合 (例 : 予約 - クエリを 1 回実行 - 閉じる)、データ ソースの接続のテストは各使用サイクルに大量のオーバーヘッドをもたらす可能性があります。接続テストの影響を最小化するには、JDBC データ ソース コンフィグレーションの [アイドル プール接続を信頼する秒数] 属性を設定して、最近使用またはテストしたデータベース接続を信頼して接続テストをスキップします。
データ ソース上で [予約時に接続をテスト] が有効化されている場合、アプリケーションがデータベース接続をリクエストすると、WebLogic Server はアプリケーションに渡す前にその接続をテストします。接続がテストされるかアプリケーションで正常に使用されてから、[アイドル プール接続を信頼する秒数] に指定した時間内にこのリクエストが送信された場合は、その接続は接続テストなしでアプリケーションに渡されます。
データ ソースに対する [テスト頻度] が 0 より多い (定期テストが有効化されている) 場合も、WebLogic Server は接続が正常に使用されて、[アイドル プール接続を信頼する秒数] で指定した時間内にデータ ソースに戻されていれば、接続テストをスキップします。
[アイドル プール接続を信頼する秒数] を設定する手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースのテスト オプションのコンフィグレーション」を参照してください。
[アイドル プール接続を信頼する秒数] は、特に大量のトラフィックが発生している場合のデータベース接続テストによる遅延を最小化することで、アプリケーションのパフォーマンスを向上させるチューニング機能です。ただし、あまり高い値を設定した場合などには、接続テストの有効性が失われるおそれがあります。どの程度の値が適切かは、使用している環境や、接続が切断される可能性の高さによって異なります。
接続テストの属性は、環境に最もよく適合するように設定する必要があります。たとえば、アプリケーションがデータベース接続の失敗を許容できない場合は、[アイドル プール接続を信頼する秒数] を 0 に設定して確実に [予約時に接続をテスト] を有効化しておき、WebLogic Server が接続をアプリケーションに渡す前に、毎回その接続のテストを行うようにします。アプリケーションがデータ ソースから接続を取得する際の遅延に影響を受けやすく、切断された接続の使用によるアプリケーション エラーの可能性を許容できるのであれば、[アイドル プール接続を信頼する秒数] をより高い数値に、[テスト頻度] を低い数値に設定し、[予約時に接続をテスト] を有効化する必要があります。
これらの設定によりアプリケーションは、アプリケーションが接続を要求したときよりも、プール内の接続が使用されていないときのデータ ソースの接続テストに依存するようになります。
|
注意 : 結局は、WebLogic が最善を尽くした場合でも、WebLogic が接続を正常にテストした後で、アプリケーションがその接続を使用する前に、接続が失敗する可能性はあります。したがって、どのアプリケーションも、切断された接続から予期しない例外が発生した場合に適切に対応するように記述しておく必要があります。 |
Administration Console を使用してデータ ソースを作成する場合、Administration Console は、選択した DBMS に基づき、データ ソースの [テスト対象のテーブル名] 属性を自動的に設定します。[テスト対象のテーブル名] 属性は接続テストで使用されます。接続テストは必要に応じて、テスト オプションのコンフィグレーションにより定期的に、または接続を作成、予約、解放したときに実行されます。データベースのテストを正常に実行するためには、データ ソースのデータベース接続を作成するユーザが、該当するデータベース テーブルにアクセスできる必要があります。アクセスできない場合には、DBMS を使用してそのユーザにアクセスを付与するか、WebLogic Server Administration Console を使用して [テスト対象のテーブル名] 属性をユーザがアクセスを持つテーブルの名前に変更する必要があります。
[テスト対象のテーブル名] はオーバーロードされるパラメータです。最も単純な形式は、WLS が接続のテストを要求するテーブルを指定することです。Oracle の場合の「DUAL」など、任意のテーブルに設定すると、データ ソースは「select count(*) from DUAL」のようなクエリを実行することになります。このモードで使用する場合は、小さく、頻繁には更新されないテーブル (DUAL のような擬似テーブルが望ましい) を選ぶことをお勧めします。
このパラメータを定義するときの 2 番目の方法は、特定の SQL 文字列に接続のテストを実行させることです。この方法を使用するには、パラメータとして、「SQL」 に必要な SQL 文字列を加えたもの設定します。たとえば、SQLServer の場合は「SQL select 1」が機能しますが、この場合、定数を選択するためにクエリ内にテーブルを含める必要はありません。この方法は、WLS のプール接続テストに DBMS 側の制御を加えて、テストをできる限り速く行うには便利です。
表 3-2 DBMS による、デフォルトのテスト対象のテーブル名
| DBMS | デフォルトのテスト対象のテーブル名 (クエリ) |
|---|---|
|
Adabas for z/OS |
SQL call shadow_adabas('select * from employees') |
|
Cloudscape |
SQL SELECT 1 |
|
DB2 |
SQL SELECT COUNT(*) FROM SYSIBM.SYSTABLES |
|
FirstSQL |
SQL SELECT 1 |
|
IMS/TM for z/OS |
SQL call shadow_ims('otm','/dis','cctl') |
|
Informix |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
Microsoft SQL Server |
SQL SELECT 1 |
|
MySQL |
SQL SELECT 1 |
|
Oracle |
SQL SELECT 1 FROM DUAL |
|
PointBase |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
PostgreSQL |
SQL SELECT 1 |
|
Progress |
SQL SELECT COUNT(*) FROM SYSTABLES |
|
Sybase |
SQL SELECT 1 |
WebLogic JDBC データ ソースには、データベースへの接続確立を試行する間隔の秒数を指定するのに使用できる、[接続作成の再試行間隔] オプション (JDBCConnectionPoolParamsBean の ConnectionCreationRetryFrequencySeconds) があります。この値を設定して、データ ソースの作成時にデータベースが使用できない場合、指定した秒数が経過するたびにプール内における接続の作成を再試行し、成功するまで続行します。このオプションは、サーバ起動時にデータ ソースが作成されたとき、データ ソースがデプロイされたとき、または初期容量が増大されたときに作成される、接続に適用されます。プールを拡張したり、プール内の切断された接続を置き換えたりする場合に作成される接続には適用されません。
デフォルトでは、[接続作成の再試行間隔 (秒)] は 0 秒です。この値を 0 に設定すると、接続作成の再試行は無効化され、データベースが使用できなければデータ ソースの作成は失敗します。
このオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCConnectionPoolParamsBean」を参照してください。
JDBC データ ソースには、データ ソースからの接続を待機する接続リクエストを有効化するために設定できる、2 つの属性があります。[接続予約のタイムアウト] (ConnectionReserveTimeoutSeconds) および [接続の最大待機数] (HighestNumWaiters) です。これら 2 つの属性を一緒に使うと、ブロックするスレッドが多すぎるためにシステムが無効になることなく、接続を待機する接続リクエストを有効化できます。
これらのオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCConnectionPoolParamsBean」を参照してください。
また、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「接続要求における接続待機の有効化」も参照してください。
アプリケーションがデータ ソースからの接続を要求したときにデータ ソース内の接続がすべて使用中であり、かつデータ ソースが最大容量まで拡張済みだった場合には、アプリケーションは接続使用不可 SQL 例外を受け取ります。これを避けるために、接続が利用できるようになるまで接続リクエストが待機するよう、[接続予約のタイムアウト] 値 (秒単位) をコンフィグレーションすることができます。[接続予約のタイムアウト] の有効期限が切れた後も、利用可能になった接続がなければ、リクエストは失敗し、アプリケーションは PoolLimitSQLException 例外を受け取ります。
[接続予約のタイムアウト] を -1 に設定すると、利用できる接続がなかった場合、接続リクエストは直ちにタイムアウトします。[接続予約のタイムアウト] を 0 に設定すると、接続リクエストは無期限に待機します。デフォルト値は、10 秒です。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「接続要求における接続待機の有効化」を参照してください。
接続を待機する接続リクエストは、スレッドをブロックします。あまりに多くの接続リクエストが同時に接続を待機してスレッドをブロックすると、システムのパフォーマンスが低下する可能性があります。これを回避するには、[接続の最大待機数] (HighestNumWaiters) 属性を設定して、同時に接続を待機できる接続リクエスト数を制限します。
[接続の最大待機数] (HighestNumWaiters) を MAX-INT (デフォルト) に設定すると、事実上、接続を待機できる接続リクエストに制限はなくなります。[接続の最大待機数] を 0 に設定すると、接続リクエストは接続を待機できなくなります。最大リクエスト数に到達した場合、アプリケーションが接続を要求すると SQLException が送出されます。
リークされた接続とは、適切にデータ ソースの接続プールに返されなかった接続のことです。リークされた接続を自動的に回復するには、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページで [非アクティブ接続タイムアウト] の値を指定します。[非アクティブ接続タイムアウト] に値を指定すると、予約された接続が指定した秒数の間、非アクティブになっている場合、接続が強制的にデータ ソースに返されます。0 (デフォルト値) に設定すると、この機能は無効になります。
このオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCConnectionPoolParamsBean」を参照してください。
実際のタイムアウト時間は、[非アクティブ接続タイムアウト] にコンフィグレーションした値より長くなります。内部のデータ ソース保守スレッドは 5 秒ごとに実行されます。[非アクティブ接続タイムアウト] 値 (たとえば 30 秒) が経過すると、スレッドは非アクティブな接続をチェックします。今回のチェック直前や前回のチェック直後に予約された接続のタイムアウトを回避するため、非アクティブな接続は 2 回チェックを受けることになっています。2 回目のチェック時でも接続がまだ非アクティブである場合、その接続はタイムアウトしたと見なされ、強制的にデータ ソースに返されます。タイムアウト時間は、コンフィグレーションした値より、平均して約 50% 遅延します。
アプリケーションで、データ ソースから接続を取得しようとしたが使用できる接続がない場合、使用できる接続がないという旨の例外が送出されます。このエラーを避けるには、データ ソースのサイズを接続リクエストの最大負荷に対応できるサイズに拡大するようにしてください。データ ソース内の使用できる接続の最大数を増やすには、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページでデータ ソースの [最大容量] の値を増大させます。
JDBC データ ソースで [ステートメント タイムアウト] オプションを使用すると、データ ソースからの予約されたデータベース接続に対する文の実行にかかる時間を制限できます。[ステートメント タイムアウト] に値を設定すると、WebLogic Server では、java.sql.Statement.setQueryTimeout() メソッドを使用して、指定された時間を JDBC ドライバに渡します。WebLogic Server が呼び出しを行い、ドライバが例外を送出した場合は、この値は無視されます。場合によっては、ドライバは暗黙的にこの呼び出しをサポートしていないか、制限されたサポートがドキュメントに記載されていることがあります。ドライバのドキュメントを確認して、予期しないエラーを検証することをお勧めします。
[ステートメント タイムアウト] を -1 (デフォルト値) に設定した場合には、文はタイム アウトしません。
このオプションの詳細については、Administration Console の [JDBC データ ソース : コンフィグレーション : 接続プール] ページ、または『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「JDBCConnectionPoolParamsBean」を参照してください。
アプリケーションがデータ ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ ソースの接続プロパティ リストに Pinned-To-Thread プロパティを追加し、その値を true に設定します。
Pinned-To-Thread が有効化されている場合、WebLogic Server では、データ ソースから実行スレッドまでのデータベース接続が固定されます。これは、アプリケーションでそのスレッドが接続の予約のために最初に使用されるときに実行されます。また、アプリケーションでその接続を利用し終えて connection.close() が呼び出されたときに、実行スレッドとの接続が保持され、接続はデータ ソースに返されません (この設定が有効でない場合、メソッドは接続をデータ ソースに返します)。そして、アプリケーションが引き続き同じ実行スレッドを使用して接続を要求したときに、すでにそのスレッドで予約されている接続が提供されます。このような方法を取ると、複数のスレッドが同時に接続の予約を試行したときに起こる、データ ソースでのロックの競合が発生しなくなります。また、限られた数のデータベース接続から同じ接続を予約しようとするスレッド間に競合が発生することもありません。
|
注意 : このリリースでは、Pinned-To-Thread 機能はマルチ データ ソース、Oracle RAC、および ID プールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続 ID が一致しなかった場合に、その接続を再取得する機能に依存しています。 |
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソース : コンフィグレーション : 接続プール」を参照してください。
接続プール動作の性質は、PinnedToThread を有効にすると変更されるため、そうした動作の変更に適合するため、次のように一部の接続プールの属性または機能の動作が通常と異なったり、無効化されます。
最大容量が無視される。接続プール内の接続の数は、接続プールから予約されている接続の数または初期容量のいずれか大きな方の値に等しくなります。
接続が接続プールに返されないため、PinnedToThread が有効化されている場合、縮小は接続プールに適用されない。接続は、効率上、常に予約されます。
接続プールをリセットすると、接続プールからリセットされた接続は、「テストが必要」とマークされる。次に各接続が予約されるときに、その接続は必要に応じてテストおよび再作成されます。接続は、接続プールのリセット時に同期的にテストされません。この機能は、[予約時に接続をテスト] を有効化し、[テスト対象のテーブル名] またはクエリを指定しておく必要があります。
PinnedToThread を有効にすると、接続プールの最大容量 (接続プールに作成されるデータベース接続の最大数) は、接続の要求に使われる実行スレッドの数に、各スレッドによって予約される同時接続の数を乗じた数になります。この数は、接続プールに指定された [最大容量] を超える場合があります。システム設計では接続のこの大きな数を考慮し、オープン カーソルなど、追加の関連リソースについてデータベースで許容されるようにすべき場合があります。
また、接続が接続プールに返されない点にも注意する必要があります。これは、接続プールを縮小して、使用される関連リソースおよび接続の数を減らすことができないことを意味します。このコストは、追加のドライバ パラメータ onePinnedConnectionOnly を設定することによって最小限に抑えることができます。onePinnedConnectionOnly=true の場合、要求された最初の接続のみがスレッドに固定されます。スレッドで必要なその他の接続はすべて、必要に応じて接続プールから取得されたり、接続プールに返されます。次に示すように、Properties 属性を使用して onePinnedConnectionOnly を設定します。
Properties="PinnedToThread=true;onePinnedConnectionOnly=true;user=examples"
システムで追加のリソース要件を処理できる場合、PinnedToThread オプションを使ってパフォーマンスを向上させることをお勧めします。
現在のシステムでは追加のリソース要件を処理できない、または PinnedToThread を有効化するとデータベース リソースでエラーが発生する場合は、PinnedToThread は使用しないでください。
データ ソースをクラスタまたはサーバにデプロイするには、サーバまたはクラスタをデプロイメント対象として選択します。データ ソースがサーバにデプロイされると、WebLogic Server はデータ ソース内のデータベース接続のプールを含む、サーバ上のデータ ソースのインスタンスを作成します。クラスタにデータ ソースをデプロイする場合、クラスタ内の各サーバ上にデータ ソースのインスタンスが作成されます。
手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソースの対象指定」を参照してください。
サーバ起動時に、WebLogic Server はサーバにデプロイされたデータ ソース内にデータベース接続を作成しようとします。データベースにアクセスできない場合、サーバの起動は、長時間に渡って STANDBY 状態でハングする可能性があります。これは WebLogic Server スレッドが、データベース サーバからの応答を待機している JDBC ドライバ コード内部でハングすることに起因しています。ハングの継続時間は、WebLogic Server マシン上の JDBC ドライバおよび TCP/IP タイムアウトの設定に左右されます。
この問題を回避するため、WebLogic Server では ServerMBean 上の JDBCLoginTimeoutSeconds 属性を用意しています。この属性の値を指定すると、値は java.sql.DriverManager.setLoginTimeout() に渡されます。データベース接続の作成に使用されている JDBC ドライバが setLoginTimeout メソッドを実装している場合、データベース接続作成が試行されるまでの待機時間は、指定されたタイムアウトの長さのみとなります。
以下の節では、JDBC データ ソースを保護するために WebLogic Server でロールおよびポリシーがどのように使用されているのかを説明します。
必要に応じて、JDBC データ ソースへのアクセスを制限することができます。WebLogic Server では、WebLogic リソースに対するアクセスの可否は、セキュリティ ポリシーによって決まります。セキュリティ ポリシーは、WebLogic リソースと、ユーザ、グループ、またはロールとの関連付けを定義する際に作成します。WebLogic リソースは、セキュリティ ポリシーが割り当てられるまでは保護されません。すべての WebLogic Server リソースのセキュリティを設定する手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ロールとポリシーを使用したリソースの保護」を参照してください。サーバ リソースの保護については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。
JDBC の操作は、管理者による JDBC データ ソースに対する操作を制限できる管理者用メソッドを割り当てることによって保護できます。『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「Java DataBase Connectivity (JDBC) リソース」を参照してください。
JDBC MBean で許容されるロールは Admin と Deployer のみです。以下の節では、JDBC MBean に定義されるセキュリティ ロールに関する情報が提供されます。
WebLogic Server のデフォルトのセキュリティ設定については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「Default Security Policies for MBeans」を参照してください。
次のドメイン コンフィグレーション JDBC MBean には、デフォルトのセキュリティ設定をオーバーライドする設定があります。
JDBCConnectionPoolMBean (非推奨)
JDBCDataSourceFactoryMBean (非推奨)
JDBCDataSourceMBean (非推奨)
JDBCMultiPoolMBean (非推奨)
JDBCSystemResourceMBean
JDBCTxDataSourceMBean (非推奨)
『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「Domain Configuration MBeans」を参照してください。
次のシステム モジュール JDBC MBean には、デフォルトのセキュリティ設定をオーバーライドする設定があります。
JDBCConnectionPoolParamsBean
JDBCDataSourceBean
JDBCDataSourceParamsBean
JDBCDriverParamsBean
JDBCPropertiesBean
JDBCPropertyBean
JDBCXAParamsBean
『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「System Module MBeans」を参照してください。
WebLogic Server のこれまでのリリースでは、アプリケーション スコープの JDBC 接続プールは、デフォルトの接続プールの値を提供するのに、JDBC データ ソース ファクトリを使用していました。JDBC データ ソース ファクトリは WebLogic Server 9.2 では非推奨となっており、本リリースでは下位互換性のみを目的としています。アプリケーション スコープの JDBC 接続プールの代わりとして、JDBC アプリケーション モジュールが使用されます。詳細については、「パッケージ化された JDBC モジュールのアプリケーション スコープ指定」を参照してください。
