WebSphere Application Server Network Deployment, Version 6.1   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

接続プール

接続プールは、接続管理のオーバーヘッドを軽減し、 データ・アクセスの開発タスクを削減するのに役立ちます。

アプリケーションは、 バックエンド・ストア (データベースなど) にアクセスしようとするたびに、 リソースがそのデータ・ストアへの接続を作成、保守、および解除するように要求します。 このプロセスによってアプリケーション・リソース全体にかかる負荷を軽減するために、 Application Server では、 アプリケーション・サーバー上でアプリケーションが共用可能なバックエンド接続のプールを 管理者が設定できるようにしています。接続のプール は複数のユーザー要求の間に接続オーバーヘッドを広げ、それによって、 将来の要求のためのアプリケーション・リソースを保護します。

Application Server は、接続のプールおよび接続再利用で JDBC 3.0 API をサポートしています。接続プールは、アプリケーション内での直接の JDBC 呼び出しに使用されるとともに、 データベースを使用するエンタープライズ Bean にも使用されます。

接続プールの利点

接続プールにより、接続を必要とするアプリケーション、 特に Web ベース・アプリケーションの応答時間を改善することができます。 ユーザーが Web 上でリソースに要求を行うと、そのリソースはデータ・ソースにアクセスします。 ユーザーはインターネット上のアプリケーションに対して頻繁に接続と切断を繰り返すため、 データ・アクセスへのアプリケーション要求のボリュームがかなり大きくなる場合があります。 その結果、データ・ストア・オーバーヘッドの合計が Web ベース・アプリケーションにとって急激に大きくなり、 パフォーマンスが低下します。接続プール機能を使用すると、 Web アプリケーションで、標準の結果の最大で 20 倍のパフォーマンス向上を実現できます。

接続プールを使用すると、データ・ソースは接続プールから既存の接続を探し出してそれを使用できるので、 ほとんどのユーザー要求では、新規接続を作成する場合のオーバーヘッドが発生することはありません。 要求が満たされ、応答がユーザーに戻されると、 リソースはその接続を接続プールに戻して再使用に備えます。 切断のオーバーヘッドは発生しません。個々のユーザー要求により、 わずかながら接続または切断の負荷がかかります。 初期リソースを使用してプールに接続を生成しておけば、 既存の接続が再使用されるので、 追加のオーバーヘッドはわずかですみます。

接続プールを使用する場合

WebSphere 接続プールは、以下の基準のいずれかを満たすアプリケーションで使用します。

接続をプールする方法

固有のデータ・ソースまたは接続ファクトリーを構成する場合は、 固有の Java Naming and Directory Interface (JNDI) 名を指定する必要があります。 この JNDI 名は、その構成情報と共に、接続プールを作成するために使用されます。 構成されるデータ・ソースまたは接続ファクトリーごとに、 個別の接続プールが存在します。

さらに、Application Server は、 データ・ソースまたは接続ファクトリーを使用する アプリケーション・サーバーごとに、 接続プールの個別インスタンスを作成します。 以下に例を示します。
  • すべてのサーバーが、myDataSource を使用する 3 つのサーバー・クラスターを実行していて、かつ myDataSource の最大接続数の設定が 10 になっている場合、 最大で 30 個の接続 (3 つのサーバー x 10 個の接続) を生成できます。

バックエンド・リソースがサポートできる接続数に、 このような動作がどの程度影響を与えるかを検討してください。 詳しくは、接続プール設定 を参照してください。

最大接続数の設定を決定する場合のその他の考慮事項:
  • それぞれのエンティティー Bean トランザクションには、 トランザクション処理専用の、追加のデータベース接続が必要です。
  • クローンを使用する場合、各クローンに対して 1 つのデータ・プールが存在します。
  • [AIX] [HP-UX] [Solaris] サポート対象の UNIX プラットフォームでは、 各接続ごとに個別の DB2 プロセスが作成されます。 これらのプロセスは、 メモリーの少ないシステムのパフォーマンスに直ちに影響を与えるので、 エラーの原因となります。

接続の共用 を使用する際には、 同じ接続プールから取得した接続しか共用できないという点に注意することも重要です。

デッドロックの回避

アプリケーションが、スレッドごとに複数の同時接続を必要とし ており、かつデータベース接続プールがそのスレッド数に十分な大きさでない場合、デッドロックが発生する可能性があります。 アプリケーション・スレッドが、それぞれ 2 つの同時データベース接続を必要とし ており、スレッド数は最大接続プール・サイズと等しいと仮定します。 次の両方の条件が満たされると、デッドロックが発生します。
  • 各スレッドが最初のデータベース接続を行い、 すべての接続が使用中になる。
  • 各スレッドが 2 番目のデータベース接続を待機しているが、すべてのスレッドがブロックされているために、どの接続も使用可能にならない。
この場合、デッドロックを防止するには、データベース接続プールの最大接続数の値を少なくとも 1 つ上げる必要があります。これを行うことにより、待機中のスレッドの少なくとも 1 つがその 2 番目のデータベース接続を獲得して、デッドロックを回避できます。
デッドロックを回避するには、スレッド当たり多くても 1 つの接続を使用するよ うにアプリケーションをコーディングします。 スレッド当たり C 個の同時データベース接続を要求するようにアプリケーションをコーディングする場合、接続プールは少なくとも以下の接続数をサポートする必要があります。ここで、T はスレッドの最大数です。
 T * (C - 1) + 1 
接続プールの設定値は、データベース・サーバーがサポートするように構成されている接続の数に、直接関係しています。
プール内の接続の最大数を上げて、 データベース内の対応する設定値を上げない場合、アプリケーションに障害が起こり、以下のロケーションに SQL 例外エラーが表示されます。
  • stderr.log ファイル



サブトピック
据え置き enlist
接続および接続プール統計
関連概念
共用不可能接続および共用可能接続
データ・ソース
トランザクション・タイプおよび接続の振る舞い
関連タスク
wsadmin ツールによる接続プール設定の変更
アプリケーション内のリソース・アダプターの接続ファクトリーの構成
管理コンソールにおける J2EE コネクター接続ファクトリーの構成
関連資料
アプリケーション・サービス提供環境のチューニング
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 7:44:53 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cdat_conpool.html