データ・ソース設定

このページを使用して、 特定の JDBC ドライバー・インプリメンテーション・クラスを提供する JDBC プロバイダーの下にデータ・ソースを作成します。

バージョン 5.0 のデータ・ソースを使用する必要があるか確認してください。 Enterprise JavaBean コンポーネント・モデル・バージョン 1.0、 および Servlets 2.2 を使用している場合は、バージョン 4.0 データ・ソースを 使用しなければなりません。

この管理コンソール・ページを表示するには、「 リソース」>「JDBC プロバイダー」>「JDBC_provider」>「データ・ソース」>「data_source」をクリックします。

「構成」タブ

有効範囲
このリソース定義を可視にするレベル (セル、ノード、またはサーバーの 各レベル) を指定します。

JDBC プロバイダー、ネーム・スペース・バインディング、 共用ライブラリーなどのリソースを複数の有効範囲で定義することが可能です。 より限定的な有効範囲で定義されたリソースは、 それより広い有効範囲で定義された重複するリソースをオーバーライドします。

定義済みリソースの有効範囲が何であれ、そのリソースのプロパティーは 個々のサーバー・レベルでのみ適用されることに注意して下さい。 例えば、あるデータ・ソースの有効範囲を「セル」レベルで定義する場合、 そのセルのすべてのユーザーが、そのデータ・ソースをルックアップおよび使用できます。 このとき、そのデータ・ソースはそのセル内で固有です。ただし、リソース・プロパティーの設定値は、そのセル内の各サーバーに対してローカルです。例えば、最大接続数 を 10 に設定する場合、そのセル内の 各サーバーは 10 個の接続を使用できます。

セル
最も一般的な有効範囲です。「セル」有効範囲で定義されている リソースは、オーバーライドされない限り、すべてのノードおよびサーバーから可視です。 「セル」有効範囲で定義されたリソースを表示する場合は、 有効範囲選択フォームでサーバーまたはノードの名前を指定しないでください。
ノード
大部分のリソース・タイプのデフォルト有効範囲。 「ノード」有効範囲で定義されたリソースは、「 セル」有効範囲で定義されたすべての重複するリソースをオーバーライドします。 同じノード上の「サーバー」有効範囲でオーバーライドされない限り、 そのノード上のすべてのサーバーから可視です。 「ノード」有効範囲で定義されたリソースを表示する場合は、 有効範囲選択フォームで、サーバーを指定せず、ノード名を選択します。
サーバー
リソース定義で最も限定的な有効範囲です。「サーバー」 有効範囲で定義されたリソースは、「セル」有効範囲または親の「ノード」有効範囲で 定義されたすべての重複するリソース定義をオーバーライドし、 特定のサーバーからのみ可視です。 「サーバー」有効範囲で定義されたリソースを表示するには、 有効範囲選択フォームで、ノード名だけでなくサーバー名も指定します。

リソースが作成されるときは常に、パネルで選択されている現行の有効範囲内に 作成されます。 他の有効範囲でリソースを表示する場合は、有効範囲選択フォームで、 別のノードまたはサーバーを指定します。

データ型 ストリング
名前
データ・ソースの表示名を指定します。

例えば、このフィールドを Test Data Source に設定することができます。

データ型 ストリング
JNDI 名
Java Naming and Directory Interface (JNDI) 名を指定します。

分散コンピューティング環境では、共用コンポーネントおよびリソースを 取得するために、ネーミングおよびディレクトリー・サービスを頻繁に使用 します。ネーミング・サービスおよびディレクトリー・サービスは、名前を ロケーション、サービス、情報、およびリソースと関連付けます。

ネーミング・サービスは、名前からオブジェクトへのマッピングを行います。 ディレクトリー・サービスは、 オブジェクトに関する情報と、それらのオブジェクトを探し出すのに必要な検索ツールを提供します。

ネーミングおよびディレクトリー・サービスのインプリメンテーションの数は多く、 そのインターフェースもさまざまです。JNDI は、 各種のネーミング・サービスおよびディレクトリー・サービスへのアクセスに使用する 共通インターフェースを提供します。

例えば、jdbc/markSection という名前を使用することができます。

このフィールドをブランクにしておくと、データ・ソースの名前から JNDI 名が生成されます。 例えば、データ・ソース名 markSection からは、JNDI 名 jdbc/markSection が生成されます。

