接続プール設定

このページを使用して、接続プール設定を構成します。

この管理コンソール・ページは、JDBC データ・ソースおよび JMS 接続ファクトリー (キューまたはトピックの統合接続ファクトリー) に共通のページです。 このページを表示するためのパスはリソース・タイプによって異なりますが、通常は、リソース・タイプのインスタンスを選択してから「接続プール」をクリックします。以下に例を示します。
トラブルの回避 (Avoid trouble): 接続プールは、アプリケーション・クライアントでサポートされません。アプリケーション・クライアントはデータベースを直接呼び出し、データ・ソースを介しません。アプリケーション・クライアントから getConnection() 要求を使用する場合は、Rational® Application Developer またはアセンブリー・ツールを使用して、アプリケーション・クライアント・デプロイメント記述子で JDBC プロバイダーを構成します。 接続はアプリケーション・クライアントとデータベースとの間で確立されます。アプリケーション・クライアントに接続プールはありませんが、クライアント・デプロイメント記述子で JDBC プロバイダー設定を構成できます。gotcha
接続タイムアウト

接続要求がタイムアウトになり、 ConnectionWaitTimeoutException がスローされるまでの時間 (秒) を指定します。

この値は、空きプール内に使用可能な接続がなく、また新規接続が作成できないときに、 接続要求が待機する秒数を示します。 このような事態になるのは、通常は、特定の接続プールの接続数が 最大値に達した場合です。

例えば、接続タイムアウトが 300 に設定されていて、最大数の接続がすべて使用中の場合は、プール・マネージャーは、物理接続が使用可能になるのを 300 秒待機します。 物理接続がこの時間内に使用可能にならない場合は、プール・マネージャーが ConnectionWaitTimeout 例外を開始します。 ほとんどの場合、getConnection() メソッドの再試行はお勧めできません。 待機時間を長くする必要がある場合は、接続タイムアウトの設定値を増やします。 ConnectionWaitTimeout 例外がアプリケーションによってキャッチされた場合は、 そのアプリケーションで予想される接続プールの使用量を確認し、それに合うように接続プールとデータベースを 調整する必要があります。

接続タイムアウトが 0 に設定されている場合、 プール・マネージャーは、接続が使用可能になるまで必要なだけ待機します。 これは、アプリケーションがトランザクションを完了して接続をプールに戻す時、または接続数が最大接続値を下回り、新規物理接続の作成が許可された時に起こります。

最大接続数が 0 に設定されていると、物理接続の数が無制限になるので、 接続タイムアウト値は無視されます。

データ型 整数
単位
デフォルト 180
範囲 0 から最大の整数
最大接続数

このプールに構築できる物理接続の最大数を指定します。

これらは、バックエンド・リソースへの物理接続です。 一度この数値に到達すると、新規の物理接続は構築されず、 リクエスターは、現在使用中の物理接続がプールに戻されるか、 ConnectionWaitTimeoutException がスローされるまで待機します。例えば、最大接続数 が 5 に設定されていて、5 つの物理接続が 使用中の場合、プール・マネージャーは、接続タイムアウトに指定された 時間、物理接続が空くのを待機します。

バックエンド (DB2® データベースまたは CICS® サーバー) から接続を要求する可能性がある接続プールの数を把握しておくと、最大接続プロパティーの値の決定に役立ちます。

[AIX Solaris HP-UX Linux Windows] [iSeries] 同じデータ・ソース構成または J2C 接続ファクトリー構成を使用する、複数のスタンドアロン・アプリケーション・サーバーの場合、別の物理接続プールが各サーバーについて存在します。 これら同一のアプリケーション・サーバーを複製する場合、WebSphere® Application Server は各クローンについて別々の接続プールを実装します。

[z/OS] 同じリソースにアクセスするサーバントの数を考慮します。実行時には、この数で基本的に最大接続設定を乗算します。 サーバントが、同じ JDBC データ・ソースまたは J2C 接続ファクトリー構成を呼び出す場合、WebSphere Application Server は対応する物理接続プールを各サーバントに実装します。 したがって、同じ接続プールが単独で各サーバントに存在します。 最大接続設定は、これらのそれぞれのプールに対して適用されます。

[AIX Solaris HP-UX Linux Windows] [iSeries] これらのすべての接続プールは、同じデータ・ソースまたは接続ファクトリー構成に対応します。 したがって、これらすべての接続プールは、同時に同じバックエンド・リソースから接続を要求する可能性があります。 このコンソール・パネルでユーザーが設定する単一の最大接続値は、これらの接続プールのそれぞれに適用されます。 その結果、最大接続値を高く設定すると、接続要求が、バックエンド・リソースに大きな負荷をかける数になる可能性があります。

