Administration Console オンライン ヘルプ
|
 |
 |
|
[JDBC 接続プールに関する属性と Administration Console 画面のリファレンス]
以下の節では、Administration Console で JDBC 接続プールをコンフィグレーションおよび管理する方法について説明します。
接続プールとは、接続プールが登録されるとき (WebLogic Server の起動時や、対象となるサーバまたはクラスタに接続プールをデプロイするとき) に作成される JDBC 接続のグループです。接続プールでは、JDBC ドライバを使用して物理データベース接続を作成します。アプリケーションは、接続プールから接続を取得して使用し、その接続を閉じることによって接続プールに返却します。
Administration Console で行う設定はすべて静的なものです。つまり、すべての設定は WebLogic Server を停止して再起動した後も持続します。動的な接続プール、つまりサーバの実行中に使用および削除することが想定されている接続プールは、コマンドラインを使用して作成できます (『WebLogic Server Command Reference』の「JDBC 接続プールを管理するためのコマンド」を参照)。または API を使用してプログラムで作成することもできます (『WebLogic JDBC プログラマーズ ガイド』の「接続プールの動的作成」を参照)。
接続プールの設定は config.xml ファイルに保持されます。動的に作成された接続プールの設定も、プログラムによって接続プールが削除されるまではこのファイルに保持されます。config.xml ファイルのエントリについては、『コンフィグレーション リファレンス』の「JDBCConnectionPool」を参照してください。
JDBC 接続プールを作成するには、JDBC 接続プール アシスタントを使用します。JDBC 接続プール アシスタントは、データベースおよびドライバの情報の入力を求め、その後ドライバ クラス名、データベースの URL など、JDBC ドライバが必要とする接続属性を作成することによって、接続プールの作成とデプロイを支援します。
JDBC 接続プール アシスタントを使用して、接続プールを作成すると、接続プールの属性の多くがデフォルト値で設定されます。環境に応じて、接続プールの設定変更が必要になる場合もあります。たとえば、接続プールのすべての接続が使用中であるために、アプリケーションが常に接続を予約できない場合には、接続プールで使用可能な接続の最大数を増やす必要があります。
注意: JDBC 接続プール アシスタントのリストにある JDBC ドライバは、必ずしも WebLogic Server で動作確認されているとは限りません。JDBC 接続プール アシスタントの主旨に沿って、使用可能な多くのデータベース管理システムへの接続を簡単に作成できるように JDBC ドライバのリストが表示されます。
接続プールで JDBC ドライバを使用してデータベース接続を作成するには、接続プールをデプロイする各サーバに JDBC ドライバをインストールする必要があります。JDBC 接続プール アシスタントでは、接続プールのコンフィグレーションを支援するため、必須コンフィグレーション オプションとともにドライバのリストが表示されます。リストにある JDBC ドライバは必ずしもインストールされているとは限りません。ドライバのインストールには、システム パス、クラスパス、などの環境変数の設定も含まれます。『WebLogic JDBC プログラマーズ ガイド』の「サードパーティの JDBC ドライバに対する環境設定」を参照してください。
JDBC ドライバを更新すると、コンフィグレーションの要件が変わる場合があります。JDBC 接続プール アシスタントでは、WebLogic Server ソフトウェアのリリース時におけるコンフィグレーションの要件が使用されます。JDBC ドライバのコンフィグレーション オプションが変更されると、JDBC 接続プール アシスタントの手順 3 で表示されるコンフィグレーション オプション (接続プールの作成後であれば、そのプロパティ ページに表示されるコンフィグレーション オプション) を手動でオーバーライドしなければならない場合があります。
注意: JDBC ドライバを使用して接続プールでデータベース接続を作成するには、JDBC ドライバをインストールする必要があります。JDBC アシスタントでは、接続プールのコンフィグレーションを支援するため、必須コンフィグレーション オプションとともにドライバのリストが表示されます。ドライバのインストールには、システム パス、クラスパス、などの環境変数の設定も含まれます。
ほとんどの場合において、接続プールとともに使用するデータ ソースを作成する必要があります。データ ソースの作成については、JDBC データ ソースの作成とコンフィグレーションを参照してください。
接続プール作成時には通常、データベースへの接続用に少なくとも 1 つのパスワードを指定します。オープン文字列で XA を有効化するには、2 つのパスワードを使えます。これらのパスワードは [プロパティ] フィールドに名前と値の組み合わせとして入力することも、それぞれのフィールドに入力することも可能です。
config.xml ファイル内で暗号化され (JDBCConnectionPool タグの Password 属性として保存)、Administration Console 上では非表示になります。 config.xml ファイル内で暗号化され (JDBCConnectionPool タグの XAPassword 属性として保存)、Administration Console 上では非表示になります。実行時に、WebLogic Server はこのフィールドで指定したパスワードを使ってオープン文字列を再構築します。[プロパティ] フィールドのオープン文字列は、次のフォーマットになっている必要があります。openString=Oracle_XA+Acc=P/userName/+SesTm=177+DB=dbHost+Threads=true=Sqlnet=dvi0+logDir=.
初めて接続プールをコンフィグレーションする際に [プロパティ] フィールドでパスワードを指定した場合、WebLogic Server はそのパスワードを [プロパティ] の文字列から削除して、次に WebLogic Server を起動したときに暗号化した形でその値を [パスワード] 値として設定します。接続プールの [パスワード] 属性にすでに値が指定されていた場合、WebLogic Server は値の変更を行いません。しかし、[パスワード] 属性の値は [プロパティ] 文字列のパスワード値をオーバーライドします。同じ動作が、オープン文字列の一部として定義するすべてのパスワードに適用されます。たとえば、最初に接続プールをコンフィグレーションするときに以下のプロパティを指定したとします。
user=scott;
password=tiger;
openString=Oracle_XA+Acc=p/scott/tiger+SesTm=177+db=dbHost+Threads=true+Sqlnet=lcs817+logDir=.+dbgFl=0x15;server=dbHost
次に起動したときには、WebLogic Server はデータベース パスワードおよびオープン文字列に含まれるパスワードをそれぞれ [パスワード] 属性および [オープン文字列のパスワード] 属性に移動します。[プロパティ] フィールドには、次の値が残されます。
user=scott;
openString=Oracle_XA+Acc=p/scott/+SesTm=177+db=jtaXaPool+Threads=true+Sqlnet=lcs817+logDir=.+dbgFl=0x15;server=lcs817
[パスワード] 属性または [オープン文字列のパスワード] 属性の値が確立されると、これらの属性の値は [プロパティ] 属性のそれぞれの値をオーバーライドします。つまり、引き続き上記の例で言うと、[プロパティ] 属性でデータベース パスワードとして tiger2 を指定した場合、WebLogic Server はこの値を無視して、[パスワード] 属性の現在の暗号化された値である tiger をデータベース パスワードとして使用します。データベース パスワードを変更するには、[パスワード] 属性を変更する必要があります。
注意: [パスワード] と [オープン文字列のパスワード] の値は、同じである必要はありません。
クラスタに JDBC 接続プールをデプロイする際、ほとんどの場合において、デプロイメントはクラスタ全体に対して行います。関連するデータ ソースは、同じ対象にデプロイします。
[JDBC 接続プール] の [コンフィグレーション｜接続] タブで、接続プールの Statement キャッシュの属性をコンフィグレーションできます。Statement キャッシュの詳細については、Statement キャッシュによるパフォーマンス向上を参照してください。Statement キャッシュをコンフィグレーションするには、次の手順に従います。
statementCacheSize に達すると、新しい文が使用されるときに最長時間未使用の文が削除されます。statementCacheSize の文の数が固定されたままキャッシュに格納されます。キャッシュを手動でクリアするか、またはキャッシュ サイズを大きくしない限り、新しい文はキャッシュされません。詳細については、Statement キャッシュのアルゴリズムを参照してください。
10 です。詳細については、[Statement キャッシュ サイズ]を参照してください。
エンタープライズ アプリケーションをパッケージ化する際には、weblogic-application.xml 補足デプロイメント記述子を含めることができます。この記述子は、アプリケーション スコープのコンフィグレーションに使用します。weblogic-application.xml ファイルでは、エンタープライズ アプリケーションをデプロイするときに作成される JDBC 接続プールと関連するデータ ソースをコンフィグレーションできます。
このようにして作成されたデータ ソースと接続プールは、アプリケーション スコープの接続プール、アプリケーション スコープ プール、アプリケーション ローカル プール、またはローカル プールと呼ばれ、そのエンタープライズ アプリケーション専用にスコープされます。すなわち、各接続プールがエンタープライズ アプリケーションごとに分離されます。アプリケーション スコープの接続プール/データ ソースの各組み合わせを、アプリケーションのモジュールとしてデプロイします。
作成したアプリケーション スコープの接続プールは、それぞれがデータ ソース ファクトリを参照している必要があります。データ ソース ファクトリでは、アプリケーション スコープのデータ ソースと基底となる接続プールが作成されます。weblogic-application.xml の値は、データ ソース ファクトリで指定されたデフォルト値をオーバーライドできます。
データ ソースおよび接続プールのインスタンスは、アプリケーションのインスタンスごとに作成されます (モジュールを個別にデプロイする場合を除く)。これは、プールのインスタンスが、アプリケーションの対象となる各サーバ上のアプリケーションで作成されるということを意味します。接続プールのサイズ設定を検討する際には、この点に注意します。たとえば、接続プールのインスタンスごとに 10 のデータベース接続が存在し、アプリケーションが 10 個のサーバにデプロイされている場合、ドメイン全体でのデータベースへの接続数は 100 になります。オープン カーソルの最大数など、データベースに対する制限の検討が必要になる場合があります。
アプリケーション スコープと、アプリケーション スコープのリソースの詳細については、以下を参照してください。
エンタープライズ アプリケーションをアーカイブ (拡張子 .EAR、.WAR、.JAR または .RAR) としてデプロイする場合は、weblogic-application.xml デプロイメント記述子でそのアプリケーション用のアプリケーション スコープの接続プールに対するコンフィグレーションおよびすべての変更を行います。ただし、アプリケーションを展開アーカイブ ディレクトリでデプロイする場合は、Administration Console でアプリケーション スコープの接続プールに対するコンフィグレーション変更を行うことができます。weblogic-application.xml デプロイメント記述子で直接行った変更は、即座に有効になります。アプリケーション モジュール (アプリケーション スコープの接続プール) を再デプロイする必要はありません。
展開アーカイブでデプロイされた、アプリケーション スコープの接続プールのコンフィグレーション属性を変更するには、次の手順に従います。
複数の管理対象サーバあるいは 1 つまたは複数のクラスタが存在する環境にアプリケーションをデプロイする場合には、すべてのコンポーネントを一度にデプロイするか、またはアプリケーションのコンポーネントを個別にデプロイするかを選択できます。後者を選択した場合は必ず、アプリケーション スコープのデータ ソース (関連付けられた接続プールを含む) は、その接続プールからデータベース接続を使用するその他のアプリケーション コンポーネントと同じデプロイメント対象にデプロイしてください。たとえば、アプリケーション モジュール 1 が管理対象サーバ 1 にデプロイされ、アプリケーション モジュール 1 ではデータ ソース 1 からの接続が使用される場合には、データ ソース 1 を管理対象サーバ 1 にデプロイします。
アプリケーション スコープのデータ ソースをデプロイすると、アプリケーション コンポーネントは、java:comp/env のローカル JNDI ツリーにあるアプリケーション スコープのデータ ソースをルックアップして、アプリケーション スコープの接続プールから接続を取得します。データ ソースは、ローカル サーバで使用できなければなりません。
アプリケーション スコープのデータ ソースおよび接続プールに対するデプロイメント対象を変更するには、次の手順に従います。
[デプロイ] タブには、アプリケーション スコープの接続プールの、デプロイされた各インスタンスの状態が表示されます。たとえば、アプリケーション スコープの接続プールがドメイン内の 3 つのサーバにデプロイされている場合は、各デプロイメント対象とその対象にある接続プールの状態が表示されます。アクティブな接続プールを停止または再デプロイしたり、非アクティブな接続プールをデプロイしたりできます。接続プールを停止すると、すべてのデータベース接続が閉じられます。接続プールを再デプロイすると、すべての接続が閉じられ、接続プールが再作成されます。プールの再作成では、データベース接続の再作成 (初期数) などが行われます。
注意: デプロイメント対象を追加するには、[対象] タブで追加の対象を選択します。アプリケーション スコープの接続プールに対するデプロイメント対象の選択を参照してください。
アプリケーション スコープの接続プールを停止、再デプロイ、デプロイするには、次の手順に従います。
アプリケーション スコープの接続プールをモニタするには、次の手順に従います。
アプリケーション スコープの接続プールの [制御] タブでは、接続プールを手動で縮小またはリセットしたり、接続プールの Statement キャッシュをクリアしたりできます。多くの場合、Statement キャッシュの管理操作同様、縮小および更新操作も、接続プールの設定の基づいて自動的に行われます。
[テスト] タブでは、接続プールをデプロイした各サーバで接続プールの JDBC 接続をテストできます。
接続プールをテストする場合、WebLogic Server では接続プールからの接続を予約および解放します。
より有意義なテストを行うために、[コンフィグレーション｜記述子] タブで [Check On Reserve Enabled] または [Check On Release Enabled] が選択されていることを確認します。いずれかのオプションが選択されている場合、WebLogic Server では接続を予約および解放するだけでなく、物理的なデータベース接続もテストします。「属性」の [Check On Reserve Enabled] を参照してください。
接続テストとコンフィグレーション オプションの詳細については、接続テストのオプションを参照してください。
アプリケーション スコープの接続プールにある接続をテストするには、次の手順に従います。
以降の節では、JDBC 接続プールおよびデータ ソースのコンフィグレーションのガイドラインと例を示します。
WebLogic jDiriver for Oracle など、JDBC Core 2.0 API (java.sql) をサポートする JDBC 2.0 ドライバです。この API によって、データ ソースとの接続確立に必要なクラス オブジェクトの作成、データ ソースに対するクエリの送信と文の更新、および結果の処理を行うことができます。
WebLogic jDriver for Oracle/XA など、JDBC 2.0 の分散トランザクションの標準拡張インタフェース (javax.sql.XADataSource、javax.sql.XAConnection、javax.transaction.xa.XAResource) をサポートする任意の JDBC ドライバです。
JDBC 2.0 Core API をサポートするが、JDBC 2.0 の分散トランザクションの標準拡張インタフェースはサポートしない (非 XA)、任意の JDBC ドライバです。分散トランザクションに参加できる非 XA JDBC ドライバは 1 つだけです。分散トランザクション用 非 XA JDBC ドライバのコンフィグレーションを参照してください。
ローカル トランザクション用の JDBC ドライバをコンフィグレーションするには、次のように JDBC 接続プールを設定します。
java.sql.Driver インタフェースをサポートするクラスの名前として指定する。ドライバにドライバ プロパティとして渡される。 WebLogic JDBC ドライバの詳細については、使用している特定のドライバに関する以下の BEA のマニュアルを参照してください。『WebLogic jDriver for Oracle のコンフィグレーションと使い方』および『WebLogic jDriver for Microsoft SQL Server のコンフィグレーションと使い方』サードパーティのドライバを使用している場合は、『WebLogic JTA プログラマーズ ガイド』の「WebLogic Server でのサードパーティ JDBC XA ドライバの使い方」、および JDBC ドライバのベンダが提供しているマニュアルを参照してください。以下の表では、WebLogic jDriver を使用する JDBC 接続プールとデータ ソースのコンフィグレーションのサンプルを示します。
次の表は、WebLogic jDriver for Oracle を使用する接続プールのコンフィグレーションのサンプルを示しています。
注意: 以下のコンフィグレーション例では、[パスワード] 属性を使用します。[パスワード] 属性の値は、[プロパティ] で (名前と値の組み合わせとして) 定義されたパスワードをオーバーライドします。この属性は、物理データベース接続の作成時に、JDBC ドライバに渡されます。値は、パスワードをクリアテキストで保存することを回避するため、config.xml ファイル内に暗号化された形で保存されます。
|
[一般] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [一般]) |
|
|
[接続] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [接続]) |
|
|
[対象とデプロイ] タブ ([JDBC 接続プール] --> [対象とデプロイ]) |
|
次の表は、WebLogic jDriver for Oracle を使用するデータ ソースのコンフィグレーションのサンプルを示しています。
|
[コンフィグレーション] タブ ([JDBC データ ソース] --> [コンフィグレーション]) |
|
|
[対象とデプロイ] タブ ([JDBC データ ソース] --> [対象とデプロイ]) |
|
次の表は、IBM Informix JDBC Driver を使用する接続プールのコンフィグレーションのサンプルを示しています。
|
[一般] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [一般]) |
|
|
[接続] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [接続]) |
|
|
[対象とデプロイ] タブ ([JDBC 接続プール] --> [対象とデプロイ]) |
|
XA JDBC ドライバが分散トランザクションに参加できるようにするには、JDBC データ ソースと JDBC 接続プールを次のようにコンフィグレーションします。
javax.sql.XADataSource インタフェースをサポートするクラスの名前として指定する。XADataSource にデータ ソース プロパティとして渡される。WebLogic jDriver for Oracle のデータ ソース プロパティの詳細については、「追加の XA 接続プール プロパティ」を参照。サード パーティ ドライバのデータ ソース プロパティについては、ベンダのマニュアルを参照。データ ソースのコンフィグレーションの詳細については、JDBC データ ソースのコンフィグレーションを参照してください。
次の表は、XA モードの WebLogic jDriver for Oracle を使用する JDBC 接続プールのコンフィグレーションのサンプルを示しています。
|
[一般] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [一般]) |
|
|
[接続] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [接続]) |
|
|
[対象とデプロイ] タブ ([JDBC 接続プール] --> [対象とデプロイ]) |
|
次の表は、XA モードの WebLogic jDriver for Oracle を使用するデータ ソース (config.xml ファイルにあるトランザクション データ ソース) のコンフィグレーションのサンプルを示しています。
|
[コンフィグレーション] タブ ([JDBC データ ソース] --> [コンフィグレーション]) |
|
|
[対象とデプロイ] タブ ([JDBC データ ソース] --> [対象とデプロイ]) |
|
注意: 同じ接続プールを指すトランザクション データ ソースを 2 つ作成しないでください。同じ接続プールを指す 2 つの異なるトランザクション データ ソースがトランザクションで使用されている場合、2 番目の接続を取得しようとすると XA_PROTO エラーが発生します。
また、JDBC 接続プールをコンフィグレーションして、XA モードでサード パーティ ベンダ製ドライバを使用することもできます。この場合、データ ソース プロパティは、JavaBeans 設計パターンを使用し、XADataSource インスタンスに反映して設定します。つまり、プロパティ abc の場合、XADataSource インスタンスは getAbc という名前の取得メソッドと setAbc という名前の設定メソッドをサポートする必要があります。
次の表は、Oracle Thin Driver を使用する JDBC 接続プールのコンフィグレーションのサンプルを示しています。
|
[一般] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [一般]) |
|
|
[接続] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [接続]) |
|
|
[対象とデプロイ] タブ ([JDBC 接続プール] --> [対象とデプロイ]) |
|
次の表は、XA 向けに Oracle Thin Driver を使用するデータ ソースのコンフィグレーションのサンプルを示しています。
|
[コンフィグレーション] タブ ([JDBC データ ソース] --> [コンフィグレーション]) |
|
|
[対象とデプロイ] タブ ([JDBC データ ソース] --> [対象とデプロイ]) |
|
次の表は、PointBase JDBC ドライバを使用する分散トランザクションの JDBC 接続プールのコンフィグレーションのサンプルを示しています。
注意: PointBase Server は、WebLogic Server 配布キットに含まれている、Java だけで作られた DBMS 製品です。WebLogic Server の評価を支援するために、カスタム試用アプリケーションの形態で、または WebLogic Server に付属しているパッケージ化されたサンプル アプリケーションを介する形態で含まれています。 PointBase Server を評価用ではなく、開発用およびプロダクション用に使用するには、エンド ユーザが別個のライセンスを PointBase から直接取得する必要があります。
|
[一般] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [一般]) |
|
|
[接続] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [接続]) |
|
|
[対象とデプロイ] タブ ([JDBC 接続プール] --> [対象とデプロイ]) |
|
PointBase XA ドライバを使用するデータ ソースは、次のようにコンフィグレーションします。
|
[コンフィグレーション] タブ ([JDBC データ ソース] --> [コンフィグレーション]) |
|
|
[対象とデプロイ] タブ ([JDBC データ ソース] --> [対象とデプロイ]) |
|
分散トランザクションで接続プールからの接続を使用する際には、接続プールがトランザクションのコンテキストにおいて接続を正しく処理できるよう、接続プールに対して追加のプロパティの設定が必要になる場合があります。これらのプロパティは、コンフィグレーション ファイル (config.xml) の JDBCConnectionPool タグ、または Administration Console の [JDBC 接続プール] --> [コンフィグレーション] --> [接続] タブで設定します。 デフォルトでは、すべての追加プロパティは、false に設定されています。これらのプロパティを有効化するには、true に設定します。
多くの場合、これらのプロパティに対して自動的に適切な値が設定されるため、手動で設定する必要はありません。
追加の XA 接続プール プロパティについては、詳細オプションの属性を参照してください。
一部の DBMS では、トランザクションの開始と終了を同じ物理データベース接続内で行うことが必要になります。 WebLogic Server では、場合によって、ある物理データベース接続で開始したトランザクションが、別の物理データベース接続で終了する場合があります。接続プールで強制的に物理接続を予約し、トランザクションの処理全体において、そのトランザクションが完了するまで、アプリケーションに対して同じ接続を提供するには、[JDBC 接続プール] --> [コンフィグレーション] --> [接続] タブにある [トランザクション完了まで XA 接続を保持] オプションを選択します。
注意: このプロパティは、DB2 および Sybase で分散トランザクションをサポートするためには必須です。
一部の JDBC XA ドライバでは、さまざまな JDBC オブジェクト (結果セット、文、接続など) を閉じるときに分散トランザクション コンテキストが必要になります。 トランザクション コンテキストでない JDBC オブジェクトを閉じるときに送出される SQL 例外を無条件に受信するよう WebLogic Server に強制するには、[JDBC 接続プール] --> [コンフィグレーション] --> [接続] タブにある [クローズ時にトランザクション コンテキストが必要] オプションを選択します。
一部の JDBC XA ドライバでは、分散トランザクションのコミットまたはロールバック処理で専用の XA 接続が使用されることが必要になります。 トランザクションのコミットまたはロールバック処理時に別個の XA 接続を使用するよう WebLogic Server に強制するには、[JDBC 接続プール] --> [コンフィグレーション] --> [接続] タブにある [コミット専用に新しい XA 接続を使用] オプションを選択します。
一部の DBMS および JDBC XA ドライバ では、保留中の各 XAResource.start() に対して XAResource.end() が一度だけ呼び出されることが必要になります。 XAResource.end(TMSUSPEND) および XAResource.end(TMSUCCESS) を WebLogic Server で連続して呼び出せないようにするには、[JDBC 接続プール] --> [コンフィグレーション] --> [接続] タブにある [XA を 1 度だけ終了] オプションを選択します。
一部の DBMS および JDBC XA ドライバ では、物理 XA 接続が XA 接続プールに返されても、トランザクション処理が継続している間は論理 JDBC 接続が開いたまま保持されることが必要になります。 トランザクション処理の実行中に論理接続を開いたまま保持するには、[JDBC 接続プール] --> [コンフィグレーション] --> [接続] タブにある [リリース時に接続を開いたまま保持] オプションを選択します。
一部の XA JDBC ドライバでは、グローバル トランザクションを開始せずに SQL 文を実行できます。 その他のドライバでは、グローバル トランザクションを使用しないSQL 処理は回避されます。 接続プールで使用される XA JDBC ドライバで、グローバル トランザクションを使用しない SQL 処理がサポートされている場合は、[JDBC 接続プール] --> [コンフィグレーション] --> [接続] タブにある [ローカル トランザクションのサポート] オプションを選択します。
非 XA JDBC ドライバが他のリソースとともに分散トランザクションに参加できるように JDBC 接続プールをコンフィグレーションする場合は、JDBC トランザクション データ ソースに対して [非 XA ドライバ用に 2 フェーズ コミットをエミュレート] 属性 (JDBCTxDataSource MBean 内の EnableTwoPhaseCommit) を選択します。このパラメータは、XAResource インタフェースをサポートするリソースによって無視されます。分散トランザクションに参加できる非 XA 接続プールは 1 つだけです。詳細については、2 フェーズ コミットのエミュレーションを参照してください。
注意: [非 XA ドライバ用に 2 フェーズ コミットをエミュレート] オプションを使用していると、データの整合性が損なわれるおそれがあります。このオプションよりも、XA 対応の JDBC ドライバを使用することをお勧めします。このオプションを有効にする前に、必ず以下のリスクを考慮してください。グローバル トランザクションで非 XA ドライバを使用する場合の制限とリスクを参照してください。
非XA ドライバを 1 つだけ使用していて、それがトランザクション内での唯一のリソースである場合、Administration Console で [非 XA ドライバ用に 2 フェーズ コミットをエミュレート] オプションを非選択のままにしておきます (デフォルトの EnableTwoPhaseCommit = false をそのまま使用)。この場合は、トランザクション マネージャが 1 フェーズの最適化を実行します。
他の XA リソースとともに 1 つの非 XA JDBC ドライバを使用している場合は、Administration Console で [非 XA ドライバ用に 2 フェーズ コミットをエミュレート] を選択します (EnableTwoPhaseCommit = true)。
[非 XA ドライバ用に 2 フェーズ コミットをエミュレート] が選択されている (EnableTwoPhaseCommit が true に設定されている) 場合、非 XA JDBC リソースは XAResource.prepare() メソッド呼び出し中に常に XA_OK を返します。リソースは、後続の XAResource.commit() または XAResource.rollback() の呼び出しに応答して、ローカル トランザクションをコミットまたはロールバックしようとします。リソースのコミットまたはロールバックが失敗した場合は、ヒューリスティックなエラーが発生します。ヒューリスティック エラーの結果、アプリケーション データは矛盾した状態のまま残される場合があります。
[非 XA ドライバ用に 2 フェーズ コミットをエミュレート] オプションが Administration Console で選択されていない (EnableTwoPhaseCommit が false に設定されている) 場合、非 XA JDBC リソースにより、XAResource.prepare() が失敗します。このメカニズムにより、この場合では commit() が SystemException を送出するため、トランザクションに参加しているリソースは確実に 1 つだけになります。トランザクションに参加するリソースが 1 つだけの場合、1 フェーズの最適化が XAResource.prepare() をバイパスし、トランザクションはほとんどのインスタンスで正常にコミットされます。
次の表は、非 XA JDBC ドライバを使用する JDBC 接続プールのコンフィグレーションのサンプルを示しています。
|
[一般] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [一般]) |
|
|
|
|
|
[接続] タブ ([JDBC 接続プール] --> [コンフィグレーション] --> [接続]) |
|
|
[対象とデプロイ] タブ ([JDBC 接続プール] --> [対象とデプロイ]) |
|
次の表は、非 XA JDBC ドライバを使用するデータ ソースのコンフィグレーションのサンプルを示しています。
|
[コンフィグレーション] タブ ([JDBC データ ソース] --> [コンフィグレーション]) |
|
|
[対象とデプロイ] タブ ([JDBC データ ソース] --> [対象とデプロイ]) |
|
必要に応じて、JDBC 接続プールへのアクセスを制限することができます。WebLogic Server では、WebLogic リソースに対するアクセスの可否は、セキュリティ ポリシーによって決まります。セキュリティ ポリシーは、WebLogic リソースと、ユーザ、グループ、またはロールとの関連付けを定義する際に作成します。WebLogic リソースは、セキュリティ ポリシーを割り当てられるまで、保護の対象となりません。すべての WebLogic Server リソースに対してセキュリティを設定する手順については、WebLogic リソースの保護を参照してください。サーバ リソースのセキュリティの詳細については、『WebLogic リソースのセキュリティ』を参照してください。
Administration Console の JDBC 接続プールのプロパティ タブで、ドメイン内の接続プールを管理できます。以降の節では、JDBC 接続プールに対して管理タスクを手動で実行する手順の詳細を説明します。
[JDBC 接続プール｜テスト] タブでは、接続プールをデプロイした各サーバで接続プールの JDBC 接続をテストできます。
接続プールをテストする場合、WebLogic Server では接続プールからの接続を予約および解放します。
より有意義なテストを行うために、[コンフィグレーション｜接続] タブの [詳細オプション] で [リザーブされたときに接続をテスト] または [リリースされたときに接続をテスト] が選択されていることを確認します。いずれかのオプションが選択されている場合、WebLogic Server では接続を予約および解放するだけでなく、物理的なデータベース接続もテストします。「属性」の [リザーブされたときに接続をテスト] を参照してください。
[JDBC 接続プール｜テスト] タブに表示される情報の説明については、「属性」を参照してください。
接続テストのオプション、および [テスト テーブル名] のデフォルト値の詳細については、接続テストのオプションも参照してください。
接続プールをリセットすると、WebLogic Server は接続プール内のすべてのデータベース接続を停止し、再作成します。
必要な接続数の増加に応じてデータベース接続を追加できるように接続プールをコンフィグレーションした場合、[制御] タブの [縮小] ボタンをクリックして、手動で接続プールを縮小できます。接続プールを縮小するとき、WebLogic Server はプール内の接続の数を、初期容量と現在使用中の接続数の、いずれか大きいほうの数まで低減します。
接続プールをサスペンドすると、プール内の接続がアプリケーションで使用できなくなります。WebLogic Server には、接続プールをサスペンドするための以下のオプションが用意されています。
サスペンドされた接続プールの接続はそのまま残されます。接続プールを再開しても接続は再作成されません (接続プールが強制的にサスペンドされた場合を除く)。
接続プールを手動でサスペンドした後、[JDBC 接続プール｜制御] タブをクリックすると、その接続プールを再び有効にできます。正常に起動しなかった接続プールの再開には、[再開] 機能を使用することはできません。
接続プールのインスタンスを停止するには、サーバ上の接続プールをアンデプロイします。この処理により、接続プールのすべての物理データベース接続が閉じられます。複数の対象にある接続プールを停止するには、各デプロイメント対象に対してアンデプロイを行う必要があります。
注意: 接続が使用中の場合、停止処理は失敗し、接続プールはサスペンド状態になります。正常な処理を復元するには、接続プールを再開する必要があります。
接続プールを強制的に停止する場合は、接続プールを強制的にサスペンドしてから次の手順に従います。
アンデプロイによって停止した接続プール (JDBC 接続プールの停止を参照) を再起動するには、この接続プールをサーバおよびクラスタに再デプロイします。手順については、1 つまたは複数のサーバまたはクラスタへの JDBC 接続プールのデプロイメントを参照してください。
JDBC 接続プールを破棄すると、接続プールのすべてのインスタンスのすべてのデータベース接続が閉じられ、接続プールのコンフィグレーションはドメインから削除されます。
注意: 接続プールを破棄する場合、[破棄] ボタンをクリックしたインスタンスだけでなく、接続プールのすべてのインスタンスを破棄することになります。
WebLogic Server の接続プールには、破棄オプションが 2 つあります。
接続プールのすべての接続の Statement キャッシュをクリアするには、次の手順に従います。
接続プールの Statement キャッシュの詳細については、Statement キャッシュによるパフォーマンス向上を参照してください。
表示される情報の詳細については、[JDBC 接続プール] --> [モニタ]を参照してください。
WebLogic Server ドメインの接続プールを正しくコンフィグレーションすることで、アプリケーションおよびシステムのパフォーマンスを向上させることができます。 この節の内容は、以下のとおりです。
[JDBC｜接続プール] の [コンフィグレーション｜接続] タブには、接続要求が接続プールからの接続を待機できるように設定する 2 つの属性、[接続予約のタイムアウト] および [接続の最大待機数] があります。
アプリケーションが接続プールからの接続を要求したときに、接続プール内の接続がすべて使用中であり、かつ、接続プールがその最大容量まで拡張されている場合には、[接続予約のタイムアウト] 値 (秒単位) をコンフィグレーションして、接続が使用可能になるまで接続要求が待機できるようにコンフィグレーションできます。[接続予約のタイムアウト] に指定した時間が経過しても接続が使用可能にならない場合、要求は失敗します。
[接続予約のタイムアウト] を -1 に設定すると、接続要求は無限に待機します。
属性の詳細については、[接続予約のタイムアウト]を参照してください。
接続を待機する接続要求はスレッドをブロックします。あまりに多くの接続要求が同時に接続を待機し、スレッドをブロックすると、システムのパフォーマンスが低下します。これを回避するには、[接続の最大待機数] 属性を設定して、同時に接続を待機できる接続要求数を制限します。
[接続の最大待機数] を 0 に設定すると、この機能は無効になり、接続要求は接続を待機できなくなります。
属性の詳細については、[接続の最大待機数]を参照してください。
リークされた接続とは、適切に接続プールに返されなかった接続のことです。リークされた接続を自動的に回復するには、[JDBC｜接続プール] の [コンフィグレーション｜接続] タブで、[非アクティブ接続タイムアウト] に値を指定します。[非アクティブ接続タイムアウト] に値を指定すると、予約された接続が指定した秒数の間、非アクティブになっている場合、接続が強制的に接続プールに返されます。0 (デフォルト値) に設定すると、この機能は無効になります。
属性の詳細については、[非アクティブ接続タイムアウト]を参照してください。
実際のタイムアウト時間は、[非アクティブ接続タイムアウト] にコンフィグレーションした値より長くなります。内部の接続プール保守スレッドは 5 秒ごとに実行されます。[非アクティブ接続タイムアウト] 値 (たとえば 30 秒) が経過すると、スレッドは非アクティブな接続をチェックします。今回のチェック直前や前回のチェック直後に予約された接続のタイムアウトを回避するため、非アクティブな接続は 2 回チェックを受けることになっています。2 回目のチェック時でも接続がまだ非アクティブである場合、その接続はタイムアウトしたと見なされ、強制的に接続プールに返されます。タイムアウト時間は、コンフィグレーションした値より、平均して約 50% 長くなります。
リークされた接続の自動回復を有効化すると、接続プールからリークされた接続についての統計情報を表示できます。
WebLogic Server では、接続プールにおけるデータベース接続の作成時に、自動的に SQL コードを実行して、データベース接続を初期化することができます。この機能を有効にするには、[JDBC｜接続プール] の [コンフィグレーション｜接続] タブにある [初期化 SQL] 属性に、「SQL」と入力し、その直後にスペース、次に実行する SQL コードを入力します。この属性を空白のままにしておくと (デフォルト)、データベース接続を初期化するコードは実行されません。
サーバの起動時、接続プールの拡張時、接続の更新時など、接続プールにおけるデータベース接続の作成時には常にコードが実行されます。
SQL コードを使用してデータベース接続を初期化するには、次の手順に従います。
接続プール内のデータベース接続が正常な状態であることを確認するには、接続を定期的にテストする必要があります。WebLogic Server には、2 種類の基本的なテスト方法があります。1 つは自動のテストで、[JDBC｜接続プール] の [コンフィグレーション｜接続] タブにあるオプションを使ってコンフィグレーションします。もう 1 つは手動のテストで、[JDBC｜接続プール] の [テスト] タブから接続プールのトラブルシューティングを行うことができます。次の節では、自動接続テストのオプションについて説明します。手動接続テストの詳細については、JDBC 接続プールのテストを参照してください。
[JDBC｜接続プール] の [コンフィグレーション｜接続] タブにある、以下の設定を使用して接続テストをコンフィグレーションします。
3 に設定すると、接続要求に応じる使用可能な接続が 2 個残ります。SQL」と入力し、その直後にスペース、次に実行する SQL コードを入力します。[テスト テーブル名] は、データベース接続のテストを有効にするための必須の属性です。接続テストの属性は環境に合うように設定する必要があります。これらの属性の詳細については属性を参照してください。
データベース接続のテストを有効にするには、次の手順に従います。
接続プールを作成すると、選択している JDBC ドライバの DBMS に基づいた接続プールの [テスト テーブル名] 属性が、JDBC 接続プール アシスタントにより自動的に設定されます。[テスト テーブル名] 属性は接続テストで使用されます。接続テストは必要に応じて、接続プールのコンフィグレーションにより定期的に、または接続を作成、予約、解放したときに実行されます。データベースのテストを正常に実行するためには、接続プールのデータベース接続を作成するユーザが、該当するデータベース テーブルにアクセスできる必要があります。アクセスできない場合には、DBMS を使用してそのユーザにアクセスを付与するか、WebLogic Server Administration Console を使用して [テスト テーブル名] 属性をユーザがアクセスを持つテーブルの名前に変更する必要があります。
アプリケーションまたは EJB において prepared statement または callable statement を使用すると、アプリケーション サーバとデータベース サーバ間の通信、およびデータベース サーバ自体に、かなりの処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WebLogic Server ではアプリケーションで使用する prepared statement および callable statement をキャッシュできます。アプリケーションまたは EJB が、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Server はキャッシュ内に格納されている文を再利用します。prepared statement および callable statement を再利用することで、データベース サーバの CPU 使用率が低減され、現在の文に対するパフォーマンスが向上し、CPU サイクルを他のタスクのために取っておくことができます。
接続プールの各接続には、接続に使用する prepared statement および callable statement のキャッシュが個別に備わっています。しかし、Statement キャッシュのコンフィグレーションは、接続プールごとに行います。つまり、接続プールの各接続の Statement キャッシュでは、その接続プールについて指定した Statement キャッシュ オプションを使用します。Statement キャッシュのコンフィグレーション オプションには、次のようなものがあります。
10 です。[Statement キャッシュ サイズ]を参照してください。接続プールの Statement キャッシュ オプションの設定には、次の方法を使用できます。
また、接続プールの Statement キャッシュは、手動でクリアすることもできます。JDBC 接続プールの Statement キャッシュのクリアを参照してください。
Statement キャッシュのタイプ (つまりアルゴリズム) は、接続プールの各接続のキャッシュに格納する prepared statement と callable statement を決定します。次のオプションから選択できます。
[LRU] (最長時間未使用。デフォルト) を Statement キャッシュのタイプとして選択すると、WebLogic Server は接続で使用される prepared statement および callable statement を、Statement キャッシュのサイズに到達するまでキャッシュします。アプリケーションが Connection.prepareStatement() を呼び出すと、WebLogic Server はその文が Statement キャッシュに格納されているかどうかを確認します。格納されていた場合、WebLogic Server はキャッシュされていた文を (それがすでに使用されていなければ) 返します。文がキャッシュ内に存在せず、キャッシュがいっぱい (キャッシュ内の文の数 = Statement キャッシュのサイズ) であった場合、WebLogic Server はキャッシュ内の既存の文のうち未使用時間の最も長いものを判断し、キャッシュ内のその文と新しい文を入れ替えます。
WebLogic Server の LRU Statement キャッシュ アルゴリズムは、近似 LRU 方式を使用します。
[FIXED] を Statement キャッシュのタイプとして選択すると、WebLogic Server は接続で使用される prepared statement および callable statement を、Statement キャッシュのサイズに到達するまでキャッシュします。追加の文が使用された場合、これらはキャッシュされません。
この Statement キャッシュ アルゴリズムでは、ほとんど使われない文を意図せずキャッシュしてしまうことがあります。多くの場合、LRU アルゴリズムが使用されます。ほとんど使われない文が、キャッシュ内で最終的には頻繁に使われる文に置き換えられるからです。
[Statement キャッシュ サイズ] 属性は、接続プールの各インスタンスの各接続にキャッシュする prepared statement と callable statement の総数を決定します。文をキャッシュすることで、システムのパフォーマンスが向上します。ただし、DBMS でオープンな prepared statement と callable statement がどのように処理されるかを考慮する必要があります。多くの場合、DBMS は開いている各文について、カーソルを保持します。これは、Statement キャッシュ内の prepared statement および callable statement に対して適用されます。キャッシュされた文の数が多すぎると、データベース サーバ上のオープン カーソル数の上限を超えてしまうことがあります。
たとえば、10 個の接続がある接続プールが 2 つのサーバにデプロイされている場合、[Statement キャッシュ サイズ] を 10 (デフォルト値) に設定すると、キャッシュされた文に対してデータベース サーバ上で 200 個 (10 x 2 x 10) のカーソルを開く可能性があります。
Statement キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。Statement キャッシュを使用する場合は、以下の制限に留意してください。
ここに示す以外にも、文のキャッシングに関連した問題が存在する可能性があります。prepared statement または callable statement に関連するシステムでエラーが見つかった場合は、Statement キャッシュのサイズを 0 に設定して 文のキャッシングをオフにし、問題が prepared statement のキャッシングに起因するものかどうかをテストする必要があります。
キャッシュ内に格納された prepared statement は、prepared statement のキャッシュ時に特定のデータベース オブジェクトを参照します。キャッシュに格納された prepared statement で参照されるデータベース オブジェクトに対して、何らかの DLL (データ定義言語) 処理を実行すると、それらの文は次に実行したときに失敗する可能性があります。たとえば、select * from emp などの文をキャッシュしてから、emp テーブルを削除して再作成した場合、その文が準備されたときに存在した emp テーブルはなくなるため、キャッシュされた文を次に実行すると、その文は失敗します。
同様に、prepared statement は、キャッシュされた時点でデータベース内のテーブルの各カラムのデータ型にバインドされます。テーブルのカラムを追加、削除、または再配列すると、キャッシュに格納されている prepared statement は、再び実行されたときに失敗するおそれがあります。
WebLogic jDriver for Oracle を使用してデータベースに接続しているときに、setNull バインド変数を使用する prepared statement をキャッシュする場合は、変数を適切なデータ型に設定する必要があります。次の例で示すような汎用のデータ型を使用すると、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 jDriver for Oracle を使用する場合には常に発生します。WebLogic jDriver for Oracle では、JDBC 仕様の表 B-5 に従ってデータ型が変換されます。この問題は、他の JDBC ドライバでも発生する可能性があります。
WebLogic Server でキャッシュされた prepared statement または callable statement は、データベースのカーソルを開くことができます。キャッシュされた文の数が多すぎると、接続のためのオープン カーソル数の上限を超えてしまうことがあります。接続のためのオープン カーソル数の上限を超えないようにするには、データベース管理システムの上限を変更するか、または接続プールの Statement キャッシュのサイズを低減します。
アプリケーションが接続プールからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、接続プールの接続プロパティ リストに PinnedToThread プロパティを追加し、その値を true に設定します。 [プロパティ] は、Administration Console の [JDBC 接続プール｜コンフィグレーション｜一般] タブで設定します。 [JDBC 接続プール] --> [コンフィグレーション] --> [一般]を参照してください。 config.xml ファイルの結果は、次のようになります。
<JDBCConnectionPool
DriverName="com.pointbase.jdbc.jdbcUniversalDriver"
InitialCapacity="1"
Name="demoPool"
Password="{3DES}4oIxnuEUXInhlPfGNdsQ3A=="
Properties="PinnedToThread=true;user=examples"
Targets="examplesServer"
TestConnectionsOnReserve="true"
TestTableName="SYSTABLES"
URL="jdbc:pointbase:server://localhost/demo"
/>
PinnedToThread を有効にすると、アプリケーションが実行スレッドを使用して初めて接続を予約するときに接続プールからのデータベース接続がその実行スレッドに固定されます。 アプリケーションで接続の使用が終了し、connection.close() が呼び出されても、接続は実行スレッドに固定された状態で保持され、接続プールに返されません。このプロパティが有効でない場合、接続は接続プールに返されます。 その後、アプリケーションが同じ実行スレッドを使用して接続を要求すると、WebLogic Server によってスレッドで予約済みの接続が提供されます。 複数のスレッドが同時に接続を予約しようとする場合に発生する、接続プールでのロックの競合がなく、限られた数のデータベース接続から同じ接続を予約しようとするスレッドの競合もありません。
アプリケーションが同じ実行スレッドを使用して接続プールからの複数の接続を同時に予約する場合には、追加のデータベース接続が作成され、それらがスレッドに固定されます。
PinnedToThread を有効にすると接続プールの動作の性質が変化するので、その変化に適用するため、接続プールの以下の一部の属性や機能が異なった動作をしたり、無効になったりします。
config.xml の MaxCapacity) は無視されます。 接続プール内の接続数は、初期容量または接続プールからの予約された接続数の大きいほうと同じになります。PinnedToThread が有効になっている接続プールには適用されません。 事実上、接続は常に予約されます。 PinnedToThread を有効にすると、接続プールの最大容量 (接続プールで作成されるデータベース接続の最大数) は、接続のリクエストに使用される実行スレッドの数に各スレッドが予約している同時接続の数を掛けた数になります。 この数は接続プールに対して指定されている [最大容量] の値を超過する場合があります。 場合によっては、使用しているシステム設計で超過する接続数を検討して、オープン カーソルなどの追加の関連付けられたリソースにデータベースが対応できることを確認する必要があります。
また、接続は接続プールに返されません。つまり、接続プールは縮小せず、接続数も使用中の関連付けられたリソースも減少しません。
システムで追加のリソース要件を処理できる場合は、PinnedToThread オプションを使用してパフォーマンスを向上させることをお勧めします。
システムで追加のリソース要件を処理できない場合や、PinnedToThread を有効にしてデータベース リソース エラーが発生した場合は、PinnedToThread を使用しないことをお勧めします。
|
|
|