WebSphere Application Server for z/OS, Version 6.0.x   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

テスト接続サービス

Application Server には、データ・ソース構成の検証のためのテスト接続サービスが提供されています。testConnection 命令は、データ・ソース構成をインスタンス化し、接続を取得して、 すぐに接続を閉じます。

データ・ソースの定義にWebSphere 変数が含まれる場合は、変数およびデータ・ソースの両方のスコープ設定がテスト接続の結果に与える影響を判断する必要があります。次のステップとして、テスト接続サービスを活動化するには、管理コンソールwsadmin ツール、または Java スタンドアロン・プログラムの 3 つの方法からいずれかを選択します。

[バージョン 6.0] 制約事項: Network Deployment の構成では、データ・ソースが以下のノード・スコープで定義されている場合、データ・ソースの接続をテストすることはできません。アプリケーションで使用するためにデータ・ソースのノード・スコープの構成を作成できます。 これらの構成は、実行時には正しく機能します。 データ・ソースがサーバー・スコープである場合、以下のデータ・ソースでは testConnection コマンドのみ使用できます。 Application Server は、ノード・スコープのデータ・ソースでの testConnection コマンドに対しては以下の例外を発行します。
java.sql.SQLException: Failure in loading T2 native library db2jcct2DSRA0010E: SQL state = null, Error Code = -99,999
テスト目的でこれらのデータ・ソースをノード・スコープで作成する場合は、 サーバー・スコープで同じ構成を作成する必要があります。サーバー・スコープ のデータ・ソースでテスト接続操作を実行して、設定が構成全体に有効であるかどうかを判別してください。 詳しくは、管理コンソールを使用した接続のテスト の文書、またはwsadmin を使用した接続のテスト の文書を参照してください。

スコープ設定の検証

WebSphere 変数とデータ・ソース構成を関連付けることにより、 アプリケーションの実行時の動作と一致しないテストの接続結果が生じる場合があります。 場合によっては、テスト接続操作が失敗することがありますが、物理データ・ソースはアプリケーションの実行時は正常に機能します。 これと逆のシナリオも考えられます。潜在的な競合の原因として、 アプリケーション・サーバーが実行時の WebSphere 変数のスコープ設定を処理する方法と、 テスト接続操作においてこれらの同じスコープ設定を処理する方法の違いがあります。 その違いを理解することにより、データ・ソース構成を正常に作成できるようになります。

以下のいずれかの基準が存在するスコープで、 該当する変数を解決することによって、WebSphere Application Server は物理データ・ソースを呼び出します。
  • 変数のスコープには、データ・ソースの構成を含めることができます。 つまり、より幅広いスコープを持つことになるわけです。
  • 変数とデータ・ソースは、同一のスコープを持ちます。
Application Server は、スコープのスペクトルの各レベルで変数を解決することで、これらの条件を満たします。 つまり、製品は、サーバー・スコープの変数を解決し、 続いてクラスター・スコープ、ノード・スコープ、最後にセル・スコープの変数を解決します。
しかし、Application Server がテストするのは 1 つのスコープの接続だけであり、データ・ソース構成の スコープと同じスコープの JVM 内でテスト操作を行います。この製品は、 そのスコープのみにおいて、ドライバーのクラスパス変数の解決を試みます。
表 1. データ・ソース・スコープとテスト接続 JVM の相関
データ・ソース・スコープ テスト接続操作が発生する JVM
セル デプロイメント・マネージャー・プロセス
ノード (関連するノードの) ノード・エージェント・プロセス
クラスター クラスター・メンバーを含む各ノードのノード・エージェント
サーバー サーバー。 サーバーを使用することができない場合、テスト接続操作は、 アプリケーション・サーバーを含むノードのノード・エージェントで再試行されます。
WebSphere 変数のスコープが データ・ソースのスコープより小さい場合、テスト接続操作は失敗します。 このような失敗と成功が起こるシナリオを、次の表で説明します。
表 2. 異なるデータ・ソースと変数の組み合わせによるテスト接続の結果
データ・ソース・スコープ セル・レベルの変数 ノード・レベルの変数 サーバー・レベルの変数
セル・レベル OK

* (次のセクション『テスト接続が成功し、ランタイムが失敗する』を参照。)

失敗 失敗
ノード・レベル OK OK 失敗
サーバー・レベル OK OK OK

予想に反して、 これらのテスト接続の失敗は、一般的にランタイムの障害とは解釈されません。 データ・ソースを使用しなければならない クライアントすべてが、JDBC ドライバー・ファイルの ロケーションにアクセスできることを確認してから、 そのロケーションの絶対パスを使用して WebSphere 変数を構成してください。