[z/OS] これらのサーバントのデータ・ソースまたは接続ファクトリーを要求する各アプリケーションは、リソースを同時に使用しようとする可能性があります。 したがって、対応する接続プールは同じバックエンドから同時に接続を要求します。 最大接続値は、接続要求がデータベースまたはその他のエンタープライズ情報システム (EIS) に大きな負荷をかけないように設定してください。

データ型 整数
デフォルト 10
範囲 0 から最大の整数

最大接続数が 0 に設定されていると、接続タイムアウト値は無視されます。

ヒント: パフォーマンスを改善するには、接続プールの値を Web コンテナーの 最大スレッド・プール接続数の値より低く設定します。 「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > server > 「スレッド・プール」 とナビゲートしてこの設定を構成し、WebContainer プロパティーを変更します。低い設定 (例えば、10 から 30 の接続) では、高い設定 (例えば、100) の場合よりもパフォーマンスが向上します。

Tivoli® Performance Viewer を使用して、プール内の最適な接続数を見つけることができます。 同時待機数が 0 より 大きいにもかかわらず、CPU 負荷が 100% 近くに達しない場合は、接続プール・サイズを大きくすることを検討します。通常のワークロード下で使用パーセントが常に低い場合は、プール内の接続数を減らすことを検討します。

最小接続数

維持する物理接続の最小数を指定します。

接続プールのサイズが最小接続プール・サイズと同じかまたはそれより小さい場合、「未使用タイムアウト」スレッドは物理接続を破棄しません。 しかし、プールは単独では接続を作成して最小接続プール・サイズを維持することを保障しません。 また、経過タイムアウトの値を設定すると、最小プール・サイズ設定にかかわらず、経過時間の有効期限が切れた接続は破棄されます。

例えば、「最小接続数」の値が 3 に設定されていて、1 つの物理接続が作成される場合、その接続が「未使用タイムアウト」スレッドによって廃棄されることはありません。 同じトークンによって、スレッドが自動的に 2 つの追加の物理接続を作成し、 「最小接続数」の設定値に達することはありません。

データ型 整数
デフォルト 1
範囲 0 から最大の整数
リープ時間

プール維持スレッドの実行とその次の実行との間隔 (秒) を指定します。

例えば、「リープ時間」が 60 に設定されていると、プール維持スレッドは 60 秒ごとに実行されます。 リープ時間の間隔は、未使用タイムアウトと経過タイムアウトの 設定値の精度に影響を与えます。 間隔が短いほど精度は高まります。 プール維持スレッドが使用可能である場合は、 リープ時間値を、未使用タイムアウトや経過タイムアウトの値より少なく設定してください。 プール維持スレッドが実行されると、 未使用タイムアウトで指定した値より長い時間使用されていない接続は すべて廃棄されます。廃棄は、最小接続数で指定した接続数になるまで 行われます。プール維持スレッドは、 経過タイムアウトで指定された時間値よりも長い間アクティブである接続も、すべて廃棄します。

リープ時間間隔も、パフォーマンスに影響を与えます。間隔が短いということは、 プール維持スレッドの実行回数が増え、パフォーマンスが低下することを意味します。

プール維持スレッドを使用不可にするには、リープ時間を 0 に設定するか、 または未使用タイムアウトと経過タイムアウトの両方を 0 に設定します。 プール維持スレッドを使用不可にするためには、リープ時間を 0 に設定する方法をお勧めします。 この場合、未使用タイムアウトと経過タイムアウトは無視されます。 ただし、未使用タイムアウトと経過タイムアウトが 0 に設定されている場合は、 プール維持スレッドは実行されますが、 タイムアウト値が非ゼロであるためにタイムアウトになる物理接続だけは廃棄されます。

データ型 整数
単位
デフォルト 180
範囲 0 から最大の整数
未使用タイムアウト

未使用またはアイドルの接続が廃棄されるまでの時間 (秒) を指定します。

パフォーマンスを最適化するためには、未使用タイムアウト値を、リープ時間より高く設定してください。 未使用の物理接続が廃棄されるのは、接続の現行数が、 最小接続数の設定値を超える場合に限られます。例えば、未使用タイムアウト値が 120 に設定され、 プール維持スレッドが使用可能 (リープ時間が 0 でない) である場合、 2 分間未使用の状態が続いた物理接続は廃棄されます。