この値を設定し、保管し、サーバーを再始動した後に dumpnamespace を実行すると、 このストリングを表示することができます。

データ型 ストリング
コンテナー管理パーシスタンス
このデータ・ソースが Enterprise Bean のコンテナー管理パーシスタンスに 使用されるかどうかを指定します。

チェック・ボックスが選択されている場合、このデータ・ソース に対応する CMP コネクター・ファクトリーが、リレーショナル・リソース・アダプター用に 作成されます。

データ型 チェック・ボックス
デフォルト チェックマークなし
説明
リソースを説明するテキストを指定します。
データ型 ストリング
カテゴリー
リソースを分類またはグループ化するために使用できるカテゴリー・ストリングを指定します。
データ型 ストリング
ステートメントのキャッシュ・サイズ
接続ごとにキャッシュされるフリーのステートメントの数を指定します。

WebSphere Application Server データ・ソースは、準備済みステートメントの処理を最適化します。 準備済みステートメントとは、準備済みステートメント・オブジェクト内に保管される、プリコンパイルされた SQL ステートメントです。 このオブジェクトは、所定の SQL ステートメントを効率的に複数回実行するために使用します。

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

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

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

データ型 整数
デフォルト データベースにより異なります。たいていの場合は 10 です。 また、最新の修正を行っていない Informix Version 7.3、9.2、または 9.3 では、0 にする必要 があります。デフォルトが 0 ということは、キャッシュ・ステートメントがないことを 意味します。
データ・ソース・ヘルパー・クラス名
データベース固有の機能を実行するために使用されるデータ・ストア・ヘルパーを指定します。

これは、リレーショナル・リソース・アダプターが実行時に使用します。 デフォルトの DataStoreHelper インプリメンテーション・クラスは、JDBC ドライバー・ インプリメンテーション・クラスに基づいて設定されます。このとき使用される 構造は、com.ibm.websphere.rsadapter.<database>DataStoreHelper です。 例えば、JDBC プロバイダーが DB2 である場合、 デフォルトの DataStoreHelper クラスは、com.ibm.websphere.rsadapter.DB2DataStoreHelper です。必要に応じて、この DataStoreHelper のサブクラスに変更することができます。

データ型 ストリング
デフォルト JDBC ドライバー・インプリメンテーション・クラスによって異なります
コンポーネント管理認証エイリアス
このエイリアスは実行時のデータベース認証に使用されます。

リソース認証 (res-auth) が「アプリケーション」に設定されている場合は、「 Component-managed Authentication Alias」にエイリアスを設定します。

このフィールドを設定せず、しかもデータベースが接続を確立するためにユーザー ID と パスワードを必要とする場合は、実行時に例外が発生します。

データベース (例えば、Cloudscape など) がユーザー IDパスワード を サポートしていない場合は、コンポーネント管理認証エイリアスまたは コンテナー管理認証エイリアスのフィールドで、エイリアスを設定しないでください。 設定した場合は、システム・ログにユーザーおよびパスワードが有効なプロパティーではない ことを示す警告メッセージが記述されます。このメッセージは、単なる警告メッセージ であり、データ・ソースは正常に作成されます。

データ型 ピック・リスト
コンテナー管理認証エイリアス
このエイリアスは実行時のデータベース認証に使用されます。

res-auth が「コンテナー」に設定されている場合は、「Container-managed Authentication Alias」を設定します。

このフィールドを設定せず、しかもデータベースが接続を確立するためにユーザー ID と パスワードを必要とする場合は、実行時に例外が発生します。

データベース (例えば、Cloudscape など) がユーザー IDパスワード を サポートしていない場合は、コンポーネント管理認証エイリアスまたは コンテナー管理認証エイリアスのフィールドで、エイリアスを設定しないでください。 設定した場合は、システム・ログにユーザーおよびパスワードが有効なプロパティーではない ことを示す警告メッセージが記述されます。このメッセージは、単なる警告メッセージ であり、データ・ソースは正常に作成されます。

データ型 ピック・リスト
マッピング構成エイリアス
ユーザーが、「セキュリティー」>「JAAS 構成」> Application Logins Configuration リストから選択できるようにします。

DefaultPrincipalMapping JAAS 構成を使用すると、認証エイリアスを ユーザー ID およびパスワードにマップすることができます。 他のマッピング構成を定義して使用することもできます。

データ型 ピック・リスト

関連情報

管理コンソールのボタン