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

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

この管理コンソール・ページにアクセスするには、以下のいずれかのパスを 実行します。
  • 「リソース」 > 「JDBC」 > 「データ・ソース」 > 「data_source」 > 「WebSphere Application Server データ・ソース・プロパティー」
  • 「リソース」 > 「JDBC」 > 「JDBC プロバイダー」 > 「JDBC_provider」 > 「データ・ソース」 > 「data_source」 > 「WebSphere Application Server データ・ソース・プロパティー」
  • 「アプリケーション」 > 「アプリケーション・タイプ」 > 「WebSphere エンタープライズ・アプリケーション」 > application_name > 「アプリケーション有効範囲リソース」 > data_source > 「WebSphere Application Server データ・ソース・プロパティー」

ステートメント・キャッシュのサイズ

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

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

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

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

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

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

通知
データ型 整数
デフォルト デフォルト値はデータベースによって異なります。通常は 10 です。 最新のフィックスが適用されていない Informix® バージョン 7.3、9.2、9.3、および 9.4 の場合は、デフォルト値を 0 にする必要があります。デフォルト値 0 は、キャッシュ・ステートメントがないことを意味します。

マルチスレッド・アクセス検出を使用可能にする

これにチェック・マークが付けられた場合は、複数のスレッドが同じ接続ハンドルを同時に使用しようとすると、以下の警告メッセージの 1 つまたは両方が WebSphere Application Server システム出力ログに入力されます。複数のスレッドが同一の接続ハンドルを使用しようとすることにより問題が発生した可能性があると考えられる場合は、このプロパティーを使用して、接続の問題をデバッグできます。複数のスレッドが同じ接続ハンドルを同時に使用することは、プログラミング・モデル違反です。
注: 正確な処理状況に基づいて、管理された接続を使用した場合に メッセージ J2CA0167W または DSRA8720W (あるいは両方のメッセージ) が発行されることがあります。マルチスレッド・アクセス検出を使用可能にするが有効になっている場合、ジョブ・ログを調べてこれらのメッセージがないか確認してください。

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

DSRA8720W: {0} でマルチスレッド・アクセスが検出されました。最後にスレッド ID {1} でマルチスレッド・アクセスが使用されました。現行スレッド ID: {2}。現行スレッドのスタック・トレース: {3}

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

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

接続の再認証を使用すると、接続のオープンとクローズが減少するため、 さまざまなユーザー名とパスワードで接続を頻繁に要求するアプリケーションでは特に、 パフォーマンスが向上する効果があります。
トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 構成別名のマッピングに TrustedConnectionMapping を選択した場合、データベース再認証を使用可能にすることはできません。gotcha

JMS 1 フェーズ最適化サポートを使用可能にする

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

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

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

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

トランザクション・コンテキストの欠落をログに記録

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

非トランザクション・データ・ソース

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

WebSphere Application Server 例外検査モデルの使用

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

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

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

注: このエラー検出モデルは、 JDBC バージョン 3.0 以前で機能します。

新規接続の妥当性検査 (Validate new connections)

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

再試行回数

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

再試行間隔

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

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

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

再試行間隔

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

JDBC ドライバーによる妥当性検査 (Validation by JDBC driver)

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

タイムアウト

データベースへの接続 (新規の接続またはアプリケーション・サーバーによってプールされた接続) のテストのタイムアウトを秒単位で指定します。 検証前にタイムアウトになった場合、接続は使用不可であるとみなされます。再試行を構成した場合、タイムアウトの全ての値が各再試行に適用されます。値が 0 の場合、JDBC ドライバーは妥当性検査の試行にタイムアウトを設定しません。
注: このオプションは、 JDBC 4.0 に準拠する JDBC ドライバーでのみ選択できます。

SQL ストリングによる妥当性検査 (非推奨)

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

異種プールでの「取得/使用/クローズ」接続パターンの最適化

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

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

注: このフィールドは、DB2® データ・ソースにのみ使用可能です。

「クライアント・リルートの再試行の間隔 (Retry interval for client reroute)」

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

注: このフィールドは、DB2 データ・ソースにのみ使用可能です。

「クライアント・リルートの最大再試行数 (Maximum retries for client reroute)」

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

注: このフィールドは、DB2 データ・ソースにのみ使用可能です。

代替サーバー名 (Alternate server names)

DB2 サーバーの 代替サーバー名のリストを指定します。複数の代替サーバー名を指定する場合、 名前をコンマで区切る必要があります。以下に例を示します。
host1,host2
注: このフィールドは、DB2 データ・ソースにのみ使用可能です。

代替ポート番号 (Alternate port numbers)

DB2 サーバーの 代替サーバーのポート (複数可) のリストを指定します。複数の代替サーバーのポートを指定する場合、 ポートをコンマで区切る必要があります。以下に例を示します。
5000,50001
注: このフィールドは、DB2 データ・ソースにのみ使用可能です。

クライアント転送サーバー・リスト JNDI 名

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

注: このフィールドは、DB2 データ・ソースにのみ使用可能です。

JNDI からのクライアント転送リストのアンバインド

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

注: このフィールドは、DB2 データ・ソースにのみ使用可能です。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=udat_jdbcdatasorprops
ファイル名:udat_jdbcdatasorprops.html