このタイムアウトの精度とパフォーマンスは、リープ時間の値に 影響されます。詳しくは、リープ時間を参照してください。

データ型 整数
単位
デフォルト 1800
範囲 0 から最大の整数
経過時間タイムアウト

物理接続が廃棄されるまでの時間 (秒) を指定します。

経過タイムアウトを 0 に設定すると、アクティブな物理接続を無期限にプールに 残しておくことができます。パフォーマンスを最適化するには、経過タイムアウトをリープ・タイムアウトより高い値に設定します。 ただし、経過タイムアウトは必要な場合にのみ使用してください。

多くのリソース・アダプターで、経過タイムアウトは 0 に設定する必要があります。 経過タイムアウトは、管理対象接続が失効することが分かっている場合にのみ使用してください。 例えば、IMS 管理対象接続は、そのネイティブ・ログがこの管理対象接続の制限に達すると動作を停止します。 ログが 30 分でスペース不足になる場合には、経過タイムアウトを 25 分に設定します。 これにより、管理対象接続のクリーンアップが可能になり、バックエンド・リソースが解放されます。

また、別の例として、経過タイムアウト値を 1200 に設定し、リープ時間の値が 0 でない 場合は、1200 秒間 (20 分間) 存在し続けている物理接続はプールから廃棄されます。唯一の例外は、 経過タイムアウトに達したときに、接続がトランザクションに含まれている場合です。 この場合、アプリケーション・サーバーは、トランザクションが完了して接続が終了するのを待って その接続を廃棄します。

このタイムアウトの精度とパフォーマンスは、リープ時間の値に 影響されます。詳しくは、リープ時間を参照してください。

データ型 整数
単位
デフォルト 0
範囲 0 から最大の整数
パージ・ポリシー

不整合な接続 または致命的接続エラー が検出されたときに、 接続をパージする方法を指定します。

有効な値は「EntirePool」および「FailingConnectionOnly」です。

データ型 ストリング
デフォルト
  • J2C 接続ファクトリーおよび JMS 関連接続ファクトリーの場合は EntirePool
  • WebSphere バージョン 4.0 データ・ソースの場合は EntirePool
  • 管理コンソールで作成する現行バージョンのデータ・ソースの場合は EntirePool
  • wsadmin AdminConfig コマンドを使用してスクリプトを実行する現行バージョンのデータ・ソースの場合は EntirePool。これは、WebSphere Application Server に組み込まれる JDBC テンプレートを呼び出します (コマンド createUsingTemplate について詳しくは、インフォメーション・センターの項目『AdminConfig オブジェクトのコマンド』を参照してください。)
  • JDBC テンプレートを呼び出さないで wsadmin でスクリプトを実行するデータ・ソースの場合は FailingConnectionOnly
:
範囲
EntirePool
プール内の接続は、すべて失効とマークされます。使用されていない接続は、直ちに閉じられます。 使用中の接続は閉じられ、その接続に次回操作が行われたときに不整合接続の例外が発行されます。 アプリケーションからの後続の getConnection() 要求の結果、 開かれているデータベースへの新規接続が発生します。 このパージ・ポリシーを使用しているときは、 プール内の一部の接続が、失効していない場合に不必要に閉じられる可能性が若干あります。 ただし、これはめったに起こりません。たいていの場合は、パージ・ポリシーを EntirePool に設定するのが最善の選択です。
FailingConnectionOnly
不整合接続例外の発生原因である接続だけがクローズされます。この設定により、有効な接続が不必要に閉じられなくなる一方で、アプリケーション・パースペクティブからのリカバリーがより複雑になります。 現在失敗している接続だけが閉じられるため、 アプリケーションからの次の getConnection() 要求により、 プールからやはり失効した接続が戻され、結果的により多くの不整合接続の例外が 発生する可能性が極めて高くなります。

接続の事前テスト機能は、 無効なプール済み接続からアプリケーションを分離させます。 データベースなどのバックエンド・リソースが停止した場合、無効なプール済み接続が、空きプールに存在していることがあります。 これは、パージ・ポリシーが failingConnectionOnly の場合、特に発生します。この場合には、障害のある接続は、 そのプールから除去されます。障害によっては、プール内の残りの接続が、無効になっている場合があります。




マーク付きのリンク (オンライン) では、インターネットにアクセスする必要があります。

関連概念
関連タスク
関連資料


ファイル名: udat_conpoolset.html