WebSphere Application Server データ・ソース・プロパティー

接続ごとにキャッシュできるステートメントの数を指定します。 アプリケーション・サーバーは、ステートメントをクローズした後でキャッシュします。

ステートメントのキャッシュが十分な大きさではない場合は、有用なエントリーでも、新しいエントリーの余地を作るために廃棄されます。 どのキャッシュも廃棄されないようにするためのキャッシュ・サイズの最大値を判断するには、 特定のサーバー上のこのデータ・ソースを使用するアプリケーションごとに、SQL ストリング、並行性、およびスクロール・タイプによって決まる固有の準備済みステートメント および呼び出し可能ステートメントの数を追加します。この値は、サーバーの存続期間中、特定の 1 つの接続上にキャッシュできるステートメントの最大数です。キャッシュ・サイズをこの値に設定するということは、決してキャッシュ廃棄を行わないということです。一般的に、ステートメント数の多いアプリケーションには大きめのキャッシュを構成します。

また、Tivoli® Performance Viewer を使用すると、キャッシュの廃棄数を最小化できます。着信 クライアント要求の標準数を表す標準のワークロード、固定の反復回数、および標準セットの構成設定値を使用します。

注: ステートメントのキャッシュが大きいほど、システム・リソースの遅延も大きくなります。したがって、設定した値が大きすぎると、システムが複数の準備済みステートメントを開くことができないために、リソースが不足することがあります。

アプリケーション・サーバーがキャッシュに入れることが望ましくない特定のステートメントがある場合、そのステートメントのプール可能性ヒントを false に構成します。 アプリケーション・サーバーは、プール可能性ヒントが false に設定されていれるステートメントをキャッシュに入れません。アプリケーションはステートメントのプール可能性ヒントを実行時に指定します。

テスト・アプリケーションでは、ステートメントのキャッシュを調整することで、 スループットが 10% から 20% 改善されました。ただし、リソースに制限がある場合もあるため、このチューニング・プロセスが常に可能であるとは限りません。

チェックした場合、複数のスレッドが同じ接続ハンドルを同時に使用しようとすると、WebSphere Application Server システム・アウト・ログに以下の警告メッセージが書き込まれます。複数のスレッドが同一の接続ハンドルを使用しようとすることにより問題が発生した可能性があると考えられる場合は、このプロパティーを使用して、接続の問題をデバッグできます。複数のスレッドが同じ接続ハンドルを同時に使用することは、プログラミング・モデル違反です。

J2CA0167W: An attempt to concurrently use the same connection handle by multiple threads has been detected. The connection handle is: {0}.

アプリケーション・サーバーの接続プールから取得される接続と完全に一致する接続 (接続プールの検索条件にユーザー名とパスワードが含まれない接続) が使用できなくなります。代わりに、DataStoreHelper クラスの doConnectionSetupPerTransaction() で、 接続の再認証が行われます。アプリケーション・サーバーは、ランタイムには、 接続の再認証の実装を行いません。そのため、 このボックスにチェックを入れた場合は、DataStoreHelper クラスを拡張して doConnectionSetupPerTransaction() メソッドを実装し、このメソッドで 再認証を行う必要があります。このプロセスを完了しない場合、 アプリケーション・サーバーから使用できない接続が戻されることがあります。 詳しくは、API 文書の com.ibm.websphere.rsadapter.DataStoreHelper#doConnectionSetupPerTransaction メソッドを参照してください。

接続の再認証を使用すると、接続のオープンとクローズが減少するため、 さまざまなユーザー名とパスワードで接続を頻繁に要求するアプリケーションでは特に、 パフォーマンスが向上する効果があります。

トラブルの回避: 構成別名のマッピングに TrustedConnectionMapping を選択した場合、データベース再認証を使用可能にすることはできません。gotcha

このオプションにチェック・マークを付けると、アプリケーション・サーバーは、 Java Messaging Service (JMS) を使用して、このデータ・ソースからの最適化接続を取得します。このプロパティーを指定すると、 Java Database Connectivity (JDBC) アプリケーションが、コンテナー管理パーシスタンス (CMP) アプリケーションと接続を共有できなくなります。このオプションは、データ・ソースの JDBC プロバイダーが XA プロバイダーである場合は使用できません。

コンテナーがキャッシュ・ハンドルを追跡するかどうかを指定します。 キャッシュ・ハンドルは、トランザクション、およびメソッドの複数の境界にわたって アプリケーション・コンポーネントをアクティブに保持する接続ハンドルです。 このプロパティーを使用して接続の問題をデバッグできますが、 ハンドルを追跡するので、実行時に大きなパフォーマンス問題が生じる可能性があります。

