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 例外が発生します。
以下の Application Server 管理オプションの いずれかを使用すると、ドライバー・クラスパス変数の最終値が 空ストリングにならないようにすることができます。
データ・ソースへのアクセスを必要とする すべてのノード (デプロイメント・マネージャー・ノードを含む) が、 同じプラットフォームで稼働し、 同じロケーションに JDBC ドライバーがインストールされている場合に限り、 セル・スコープのリソースを使用します。 それ以外の場合は、ノード・スコープを データ・ソースの最大スコープ設定として使用します。
変数ルックアップのバイパス
JDBC プロバイダーのクラスパス・エントリーをハードコーディングした値に変更することにより、環境変数のルックアップをバイパスすることができます。 ただし、この方法が成功するのは、データ・ソースを機能させるすべてのノードで同じようにクラスパスを構成した場合 に限ります。
テスト接続サービスを活動化するには、管理コンソール、wsadmin ツール、または Java スタンドアロン・プログラムの 3 通りの方法があります。各プロセスとも、同じ MBean 上で同じメソッドが起動します。
WebSphere Application Server では、管理コンソールからボタン操作だけで接続をテストできます。「Data source collection 」、Data source settings 」、「Version 4 data source collection 」、および「Version 4 data source settings 」ページにはすべて、「テスト接続」ボタンがあります。 データ・ソースを定義および保管したら、このボタンをクリックして、データ・ソース定義のパラメーターが正しいことを確認できます。 コレクション・ページでは、複数のデータ・ソースを選択し、 それらをすべて一度にテストできます。 最初に一定の条件が満たされていなければならないことに注意してください。 詳しくは、 管理コンソールによる接続のテストを参照してください。
Test connection failed for data source isagent on server server1 at node svtaix24Node01 with the following exception: java.lang.Exception: java.sql.SQLException: JZ006: Caught IOException: java.net.ConnectException: A remote host refused an attempted connect operation.DSRA0010E: SQL State = JZ006, Error Code = 0Sybase データ・ソースのポート番号が、Sybase サーバーで 構成されたポートと一致しない場合に、この例外が発生します。 デフォルトのポート番号は 5000 です。 /<sybase install directory> の下にある インターフェース・ファイルで、ご使用の Sybase サーバーのポート番号を確認してください。
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) を用いた接続のテストを参照してください。