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

手順
- 接続のデッドロックを防止します。 アプリケーションが、スレッドごとに複数の同時接続を必要とし ており、かつデータベース接続プールがそのスレッド数に十分な大きさでない場合、デッドロックが発生する可能性があります。 アプリケーション・スレッドが、それぞれ 2 つの同時データベース接続を必要とし ており、スレッド数は最大接続プール・サイズと等しいと仮定します。 次の両方の条件が該当する場合、デッドロックが発生する可能性があります。
- 各スレッドが最初のデータベース接続を行い、 すべての接続が使用中になる。
- 各スレッドが 2 番目のデータベース接続を待機しているが、すべてのスレッドがブロックされているために、どの接続も使用可能にならない。
この場合、デッドロックを防止するには、データベース接続プールの最大接続数の値を 少なくとも 1 増やします。こうすることで、 待機中のスレッドの少なくとも 1 つが 2 番目のデータベース接続を取得できるので、 デッドロック・シナリオを回避できます。
一般に接続デッドロックを防止するには、アプリケーションが スレッドごとに接続を 1 つだけ使用するようにコーディングします。スレッド当たり C 個の 同時データベース接続を要求するようにアプリケーションをコーディングする場合は、 接続プールが少なくとも以下の接続数をサポートする必要があります。 ここで、T はスレッドの最大数です。T * (C - 1) + 1
接続プールの設定値は、データベース・サーバーがサポートするように構成されている接続の数に、直接関係しています。 プール内の接続の最大数を増やしても、それに合わせてデータベース内の対応する設定を大きくしなければ、 アプリケーションに障害が起こる場合があります。その結果発生する SQL 例外エラーは、 以下の場所に表示されます。接続デッドロックの最も一般的な原因の 1 つとして、サーブレットが直接または間接的に Bean を呼び出す場合に、サーブレットと Enterprise JavaBeans (EJB) の両方で同じ接続プールを使用していることが考えられます。例えば、接続プールから JMS 接続を取得するサーブレットの場合、メッセージをメッセージ駆動型 Bean (MDB) に送信して応答を待ちます。 この MDB は同じ接続プールをサーブレットとして使用するように構成されているため、MDB から応答をサーブレットに送信する場合にプールからの別の接続が必要になります。サーブレットとエンタープライズ Bean は同じ接続プールを共有しません。これは、並行 (C) スレッドの典型的な例です。ここで C は 2 を表し、T はサーブレットと EJB スレッド・プールの最大サイズを表します。stderr.log ファイル
サーバントの SYSOUT
- 接続のプールを使用不可にします。
- リレーショナル・リソース・アダプター (RRA) では、
ご使用のデータ・ソースに適した disableWASConnectionPooling カスタム・プロパティーを追加します。
- 「JDBC」>「データ・ソース」をクリックします。
- 構成するデータ・ソースの名前をクリックします。
- 「追加プロパティー」見出しの下の「カスタム・プロパティー」を クリックします。
- 「新規」をクリックします。
- 必須フィールドに以下の情報を入力します。
- 名前: disableWASConnectionPooling
- 値: true
- 他のリソース・アダプターの場合は、そのリソース・アダプターの
バインディング仕様に従って、アプリケーションで接続プーリングを使用不可にするように
構成してください。
- プログラムで、リソース・アダプターによる接続プーリングを使用不可にします。
- アプリケーション・サーバーは、以下のコードを活用して javax.resource.NotSupportedException 例外を検出し、
接続プーリングを使用不可にします。
_managedFactory.matchManagedConnections(s,subject,cri); // 169059 174269 } catch(javax.resource.NotSupportedException e){
- リレーショナル・リソース・アダプター (RRA) では、
ご使用のデータ・ソースに適した disableWASConnectionPooling カスタム・プロパティーを追加します。
- 据え置き enlist を使用可能にします。
アプリケーション・サーバー環境で、据え置き enlist とは、 接続が使用されてアプリケーションの作業単位 (UOW) 有効範囲に接続が登録されるまで アプリケーション・サーバーが待機する手法のことです。
次の据え置き enlist の図を検討してください。- 据え置き enlist を使用するアプリケーション・コンポーネントは、 グローバル・トランザクション内から getConnection メソッドを呼び出します。
- アプリケーション・コンポーネントは、この接続をすぐには使用しません。
- この接続を最初に使用するための呼び出しをアプリケーションが行うと、 トランザクション・マネージャーがその呼び出しをインターセプトします。
- トランザクション・マネージャーは、接続用の XA リソースを 登録し、XAResource.start メソッドを呼び出します。
- XA リソースに関連した接続マネージャーが、 データベースに呼び出しを送信します。
据え置き enlist により、取得した接続が UOW のスコープで 使用されない場合のパフォーマンスが向上します。 この手法により、参加が発生する必要がある UOW までの トランザクション参加のコストが節約されます。
使用するリソース・アダプターに この機能があるかどうかを調べる必要がある場合は、 リソース・アダプターのプロバイダーに確認してください。 アプリケーション・サーバーのリレーショナル・リソース・アダプターは、据え置き enlist を自動的にサポートします。
据え置き enlist のコードへの取り込み
Java™ Platform, Enterprise Edition (Java EE) コネクター・アーキテクチャー (JCA) バージョン 1.5 以降の仕様では、 据え置き enlistment の手法を、トランザクションの lazy enlistment 最適化と呼んでいます。このサポートは、以下に示すマーカー・インターフェース (LazyEnlistableManagedConnection) および接続マネージャーの メソッド (LazyEnlistableConnectionManager()) により実現されます。package javax.resource.spi; import javax.resource.ResourceException; import javax.transaction.xa.Xid; interface LazyEnlistableConnectionManager { // application server void lazyEnlist(ManagedConnection) throws ResourceException; } interface LazyEnlistableManagedConnection { // resource adapter }
- 接続プールの共有を制御します。 defaultConnectionTypeOverride または globalConnectionTypeOverride 接続プール・カスタム・プロパティー を特定の接続ファクトリーまたはデータ・ソースに使用して、 接続の共有を制御できます。
- defaultConnectionTypeOverride プロパティーは、接続プールのデフォルトの共有値を変更します。このプロパティーを使用することで、接続の共有を制御し、直接照会を行うことができます。このデータ・ソース または接続ファクトリーに対してリソース参照が構成されている場合、リソース参照の構成 が defaultConnectionTypeOverride プロパティー設定よりも優先されます。 例えば、アプリケーションが直接照会を行い、非共有の接続が必要な場合には、defaultConnectionTypeOverride プロパティーを unshared に設定してください。
- globalConnectionTypeOverride カスタム・プロパティーに指定される値は、他のすべての接続共有設定よりも優先されます。例えば、このプロパティーを unshared に 設定すると、直接照会とリソース参照検索の両方で、すべての接続要求は非共有になります。このプロパティーを使用すると、 ある特定のデータ・ソースまたは接続ファクトリーのすべての接続を非共有または 共有に変更した場合の結果を、リソース参照設定を変更せずに簡単に テストできます。
defaultConnectionTypeOverride プロパティーと globalConnectionTypeOverride プロパティーの 両方の値を指定した場合、globalConnectionTypeOverride プロパティーの 値のみが接続共有タイプの決定に使用されます。
これらの新規カスタム・プロパティーを、データ・ソースまたは接続ファクトリーの接続プールの設定に追加するには、新規接続プール・カスタム・プロパティーを作成する必要があります。これらのプロパティーの 1 つをデータ・ソースに追加するには、管理コンソールを使用します。「リソース」 > 「JDBC」 > 「データ・ソース」とクリックします。 リストからデータ・ソースを選択し、「追加プロパティー」 > 「接続プール・プロパティー」 > 「接続プール・カスタム・プロパティー」 > 「新規」をクリックします。他の J2C 接続ファクトリーまたは JMS 接続ファクトリーを使用する場合は、管理コンソールで接続ファクトリー定義に移動します。次に、「追加プロパティー」 > 「接続プール」 > 「接続プール・カスタム・プロパティー」 >「新規」と選択します。その後、「名前」フィールドで defaultConnectionTypeOverride または globalConnectionTypeOverride を指定し、「値」フィールドで shared または unshared を指定します。重要: プロパティーは、データ・ソースまたは接続ファクトリーの一般的な「カスタム・プロパティー」ではなく、「接続プールのカスタム・プロパティー」で設定する必要があります。 構成されたリソース・マネージャーへの接続を接続プールが確立できない場合、 軽減アクションを自動的に実行します。
failureNotificationActionCode プロパティー と failureThreshold プロパティーを使用して接続プールを構成することによって、 接続ファクトリーがそれに対して構成されているリソース・マネージャーへの接続を確立できない場合に、 その障害によるエンド・ユーザーへの影響を最小限にするため、自律型の軽減アクション が WebSphere® Application Server for z/OS® ランタイムによって実行 されるようにできます。接続ファクトリーがそれに対して構成されたリソース・マネージャーへの 接続を再確立できると、自律型軽減アクションは リバースされます。このタイプの軽減アクションの一例 は、障害が起こったリソースのあるサーバーに対してランタイムが「pause listeners」コマンド を発行して、新しい作業がそのサーバーで受け入れられないようにすること です。高可用性フロントエンドと組み合わせると、 新しい作業をクラスター内の他のサーバーに転送することが可能です。
特定の接続ファクトリーまたはデータ・ソースが、障害しきい値に指定された値またはデフォルト値に達した場合、 通知が z/OS ランタイムに 送付されます。障害通知には、ランタイムがこの障害通知に どのように応答するのかを決定する、構成されたアクション・コード が含まれます。アクション・コード定義について詳しくは、 『接続プールのカスタム・プロパティー』トピックを参照してください。
これらのプロパティーを使用する には、接続プールの新しいカスタム・プロパティーとしてこれらのプロパティーを定義 する必要があります。これを行うには、管理コンソールで、 「JDBC プロバイダー」 > 「データ・ソース」 >「接続プール」 > 「カスタム・プロパティー」 > 「新規」とクリックします。 次に、「名前」フィールドに failureNotificationActionCode または failureNotification を 指定し、「値」フィールドに適切な値を指定します。
これらのカスタム・プロパティーの設定について 詳しくは、『接続プールのカスタム・プロパティー』トピックを 参照してください。
- 接続を廃棄します。
サーバント領域がアイドルである場合、リープ時間および未使用のタイムアウト設定によって、アイドル状態または未使用の接続は廃棄されません。この状態では、一部の DB2 接続が必要以上に長く保持されることになる可能性があります。
リーパー時間と未使用タイムアウト設定の組み合わせによって指定された時刻に接続が廃棄されるようにしたい場合 (この設定によってアイドルなサーバント領域が再度アクティブになる可能性があるとしても)、nondeferredreaper カスタム・プロパティーを JDBC ドライバー・プロバイダーのデータ・ソース設定に追加することができます。このカスタム・プロパティーを追加すると、リーパー時間と未使用タイムアウト設定の組み合わせによって指定された時刻に接続が廃棄されます。
このカスタム・プロパティーを JDBC ドライバー・プロバイダーのデータ・ソース設定に追加するには、管理コンソールで「リソース」 > 「JDBC プロバイダー」 > 「DB2 Universal JDBC Driver Provider」 > 「データ・ソース」 > 「data_source」 > 「カスタム・プロパティー」 > 「新規」とクリックします。次に、「名前」フィールドに nondeferredreaper、 「値」フィールドに true、「タイプ」フィールドに java.lang.Boolean を 指定します。この新しい設定は、このデータ・ソースを使用しているサーバーを再始動するまで、有効になりません。
トラブルの回避 (Avoid trouble): 未使用の接続を廃棄する目的のためにのみアイドルなサーバント領域をアクティブにすると、余分な (場合によっては望ましくない) CPU 使用量が発生する可能性があります。また、以下の警告メッセージがログに記録される場合がありますが、無視してください。
gotchaDSRA8200W: DataSource Configuration: DSRA8020E: Warning: The property 'nondeferredreaper' does not exist on the DataSource classcom.ibm.db2.jcc.DB2ConnectionPoolDataSource.
- パージ・ポリシーに基づいて、接続プールを
パージします。
接続プール・エラー検出モデルが例外マッピングに 構成されている場合、接続がもう有効ではないことを失効接続例外が 示します。
一般的に、例外マッピング処理の 結果として StaleConnectionException (失効接続例外) になると、 接続エラー・イベントが発生し、それに続いて接続プール がパージされます。しかし、このケースでは、SCE がインスタンス化されていて、 既存のコードには接続エラー・イベントを発生させる機能がないため、プールはパージされず、新規接続の要求時に接続がデータベース側で終了すると ドライバーが XAException をスローします。errorDetectionModel=ExceptionMapping と 設定されていると、ConnectionErrorEvent が発生して、接続プールはパージ・ポリシーに基づいてパージ されます。
このカスタム・プロパティーを JDBC ドライバー・プロバイダーのデータ・ソース設定に追加するには、管理コンソールで「リソース」 > 「JDBC プロバイダー」 > 「DB2 Universal JDBC Driver Provider」 > 「データ・ソース」 > 「data_source」 > 「カスタム・プロパティー」 > 「新規」とクリックします。次に、「名前」フィールドに fireCEEventOnSCE、 「値」フィールドに true、「タイプ」フィールドに java.lang.Boolean を 指定します。この新しい設定は、このデータ・ソースを使用しているサーバーを再始動するまで、有効になりません。
WebSphere RRA コードが変更され、errorDetection モデルとして ExceptionMapping を使用している場合、 StaleConnectionException の発生時にプールが正しくパージされるようになりました。
サブトピック


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_conpoolman
ファイル名:tdat_conpoolman.html