AdminConfig.modify(myDataSourceVariable, '[[manageCachedHandles "true"]]')

アプリケーションがトランザクション・コンテキストなしで接続を取得したときに、 コンテナーがアクティビティー・ログにエントリーを送出するかどうかを指定します。 これらは Java Platform, Enterprise Edition (Java EE) プログラミング・モデル接続要件の例外です。

アプリケーション・サーバーが、エラーを特定するためにデータ・ストア・ヘルパーに 定義されたエラー・マッピング機能を使用することを指定します。 アプリケーション・サーバーは、JDBC ドライバーによってスローされた例外を、 データ・ストア・ヘルパーのエラー・マップに定義された例外で置換しません。

アプリケーション・サーバーが、エラーを特定するためにデータ・ストア・ヘルパーに定義されたエラー・マッピング機能を使用することを指定します。アプリケーション・サーバーは、JDBC ドライバーによってスローされた例外を、データ・ストア・ヘルパーのエラー・マップに定義された例外で置換します。

接続マネージャーが、データベースに対して新規に作成された接続をテストするかどうかを指定します。

最初の事前テスト処理が失敗した後、データベースへの初期接続を再試行する回数を指定します。

「新規接続の妥当性検査 (Validate new connections)」を選択する場合は、このオプションで、 アプリケーション・サーバーが最初の接続に失敗してから接続を再試行するまでの 待機時間を秒数で指定します。

プール接続をアプリケーションに返す前に、接続マネージャーがプール接続の妥当性をテストするかどうかを指定します。

「既存プール接続の事前テスト (Pretest existing pooled connections)」を選択した場合は、このオプションで、 接続の妥当性検査のために JDBC ドライバーに割り振る時間を秒数で 指定します。

アプリケーション・サーバーが JDBC ドライバーを使用して接続の妥当性検査を行うことを指定します。このオプションを使用する場合は、JDBC プロバイダーが JDBC 4.0 以降をサポートしている必要があります。このオプションは、「新規接続の検証 (Validate new connections)」または「既存プール接続の検証 (Validate existing pooled connections)」のどちらかが選択されている場合のみ使用可能です。

トラブルの回避: Oracle データ・ソースの場合、「JDBC ドライバーによる検証 (Validation by JDBC Driver)」は、validateNewConnectionTimeout プロパティーを データ・ソースのカスタム・プロパティーに追加した場合にのみ、管理コンソールに表示されます。validateNewConnectionTimeout プロパティーは JDBC 4.0 ドライバーの妥当性検査に使用されます。このプロパティーは、管理コンソールを使用して指定できます。gotcha

接続テストのためにアプリケーション・サーバーがデータベースに送信する SQL ステートメントを指定します。パフォーマンスへの影響が少ない照会を使用してください。このオプションは、「新規接続の検証 (Validate new connections)」または「既存プール接続の検証 (Validate existing pooled connections)」のどちらかが選択されている場合のみ使用可能です。

「取得/使用/クローズ」接続パターンを使用するアプリケーション に対してデータ・ソースを最適化します。この最適化によって、 データ・ソース用の接続プールは、同じトランザクション内の接続を共有 することが可能になります。この最適化パターンでは、 異なる接続プロパティーを使用している複数の接続がある場合でも、1 つのトランザクション中に、1 つの接続を 共有することができます。

異種プール機能を使用する場合、最初にデータ・ソース定義を 拡張する必要があります。これによって、異なるカスタム・プロパティー またはアプリケーションを指定して、データ・ソースの非コア・プロパティーをオーバーライド できるようになります。データ・ソースの拡張 について詳しくは、アプリケーション・レベルでの DB2 データ・ソース定義の拡張に関する 説明を参照してください。

自動クライアント・リルートの再試行の間隔の時間 (秒単位) を指定します。

サーバーへの 1 次接続に失敗した場合の、自動クライアント・リルート機能 によって試行される接続の再試行の最大回数を指定します。このプロパティー は、「クライアント・リルートの再試行の間隔 (Retry interval for client reroute)」が設定されている場合にのみ使用されます。

JNDI 名前空間に DB2 クライアント転送サーバー・リストをバインドするのに使用する JNDI 名を指定します。 DB2 データベース・サーバーでは、この名前を使用して、代替サーバーの情報がメモリーにまだない場合に、代替サーバー名を検索します。このオプションは、タイプ 2 のデータ・ソースではサポートされません。

テスト接続でのみ使用されます。true に設定すると、クライアント転送サーバー・リスト JNDI 名は、テスト接続の開始後に JNDI 名前空間からアンバインドされます。