Application Server には、データ・ソース構成の検証のためのテスト接続サービスが提供されています。testConnection 命令は、データ・ソース構成をインスタンス化し、接続を取得して、 すぐに接続を閉じます。
データ・ソースの定義にWebSphere 変数が含まれる場合は、変数およびデータ・ソースの両方のスコープ設定がテスト接続の結果に与える影響を判断する必要があります。次のステップとして、テスト接続サービスを活動化するには、管理コンソール、wsadmin ツール、または Java スタンドアロン・プログラムの 3 つの方法からいずれかを選択します。
WebSphere 変数とデータ・ソース構成を関連付けることにより、 アプリケーションの実行時の動作と一致しないテストの接続結果が生じる場合があります。 場合によっては、テスト接続操作が失敗することがありますが、物理データ・ソースはアプリケーションの実行時は正常に機能します。 これと逆のシナリオも考えられます。潜在的な競合の原因として、 アプリケーション・サーバーが実行時の WebSphere 変数のスコープ設定を処理する方法と、 テスト接続操作においてこれらの同じスコープ設定を処理する方法の違いがあります。 その違いを理解することにより、データ・ソース構成を正常に作成できるようになります。
データ・ソース・スコープ | テスト接続操作が発生する JVM |
---|---|
セル | デプロイメント・マネージャー・プロセス |
ノード | (関連するノードの) ノード・エージェント・プロセス |
クラスター | クラスター・メンバーを含む各ノードのノード・エージェント |
サーバー | サーバー。 サーバーを使用することができない場合、テスト接続操作は、 アプリケーション・サーバーを含むノードのノード・エージェントで再試行されます。 |
データ・ソース・スコープ | セル・レベルの変数 | ノード・レベルの変数 | サーバー・レベルの変数 |
---|---|---|---|
セル・レベル | OK * (次のセクション『テスト接続が成功し、ランタイムが失敗する』を参照。) |
失敗 | 失敗 |
ノード・レベル | OK | OK | 失敗 |
サーバー・レベル | OK | OK | OK |
予想に反して、 これらのテスト接続の失敗は、一般的にランタイムの障害とは解釈されません。 データ・ソースを使用しなければならない クライアントすべてが、JDBC ドライバー・ファイルの ロケーションにアクセスできることを確認してから、 そのロケーションの絶対パスを使用して WebSphere 変数を構成してください。
テスト接続が成功し、ランタイムが失敗する
しかし、表 2 にリストされたスコープの組み合わせのいずれかで、 逆のシナリオが発生する可能性があります。 つまり、テスト接続操作は成功するものの、 実行時にデータ・ソースで障害が起こる、というものです。 この異常は、セル・スコープのデータ・ソースで、セル・スコープの WebSphere 変数を使用すると発生します。デプロイメント・マネージャー・ プロセスで操作が行われるため、 接続テストは成功します (表 1 参照)。 この場合、Application Server はセル・スコープの変数を解決できます。 そのデータ・ソースは、実行時に失敗する可能性があります。 これは、ヌル値を持つ ノード・スコープで自動的に定義された変数によって、 セル・スコープの変数がオーバーライドされるためです。
Application Server のほとんどの実装において、 この製品は、サポートされる JDBC ドライバーの変数を、 ノード・スコープの空ストリングに初期化します。 通常、セル・スコープ変数定義は、 このヌル値でオーバーライドされるため、 ランタイムの失敗の原因となります。 ランタイム・サーバーは、セル・スコープをチェックする前に、 変数定義のノード・スコープをチェックするため、 空ストリング変数を読み取り、JDBC ドライバー・クラスパスの 値として受け入れます。 クラスパスが正しくないと、サーバーがデータ・ソースの使用を試みた場合に、classNotFound 例外が発生します。
変数ルックアップのバイパス
JDBC プロバイダーのクラスパス・エントリーをハードコーディングした値に変更することにより、環境変数のルックアップをバイパスすることができます。 ただし、この方法が成功するのは、データ・ソースを機能させるすべてのノードで同じようにクラスパスを構成した場合 に限ります。
テスト接続サービスを活動化するには、管理コンソール、wsadmin ツール、または Java スタンドアロン・プログラムの 3 通りの方法があります。各プロセスとも、同じ MBean 上で同じメソッドが起動します。
WebSphere Application Server では、管理コンソールからボタン操作だけで接続をテストできます。「Data source collection 」、Data source settings 」、「Version 4 data source collection 」、および「Version 4 data source settings 」ページにはすべて、「テスト接続」ボタンがあります。 データ・ソースを定義および保管したら、このボタンをクリックして、データ・ソース定義のパラメーターが正しいことを確認できます。 コレクション・ページでは、複数のデータ・ソースを選択し、 それらをすべて一度にテストできます。 最初に一定の条件が満たされていなければならないことに注意してください。 詳しくは、 管理コンソールによる接続のテストを参照してください。
wsadmin ツールは、すべての WebSphere Application Server 管理アクティビティーに対してスクリプト・インターフェースを提供します。 このテスト接続機能は、MBean のメソッドとしてインプリメントされ、MBean メソッドは wsadmin により呼び出せるため、wsadmin を使用して、データ・ソースとの接続をテストできます。 wsadmin からのデータ・ソース接続のテストには、2 つのオプションがあります。
wsadmin の AdminControl オブジェクトは、 データ・ソース・オブジェクトの構成プロパティーをテストする testConnection 操作を備えています。 詳しくは、 wsadmin を用いた接続のテストを参照してください。
また、MBean 操作を起動して接続をテストできます。 この方法では、例: wsadmin を用いたデータ・ソース接続のテストを参考にしてください。
最後に、DataSourceCfgHelper MBean で testConnection() メソッドを実行して、テスト接続をテストする方法があります。 この方法では、構成されたデータ・ソースの構成 ID を渡すことができます。この Java プログラムは、実行されている Java Management Extensions (JMX) サーバーに接続して、MBean にアクセスします。Application Server の Network Deployment インストール では、デプロイメント・マネージャーで稼働する JMX サーバーへの接続に、通常はポート 8879 を使用します。
この起動からの戻り値は、0、正数または例外のいずれかです。 0 は、操作が正常に完了し、警告が戻されなかったことを意味します。 正数は、操作が完了したこと、および警告の数を意味します。 例外は、接続のテストが失敗したことを意味します。
このコードの例については、例: testConnection(ConfigID) を用いた接続のテストを参照してください。