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

このページを使用して、アプリケーション・サーバーに高機能データ・ソース・プロパティーを設定します。これらのプロパティーは、 アプリケーション・サーバーがデータ・ソースに適用するサービスを活動化および構成し、 アプリケーション・サーバー内の接続をカスタマイズします。これらのプロパティーは、 データベース内の接続には影響しません。

この管理コンソール・ページにアクセスするには、以下のいずれかのパスを 実行します。
ステートメント・キャッシュ・サイズ

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

WebSphere® Application Server データ・ソースは、 準備済みステートメントおよび呼び出し可能ステートメントの処理を最適化するために、 アクティブな接続で使用されていないそれらのステートメントをキャッシュします。 どちらのタイプのステートメントも、 アプリケーションとデータ・ストア間のトランザクションのパフォーマンスを最大にするのに役立ちます。
  • 準備済みステートメントとはプリコンパイルされた SQL ステートメントで、PreparedStatement オブジェクトに 保管されています。アプリケーション・サーバーは このオブジェクトを使用して、アプリケーション・ランタイムの要求に応じて、ランタイムで判別された値を使用して SQL ステートメントを複数回実行します。
  • 呼び出し可能ステートメントとは、ストアード・プロシージャーへの呼び出しを含む SQL ステートメントです。 ストアード・プロシージャーは、タスクを実行し、結果を戻す、プリコンパイルされたステートメントのセットです。 このステートメントは、CallableStatement オブジェクトに保管されます。 アプリケーション・サーバーはこのオブジェクトを使用して、 アプリケーション・ランタイムの要求に応じて、ランタイムで判別された値を使用して、ストアード・プロシージャーを複数回実行します。

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

[AIX Solaris HP-UX Linux Windows] [iSeries] また、Tivoli® Performance Viewer を使用すると、キャッシュの廃棄数を最小化できます。着信 クライアント要求の標準数を表す標準のワークロード、固定の反復回数、および標準セットの構成設定値を使用します。
注: ステートメントのキャッシュが大きいほど、システム・リソースの遅延も大きくなります。したがって、 設定した値が大きすぎると、システムが複数の準備済みステートメントを開くことができないために、リソースが 不足することがあります。

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

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

データ型 整数
デフォルト デフォルト値はデータベースによって異なります。通常は 10 です。 Informix® のバージョン 7.3、9.2、9.3 および 9.4 で最新の修正を適用していない場合は、 デフォルト値を 0 にしてください。デフォルト値 0 は、キャッシュ・ステートメントが ないことを意味します。
マルチスレッド・アクセス検出を使用可能にする

このオプションにチェック・マークを付けると、アプリケーション・サーバーは複数のスレッドによるアクセスが ある場合にそれを検出します。

データベース再認証を使用可能にする

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

接続の再認証を使用すると、接続の開始および終了時のオーバーヘッドが削減されるため、 特にユーザー名とパスワードが異なる接続を頻繁に要求するアプリケーションでは、 パフォーマンスの向上が期待できます。
トラブルの回避 (Avoid trouble): 構成別名のマッピングに TrustedConnectionMapping を選択した場合、データベース再認証を使用可能にすることはできません。gotcha
JMS 1 フェーズ最適化サポートを使用可能にする

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

キャッシュ・ハンドルの管理

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

管理コンソールで「キャッシュ・ハンドルの管理」プロパティーを 選択してから選択解除すると、このフィールドは、バージョン 7.0 のアプリケーション・サーバーの リソースからは見えなくなります。 このフィールドは、resources.xml ファイルで manageCachedHandles プロパティーが true に 設定されている場合にのみ表示されます。このフィールドを選択できるようにするには、 resources.xml ファイルで manageCachedHandles エントリーの値を false から true に 変更するか、wsadmin ツールから以下の Jython コマンドを入力します。
AdminConfig.modify(myDataSourceVariable, '[[manageCachedHandles "true"]]')
サポートされる構成: バージョン 6.x のアプリケーション・サーバーで実行される リソースでは、「キャッシュ・ハンドルの管理」プロパティーは 常に表示されます。例えば、バージョン 6.1 のノードの場合、 resources.xml ファイルのこのエントリーは、このフィールドの管理コンソールでの表示方法には 影響を与えません。sptcfg
このほかに、マルチスレッドおよびクロス・コンポーネントの 診断アラートを使用して Java コネクター・アーキテクチャー (JCA) プログラミング・モデルでの 違反を検出する方法で問題をデバッグすることもできます。 このアラートを使用可能にするには、 「サーバー」 > 「アプリケーション・サーバー」 > application_server > 「パフォーマンス」 > 「パフォーマンスおよび診断アドバイザー構成」 > 「パフォーマンスおよび診断通知構成」パネルから、該当するオプションを選択します。このアラートによって、接続マネージャーが、 キャッシュ・ハンドルの管理、接続状態の検出、およびアラートの送信を行います。
注: このアラートを アクティブにするには、「サーバー」 > 「アプリケーション・サーバー」 > application_server > 「パフォーマンス」 > 「パフォーマンスおよび診断アドバイザー構成」パネルから、「パフォーマンスおよび診断アドバイザー・フレームワーク (ランタイム・パフォーマンス・アドバイザー) を使用可能にする」をも選択する必要があります。
トランザクション・コンテキストの欠落をログに記録

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

