セッション・プール設定

このページを使用して、セッション・プール設定を構成します。

この管理コンソール・ページは、特定のリソース・タイプ (例えば、JMS キュー接続ファクトリーなど) に共通のものです。 このページを表示するためのパスはリソースのタイプによって異なります。 一般的な表示手順としては、リソース・プロバイダーのインスタンスを選択し、次にそのリソース・タイプのインスタンスを 選択し、「セッション・プール」をクリックします。例えば、「リソース」 > 「JMS」 > 「JMS プロバイダー」->「デフォルトのメッセージング・プロバイダー」->「キュー接続ファクトリー」->「connection_factory」 ->「セッション・プール」とクリックします。

「構成」タブ

接続タイムアウト

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

特定の接続プールに対する接続の最大値 (最大接続数) に達したら、待機する必要があります。例えば、接続タイムアウト が 300 に設定されていて、 最大接続数に達している場合、プール・マネージャーは、物理接続が使用可能になるのを 300 秒待機します。 物理接続が、この時間内に使用可能にならない 場合は、 プール・マネージャーが ConnectionWaitTimeoutException をスローします。 getConnection() メソッドを再試行しても、通常は意味がありません。 これは、待機時間を長くする必要がある場合、「接続タイムアウト」設定を より高い値に設定する必要があるためです。したがって、この例外がアプリケーションによってキャッチされた場合、 管理者はアプリケーションの予期される使用法を確認し、 それに従って接続プールとデータベースを調整する必要があります。

接続タイムアウトが 0 に設定されている場合、プール・マネージャーは、接続が割り振られるまで (割り振られるのは、接続数が最大接続数の値を下回った場合です) 必要に応じて待機します。

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

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

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

これらは、バックエンド・リソースへの物理接続です。 一度この数値に到達すると、新規の物理接続は構築されず、 リクエスターは、現在使用中の物理接続がプールに戻されるか、 ConnectionWaitTimeoutException がスローされるまで待機します。

例えば、最大接続数 が 5 に設定されていて、5 つの物理接続が 使用中の場合、プール・マネージャーは、接続タイムアウトに指定された 時間、物理接続が空くのを待機します。

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

パフォーマンスを改善するには、接続プールの値を Web コンテナー・オプションの 最大接続数の値より低く設定します。 低い設定 (例えば、10 から 30 の接続) では、高い設定 (例えば、100) の場合よりもパフォーマンスが向上します。

クローンを使用する場合、各クローンに対して 1 つのデータ・プールが存在します。 データ・プール数を知ることは、データベースの最大接続数を構成する場合に重要となります。

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

[AIX Solaris HP-UX Linux Windows] [iSeries]
データ型 整数
デフォルト 10
範囲 0 から 最大の整数
最小接続数

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

この数値に達するまで、プール維持スレッドは物理接続を廃棄しません。 ただし、接続数をこの数値まで増やすための試行は行われません。経過タイムアウトの値を設定すると、この最小数は維持されません。有効期限切れの接続はすべて廃棄されます。

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

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

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

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

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

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

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

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

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

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

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

経過タイムアウト」を 0 に設定すると、アクティブな物理接続を無制限にプールに残しておくことができます。パフォーマンスを最適化するには、「経過タイムアウト」を「リープ時間」 より高い値に設定してください。例えば、経過タイムアウト値を 1200 に設定し、リープ時間の値が 0 でない 場合は、1200 秒間 (20 分間) 存在し続けている物理接続はプールから廃棄されます。 パフォーマンスと同様、このタイムアウトの精度もリープ時間値の影響を受けます。 詳しくは、リープ時間を参照してください。

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

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

有効な値は「EntirePool」および「FailingConnectionOnly」です。Java™ EE Connector Architecture (JCA) データ・ソースは、いずれかのオプションをもつことができます。WebSphere® バージョン 4.0 データ・ソースのパージ・ポリシーは常に、EntirePool です。

データ型 ストリング
デフォルト FailingConnectionOnly
範囲
EntirePool
プール内の接続は、すべて失効とマークされます。使用されていない接続は、直ちに閉じられます。 使用中の接続は閉じられ、その接続に次回操作が行われたときに StaleConnectionException がスローされます。アプリケーションからの後続の getConnection 要求の結果、 開かれているデータベースへの新規接続が発生します。 このパージ・ポリシーを使用しているときは、 プール内の一部の接続が、失効していない場合に不必要に閉じられる可能性が若干あります。 ただし、これはめったに起こりません。たいていの場合は、パージ・ポリシーを EntirePool に設定するのが最善の選択です。
FailingConnectionOnly
StaleConnectionException の発生原因である接続だけがクローズされます。この設定により、有効な接続が不必要に閉じられなくなる一方で、アプリケーション・パースペクティブからのリカバリーがより複雑になります。 現在失敗している接続だけが閉じられるため、 アプリケーションからの次の getConnection 要求により、 やはり失効したプールから接続が戻され、結果的により多くの失効接続の例外が 発生する可能性が極めて高くなります。



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

関連概念
関連タスク
関連資料
バージョン 5 WebSphere キュー接続ファクトリー設定


ファイル名: umj_sesspoolset.html