テスト接続が成功し、ランタイムが失敗する

しかし、表 2 にリストされたスコープの組み合わせのいずれかで、 逆のシナリオが発生する可能性があります。 つまり、テスト接続操作は成功するものの、 実行時にデータ・ソースで障害が起こる、というものです。 この異常は、セル・スコープのデータ・ソースで、セル・スコープの WebSphere 変数を使用すると発生します。デプロイメント・マネージャー・ プロセスで操作が行われるため、 接続テストは成功します (表 1 参照)。 この場合、Application Server はセル・スコープの変数を解決できます。 そのデータ・ソースは、実行時に失敗する可能性があります。 これは、ヌル値を持つ ノード・スコープで自動的に定義された変数によって、 セル・スコープの変数がオーバーライドされるためです。

Application Server のほとんどの実装において、 この製品は、サポートされる JDBC ドライバーの変数を、 ノード・スコープの空ストリングに初期化します。 通常、セル・スコープ変数定義は、 このヌル値でオーバーライドされるため、 ランタイムの失敗の原因となります。 ランタイム・サーバーは、セル・スコープをチェックする前に、 変数定義のノード・スコープをチェックするため、 空ストリング変数を読み取り、JDBC ドライバー・クラスパスの 値として受け入れます。 クラスパスが正しくないと、サーバーがデータ・ソースの使用を試みた場合に、classNotFound 例外が発生します。

しかし、 セル・スコープとすべての関連したノード・スコープに、 同じドライバー・クラスパス構成を作成して、 実行時にデータ・ソースが機能するようにすることができます。 以下のステップを、正しく実行してください。
  1. JDBC ドライバー・ファイルを、 デプロイメント・マネージャー・ノードにインストールします。 そのパス名を使用して、JDBC プロバイダーのドライバー・クラスパス変数を セル・スコープに定義します。
  2. データ・ソースが機能する必要がある 各ノードに、JDBC ドライバー・ファイルをインストールします。 そのパスを使用して、JDBC プロバイダーの WebSphere 変数を ノード・スコープに定義します。
    重要: デプロイメント・マネージャー・ノードを含む すべてのノード上で、 同一の絶対パス名を持つロケーションに ドライバー・ファイルをインストールして、 正常に終了することを確認してください。 このようにしない場合、テスト接続の成功と同じシナリオが発生しますが、実行時に障害が発生している可能性が残ります。
デプロイメント・マネージャー・ノードを含む、 すべてのノード上で、 同一の絶対パス名を持つロケーションに ドライバー・ファイルをインストールできない場合は、 セル・スコープのデータ・ソースを作成しないでください。 ノード・スコープは、データ・ソースの最大スコープ設定として使用してください。

変数ルックアップのバイパス

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 ツール

wsadmin ツールは、すべての WebSphere Application Server 管理アクティビティーに対してスクリプト・インターフェースを提供します。 このテスト接続機能は、MBean のメソッドとしてインプリメントされ、MBean メソッドは wsadmin により呼び出せるため、wsadmin を使用して、データ・ソースとの接続をテストできます。 wsadmin からのデータ・ソース接続のテストには、2 つのオプションがあります。

wsadmin の AdminControl オブジェクトは、 データ・ソース・オブジェクトの構成プロパティーをテストする testConnection 操作を備えています。 詳しくは、 wsadmin を用いた接続のテストを参照してください。

また、MBean 操作を起動して接続をテストできます。 この方法では、例: wsadmin を用いたデータ・ソース接続のテストを参考にしてください。

Java スタンドアロン・プログラム

最後に、DataSourceCfgHelper MBean で testConnection() メソッドを実行して、テスト接続をテストする方法があります。 この方法では、構成されたデータ・ソースの構成 ID を渡すことができます。この Java プログラムは、実行されている Java Management Extensions (JMX) サーバーに接続して、MBean にアクセスします。Application Server の Network Deployment インストール では、デプロイメント・マネージャーで稼働する JMX サーバーへの接続に、通常はポート 8879 を使用します。

この起動からの戻り値は、0、正数または例外のいずれかです。 0 は、操作が正常に完了し、警告が戻されなかったことを意味します。 正数は、操作が完了したこと、および警告の数を意味します。 例外は、接続のテストが失敗したことを意味します。

このコードの例については、例: testConnection(ConfigID) を用いた接続のテストを参照してください。




関連概念
変数
関連タスク
WebSphere 変数の構成
管理コンソールを使用した接続のテスト
wsadmin を使用した接続のテスト
関連資料
管理コンソールの有効範囲設定
例: testConnection(ConfigID) を使用した接続のテスト
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:52:11 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/cdat_testcon.html