非トランザクション・データ・ソース
アプリケーション・サーバーがグローバル・トランザクションまたはローカル・トランザクションで、このデータ・ソースを使用して接続を取得しないことを指定します。 アプリケーションは接続でローカル・トランザクションを開始する場合、 接続の setAutoCommit(false) を明示的に呼び出す必要があり、 開始したトランザクションをコミットまたはロールバックする必要があります。
トラブルの回避 (Avoid trouble): このプロパティーを true に設定するのはまれな状況ですが、Java Persistence API (JPA) は JTA および非 JTA データ・ソースの両方を必要とします。gotcha
WebSphere Application Server 例外検査モデルを使用する

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

WebSphere Application Server 例外マッピング・モデルを使用する

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

サポートされる構成: このエラー検出モデルは、 JDBC バージョン 3.0 以前で機能します。sptcfg
新規接続の妥当性検査 (Validate new connections)

新しく作成されたデータベースへの接続を接続マネージャーがテストするかどうかを指定します。

再試行回数

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

再試行間隔

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

既存のプール接続の妥当性検査 (Validate existing pooled connections)

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

再試行間隔

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

JDBC ドライバーによる妥当性検査

アプリケーション・サーバーが JDBC ドライバーを使用して接続の妥当性検査を行うことを指定します。 このオプションを使用するには、JDBC プロバイダーは JDBC 4.0 以降をサポートする必要があります。

トラブルの回避 (Avoid trouble): Oracle データ・ソースの場合、 「JDBC ドライバーによる妥当性検査」は、 WebSphere Application Server データ・ソース・プロパティーのカスタム・プロパティーに validateNewConnectionTimeout プロパティーが追加された後にのみ、 管理コンソールに表示されます。 validateNewConnectionTimeout プロパティーは、 JDBC 4.0 ドライバー妥当性検査に使用され、管理コンソールを使用して指定できます。gotcha
タイムアウト
データベースへの接続 (新規の接続またはアプリケーション・サーバーによってプールされた接続) のテストに対してタイムアウトを秒単位で指定します。 検証前にタイムアウトの有効期限が切れた場合、接続は使用不能と見なされます。 再試行を構成した場合、タイムアウトの全ての値が各再試行に適用されます。 値が 0 の場合、JDBC ドライバーは妥当性検査の試行にタイムアウトを設定しません。
サポートされる構成: このオプションは、 JDBC 4.0 に準拠する JDBC ドライバーでのみ選択できます。sptcfg
SQL ストリングによる妥当性検査 (非推奨)

接続テストのためにアプリケーション・サーバーがデータベースに送信する SQL ステートメントを指定します。 パフォーマンスへの影響が少ない照会を使用してください。

異種プーリングでの get/use/close/connection パターンの最適化

アプリケーション・サーバーが get/use/close/connection パターンを使用することを指定します。これにより、アプリケーション・サーバーの接続プーリングは、同じトランザクション内の接続を共用することができます。 この最適化パターンによって、1 つのトランザクションの間、1 つの接続 (異なる接続プロパティーを使用する場合も含めて) を共用することが可能になります。

異種プーリング機能によって、データ・ソース定義を拡張することができるため、データ・ソースについて、異なるカスタム・プロパティーを指定したり、アプリケーションで非コア・プロパティーをオーバーライドしたりすることができます。

サポートされる構成: このフィールドは、DB2® データ・ソースでのみ使用可能です。sptcfg
「クライアント・リルートの再試行の間隔 (Retry interval for client reroute)」

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

サポートされる構成: このフィールドは、DB2 データ・ソースでのみ使用可能です。sptcfg
「クライアント・リルートの最大再試行数 (Maximum retries for client reroute)」

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

サポートされる構成: このフィールドは、DB2 データ・ソースでのみ使用可能です。sptcfg
代替サーバー名 (Alternate server names)
DB2 サーバーの 代替サーバー名のリストを指定します。複数の代替サーバー名を指定する場合、名前の間をコンマで区切る必要があります。以下に例を示します。
host1,host2
サポートされる構成: このフィールドは、DB2 データ・ソースでのみ使用可能です。sptcfg
代替ポート番号 (Alternate port numbers)
DB2 サーバーの 代替サーバーのポート (複数可) のリストを指定します。複数の代替サーバーのポートを指定する場合、 ポートをコンマで区切る必要があります。以下に例を示します。
5000,50001
サポートされる構成: このフィールドは、DB2 データ・ソースでのみ使用可能です。sptcfg
クライアント転送サーバー・リストの JNDI 名

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

サポートされる構成: このフィールドは、DB2 データ・ソースでのみ使用可能です。sptcfg
JNDI からのクライアント転送リストのアンバインド

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

サポートされる構成: このフィールドは、DB2 データ・ソースでのみ使用可能です。sptcfg



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

関連概念
関連タスク
関連資料
カスタム・プロパティー設定


ファイル名: udat_jdbcdatasorprops.html