| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1) E70015-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.2.1) E70015-01 |
|
前 |
次 |
この章では、WebLogic JDBCリソースの概要、構成方法およびWebLogicドメインへの適用方法について説明します。
この章には次の項が含まれます:
WebLogic Serverでは、JDBCデータ・ソースを構成して、WebLogicドメイン内のサーバーまたはクラスタにJDBCリソースをターゲット指定またはデプロイすることにより、データベース接続を構成できます。
構成対象の各データ・ソースにはデータベース接続のプールが含まれます。データベース接続は、データ・ソース・インスタンスの作成時(デプロイ時またはターゲット指定時)に作成されるか、サーバー起動時に作成されます。アプリケーションは、オブジェクトをどのように構成およびデプロイするかに応じて、JNDIツリー上のデータ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のデータ・ソースをルックアップし、その後データベース接続をリクエストします。接続の使用後に、アプリケーションは、connection.close()を呼び出します。これにより、データ・ソースの接続プールに接続が戻されます。WebLogic Serverにおけるデータ・ソースの詳細は、第3章「JDBCデータ・ソースの構成」を参照してください。
Active GridLink (AGL)データ・ソースは、1つ以上のOracle RACクラスタ内の1つ以上のノードに及ぶ接続プールを提供します。これは、ノード全体にわたる接続の動的ロード・バランシングをサポートし、クラスタに対するノードの追加や削除を示すイベントを処理します。第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。
マルチ・データ・ソースは汎用データ・ソースの選択されたリストを抽象化したものであり、マルチ・データ・ソースに関連付けられている汎用データ・ソース間でロード・バランシングやフェイルオーバー処理を提供します。マルチ・データ・ソースは、汎用データ・ソースがJNDIツリーにバインドされるように、JNDIツリーまたはローカル・アプリケーション・コンテキストにバインドされます。アプリケーションは、汎用データ・ソースの場合と同じようにJNDIツリー上のマルチ・データ・ソースまたはローカル・アプリケーション・コンテキスト(java:comp/env)内のマルチ・データ・ソースをルックアップし、その後データベース接続をリクエストします。マルチ・データ・ソースによって、マルチ・データ・ソース構成で選択されたアルゴリズム(ロード・バランシングまたはフェイルオーバー)に応じて、リクエストに対応するために使用する汎用データ・ソースが決定されます。マルチ・データ・ソースの詳細は、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。
WebLogic JDBCデータ・ソースの構成および管理を理解する上で重要なのは、JDBCリソースの作成者またはJDBCリソースの作成方法によって、リソースがどのようにデプロイおよび変更されるかが決まる、ということです。WebLogic管理者とプログラマのどちらでもJDBCリソースを作成できます。
WebLogic管理者は通常、管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、JDBCモジュールの作成およびデプロイ(ターゲット)を行います。これらのJDBCモジュールは、システム・モジュールと見なされます。詳細は、「JDBCシステム・モジュール」を参照してください。
プログラマは、XML記述子ファイルの作成をサポートする開発ツールでモジュールを作成し、次にJDBCモジュールをアプリケーション(たとえば、EARまたはWARファイル)と一緒にパッケージ化して、そのアプリケーションをWebLogic管理者へデプロイ用に渡します。これらのJDBCモジュールは、アプリケーション・モジュールと見なされます。詳細は、「JDBCアプリケーション・モジュール」を参照してください。
表2-1は、JDBCのモジュール・タイプと、それらの構成および変更方法を示しています。
表2-1 JDBCモジュール・タイプと、構成および管理のオプション
| モジュール・タイプ | 作成に使用するツール | 管理コンソールでのモジュールの追加/削除 | JMXでの変更(リモート) | JSR-88での変更(非リモート) | 管理コンソールでの変更 |
|---|---|---|---|---|---|
|
システム |
WebLogic Server管理コンソールまたはWLST |
はい |
はい |
いいえ |
可(JMXを使用) |
|
アプリケーション |
Oracle Enterprise Pack for Eclipse (OEPE)、Oracle JDeveloper、他のIDEまたはXMLエディタ |
いいえ |
いいえ |
可(デプロイメント・プランを使用) |
可(デプロイメント・プランを使用) |
WebLogic JDBCデータ・ソースの構成は、jdbc-data-source.xsdスキーマ(http://www.oracle.com/webfolder/technetwork/weblogic/jdbc-data-source/index.htmlで入手可能)に準拠するXMLドキュメントに格納されます。
JDBCリソースは、システム・モジュールとして、またはアプリケーション・モジュールとして、作成および管理されます。WebLogicは、標準または独自のJDBCアプリケーション・モジュールをサポートします。標準のJDBCアプリケーション・モジュールは、JEE 6の注釈またはdatasourcedefinitionに基づくスキーマの定義を使用して作成されます。独自のJDBCアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションに含めて構成するか、スタンドアロンのモジュールとして構成できます。
JDBCシステム・モジュールとJDBCアプリケーション・モジュールのどちらを使用しているかに関係なく、各JDBCデータ・ソースは、XMLファイル(モジュール)によって表現されます。
WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用してJDBCリソース(データ・ソース)を作成すると、WebLogic Serverはドメイン・ディレクトリの下位ディレクトリconfig/jdbcにJDBCモジュールを作成し、ドメインのconfig.xmlファイルにモジュールへの参照を追加します。JDBCモジュールは、jdbc-data-source.xsdスキーマ(http://www.oracle.com/webfolder/technetwork/weblogic/jdbc-data-source/index.htmlで入手可能)に準拠します。
このようにして構成されるJDBCデータ・ソースは、システム・モジュールと見なされます。システム・モジュールは管理者の所有になります。管理者はいつでも、リソースの削除や修正、同様のリソースの追加を行うことができます。システム・モジュールは、ドメインに構成されたサーバーおよびクラスタのターゲット指定に対して全面的に利用できます。つまり、同じターゲットにデプロイされているすべてのアプリケーションおよびクライアント・アプリケーションで利用できます。システム・モジュールはまた、JDBCSystemResourceMBeansとしてJMXからアクセスすることもできます。
汎用データ・ソース・システム・モジュールは、JDBCSystemResource要素として、ドメインのconfig.xmlファイルに含まれています。これには、JDBCモジュール・ファイルの名前と、モジュールのデプロイ先であるターゲット・サーバーおよびクラスタのリストが含まれます。図2-1に、config.xmlファイル内のデータ・ソース・リストと、そのマップ先となるモジュールの例を示します。
|
注意: 「汎用」は単純なデータ・ソースを、マルチ・データ・ソースやAGLデータ・ソースと区別するために使用する用語です。 |
この図では、config.xmlファイルにexamples-demoデータ・ソースがjdbc-system-resource要素としてリストされています。これはdomain\config\jdbcフォルダ内のexamples-demo-jdbc.xmlモジュールにマップされます。
AGLデータ・ソース・システム・モジュールは汎用データ・ソース・システム・モジュールと同様に、JDBCSystemResource要素として、ドメインのconfig.xmlファイルに含まれています。AGLデータ・ソースには、ONSおよびFANを含むjdbc-oracle-paramsセクションが含まれます。
AGLデータ・ソースの詳細は、第6章「Active GridLinkデータ・ソースの使用方法」を参照してください。
同様に、マルチ・データ・ソース・システム・モジュールは、jdbc-system-resource要素として、ドメインのconfig.xmlファイルに含まれています。マルチ・データ・ソース・モジュールには、マルチ・データ・ソースによって使用されるデータ・ソース・モジュールにマップされるdata-source-listパラメータが含まれます。config.xmlには、個々のデータ・ソース・モジュールも含まれています。図2-2に、config.xmlファイル内の要素と、config/jdbcディレクトリ内のシステム・モジュールの関係を示します。
図2-2 config.xmlからマルチ・データ・ソースおよびデータ・ソース・システム・モジュールへの参照
この図では、config.xmlファイル内に、3つのJDBCモジュールがリストされています。1つのマルチ・データ・ソースと、そのマルチ・データ・ソースによって使用される2つの汎用データ・ソースです。この2つのデータ・ソースも、マルチ・データ・ソース・モジュール内にリストされています。アプリケーションは、これらのモジュールのうち任意のものをJNDIツリー上でルックアップして、データベース接続をリクエストできます。マルチ・データ・ソースをルックアップした場合、そのマルチ・データ・ソースは、data-source-listパラメータ内のデータ・ソース、データ・ソースのリスト順、およびalgorithm-typeパラメータで指定されているアルゴリズムに応じて、データベース接続の供給に使用する汎用データ・ソースをどれにするかを決定します。
|
注意: マルチ・データ・ソースのメンバーは、汎用データ・ソースである必要があります。マルチ・データ・ソースやAGLデータ・ソースはメンバーにできません。 |
マルチ・データ・ソースの詳細は、第5章「JDBCマルチ・データ・ソースの構成」を参照してください。
システム・リソース・モジュールとは対照的に、アプリケーションとパッケージ化されたJDBCモジュールは、そのモジュールを作成およびパッケージ化した開発者が所有者になります。モジュールをデプロイする管理者ではありません。つまり、パッケージ化されたモジュールの場合、管理者の制御が及ぶ範囲が、一段と制限されることになります。リソース・モジュールをデプロイするときに、管理者はモジュールで指定されていたリソース・プロパティを変更できますが、モジュールの追加や削除はできません。(他のJava EEモジュールのように、リソース・モジュールのデプロイメント構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません。)
Java EE ではデータソース・リソースを、データベース接続の柔軟で移植性に優れたメソッドのためのアプリケーション・モジュールとしてプログラムで定義できます。『Oracle WebLogic Server JDBCアプリケーションの開発』のデータソース・リソース定義の使用に関する項を参照してください。
JDBCリソースは、標準のJava EEモジュールと同様に、アプリケーション・モジュールとしても管理できます。独自のJDBCアプリケーション・モジュールとは、単なるjdbc-data-source.xsdスキーマ(http://www.oracle.com/webfolder/technetwork/weblogic/jdbc-data-source/index.htmlで入手可能)に準拠するXMLファイルであり、データ・ソースを表します。
JDBCモジュールは、パッケージ化されたモジュールとして、エンタープライズ・アプリケーションの一部として含めることができます。パッケージ化されたモジュールは、EARまたは展開されたEARディレクトリにバンドルされ、すべての適切なデプロイメント記述子(weblogic-application.xmlやejb-jar.xmlデプロイメント記述子など)内で参照されます。JDBCモジュールはエンタープライズ・アプリケーションと一緒にデプロイされ、同梱されたアプリケーションのみ、またはすべてのアプリケーションで利用できるように構成できます。パッケージ化したモジュールを使用することにより、アプリケーションは必要なリソースに常にアクセスでき、アプリケーションを新しい環境に移動する処理が簡素化されます。パッケージ化されたJDBCモジュールを使用すると、EARファイルを開いたり、データ・ソースの手動による膨大な再構成を行ったりすることなく、アプリケーションと必要なJDBC構成を、ある環境から別の環境に(たとえば、テスト環境から本番環境に)移行できます。
定義により、パッケージ化されたJDBCモジュールは、エンタープライズ・アプリケーションに含まれているため、エンタープライズ・アプリケーションのデプロイ時にデプロイされます。パッケージ化したJDBCモジュールを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
独自のJDBCアプリケーション・モジュールは、weblogic.DeployerユーティリティまたはWebLogic Server管理コンソールを使用してスタンドアロンのリソースとしてもデプロイできます。その場合、リソースは通常、デプロイメント・プロセスにおいてターゲット指定されたサーバーまたはクラスタで使用できます。このようにしてデプロイされたJDBCリソースはスタンドアロン・モジュールと呼ばれ、WebLogic Server管理コンソールまたはJSR-88対応のツールを使用して再構成できますが、JMXやWLSTを介しては使用できません。
スタンドアロンJDBCモジュールを使用すると、JDBCリソースの共有と移植が容易になります。データ・ソース構成を作成し、他の開発者に配布できます。スタンドアロンJDBCモジュールを使用して、開発ドメインとステージング・ドメインの間など、ドメイン間でデータ・ソース構成の移動もできます。
|
注意: 独自のJDBCモジュールをスタンドアロン・モジュールとしてデプロイする場合、マルチ・データ・ソースのデプロイ順序は、そのメンバーの汎用データ・ソースのデプロイ順序より大きい数値である必要があります。 |
JDBCアプリケーション・モジュールの詳細は、付録B「JDBCアプリケーション・モジュールのデプロイメントの構成」を参照してください。
スタンドアロンJDBCモジュールのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイに関する項を参照してください。
WebLogic Server 10.3.6以上のリリースでは、パッケージ化されたデータ・ソースを含むEAR/WARファイルのAPP-INF/libディレクトリにデータベース・ドライバを追加できます。これにより、アプリケーションに必要なデータ・ソースとドライバの両方を含む自己包含型EAR/WARファイルをデプロイできます。
|
注意: ドライバの場所を追加するためにマニフェスト・ファイルのクラスパスを更新する必要はありません。 |
EARには独自のクラスローダーがあり、ネストされた全アプリケーション間で使用できるように共有されます。ドライバ・バージョンが異なる、複数のEAR/WARファイルをデプロイできます。ただし、システムのclasspath内に古いバージョンのドライバがある場合は、weblogic.xmlファイル内でPREFER-WEB-INF-CLASSES=trueを設定して、アプリケーションとともにパッケージ化されたドライバ・クラスを使用できるようにします。
EARまたはWARに埋め込まれているOracleドライバをojdbc6.jarまたはojdbc7.jarで使用する場合、関連するクラス・ローダーのクリーンアップに関して既知の問題が存在します。この問題を解決するには、ServletContextListenerのcontextDestroyed()メソッドからoracle.jdbc.OracleDriver.deregisterHack()をコールします。
WEB-INF/libディレクトリを使用して、ドライバJARファイルを保持することもできます。次の例は、WARおよびEARファイルの様々なディレクトリの場所を示しています。
Application (ear)
Web module (war)
WEB-INF/lib
EJB module
META-INF
APP-INF/lib
ただし、prefer-web-inf-classesまたはprefer-application-packagesセットで、DOMAIN_HOME/lib (「DOMAIN_HOME/libのサード・パーティJARファイルの使用」を参照)またはシステム・クラスパスとWEB-INF/libまたはAPP-INF/libの両方に同じJARの2つのバージョンを保持することはできません。つまり、次のいずれかのみを行う必要があります。
DOMAIN_HOME/libまたはシステム・クラスパスを使用して、ドメイン内のすべてのアプリケーションにドライバを取得します。
アプリケーションに埋め込まれたドライバを使用します。
|
注意: この制限に従わない場合、(JAR、バージョン変更、およびJARの参照順序に応じて)アプリケーションでClassCastExceptionが発生する可能性があります。 |
JARファイルが複数の場所に存在する場合、次のルールが適用されます。
weblogic.xmlのprefer-web-inf-classesがfalseの場合、優先順位は、システム・クラスパス > DOMAIN_HOME/lib > APP-INF/lib > WEB-INF/libになります。
weblogic.xmlのprefer-web-inf-classesがtrueの場合、WEB-INF/libのクラスが他のすべての場所に優先します。
WebLogic JDBCモジュール・ファイルはすべて、examples-demo-jdbc.xmlのように、末尾に接尾辞-jdbc.xmlを付ける必要があります。WebLogic Serverは、モジュールのデプロイ時にファイル名をチェックします。ファイル名の末尾が-jdbc.xmlでないとデプロイメントは失敗し、サーバーは起動しません。
本番再デプロイメント(バージョニング)を使用して、パッケージ化されたJDBCモジュールを含むアプリケーションの、あるバージョンをデプロイする場合、WebLogic Serverは次の形式で、JDBCモジュールにおいて定義されたデータ・ソースを識別します。
application_id#version_id@module_name@data_source_name
この名前はデータ・ソース・ランタイムMBeanに使用されます。また、WebLogic Serverトランザクション・マネージャにデータ・ソース・インスタンスを登録するためにも使用されます。
リタイア中のバージョンのアプリケーションにおいてトランザクションがタイムアウトし、その後そのバージョンのアプリケーションがアンデプロイされると、リタイアされたバージョンのアプリケーションにおけるデータ・ソース上の保留中または未完了のトランザクションを手動で解決することが必要になる場合があります。データ・ソースが(この場合には、リタイアされたバージョンのアプリケーションとともに)アンデプロイされると、WebLogic Serverトランザクション・マネージャは、保留中または未完了のトランザクションをリカバリできなくなります。
本番再デプロイメントの詳細は、次を参照してください。
『Oracle WebLogic Serverアプリケーションの開発』の本番再デプロイメント用アプリケーションの開発に関する項
『Oracle WebLogic Serverへのアプリケーションのデプロイ』の本番再デプロイメントを使用したアプリケーションの更新に関する項
WebLogic ServerでJDBCリソースのモジュール式デプロイメント・モデルをサポートするために、WebLogic JDBCオブジェクト用のスキーマweblogic-jdbc.xsdが用意されています。JDBCリソース・モジュール(記述子)を作成する場合は、モジュールをこのスキーマに準拠させる必要があります。IDEなどのツールは、このスキーマを基にJDBCリソース・モジュールを検証できます。
このスキーマは、http://www.oracle.com/webfolder/technetwork/weblogic/jdbc-data-source/index.htmlで入手できます。
|
注意: パッケージ化されたデータ・ソースの場合、スキーマのjdbc-data-source-params要素内のスコープはApplicationにのみ設定する必要があります。値Applicationは、次のものに対して無効になります。
これらのデータ・ソース・タイプには、データ・ソースのスコープを指定するアプリケーションや、関連付けられたモジュールはありません。WebLogic Serverでは、 |
データ・ソースは、記述子にdatasource-typeセットが含まれる必要があります。この機能は、WebLogic Server 12.2.1で追加されたもので、下位互換性を確保するためのオプションです。有効な値は、次のとおりです。
GENERIC - 汎用データ・ソース
MDS - マルチ・データ・ソース
AGL - Active GridLinkデータ・ソース
UCP - ユニバーサル接続プール・データ・ソース
PROXY - 複数テナント・データ・ソース用プロキシ
datasource-typeがUCPまたはPROXYに設定されていない場合、次の検証が実行されます。
datasource-typeがAGLに設定されている場合、FANの有効化がfalseで、ONSリストが構成されておらず、Active GridLinkフラグがfalseであっても、それはActive GridLinkデータ・ソースとして扱われます。
datasource-typeがAGLに設定されていない場合、FANの有効化がtrueであるか、ONSリストが構成されているか、またはActive GridLinkフラグがtrueであっても、それはエラーになります。
データ・ソース・リストが存在せず(マルチ・データ・ソースのメンバーが含まれない状態)、datasource-typeがGENERICまたはAGL以外に設定されている場合、それはエラーになります。
データ・ソース・リストが存在し(マルチ・データ・ソースのメンバーが含まれる状態)、datasource-typeがMDS以外に設定されている場合、それはエラーになります。
JDBCリソースは、『Oracle WebLogic Serverの理解』のシステム管理ツールとAPIの概要に関する項にリストされている管理ツールを使用して作成できます。JDBCリソースを作成すると、WebLogic Serverで各リソースのMBean (マネージドBean)が作成されます。その後、JMXまたはWebLogic Scripting Tool (WLST)を使用してMBeanにアクセスできます。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』および『WebLogic Scripting Toolの理解』を参照してください。
図2-3は、WebLogicドメイン内のJDBCオブジェクトに対するMBeanの階層を示しています。
JDBCSystemResourceMBeanは、データ・ソース・モジュールから作成されたJavaBeansのコンテナです。ただし、JMXのJDBCデータ・ソースへのアクセスは、すべてJDBCSystemResourceMBeanを使用して行われます。データ・ソース・モジュールから作成された個々のJavaBeansに直接アクセスすることはできません。
WebLogic Server JDBCはJava EE管理モデルを定義するJSR-77をサポートしています。Java EE管理モデルは、Java EE Webアプリケーション・サーバーとそのリソースの実行時状態をモニタリングするために使用されます。Java EE管理モデルにアクセスして、WebLogic JDBCシステム全体、メモリーにロードされたJDBCドライバ、JDBCデータ・ソースなどのリソースをモニターできます。
仕様に準拠するために、WebLogic JDBCサブシステムには次の実行時MBeanタイプが追加されています。
JDBCServiceRuntimeMBean - JDBCサブシステムを表し、現在システムで使用可能なJDBCDriverRuntimeMBeans、JDBCMultiDataSourceRuntimeMBeanおよびJDBCDataSourceRuntimeMBeansのリストにアクセスするためのメソッドを提供します。
JDBCMultiDataSourceRuntimeMBean - サーバーまたはクラスタにデプロイされたJDBCマルチ・データ・ソースを表します。
JDBCDriverRuntimeMBean - サーバーがメモリーにロードしたJDBCドライバを表します。
JDBCDataSourceRuntimeMBeans - サーバーまたはクラスタにデプロイされたJDBC汎用データ・ソースまたはAGLデータ・ソースを表します。
|
注意: WebLogic JDBCランタイムMBeanは、JSR-77で指定されている任意の統計プロバイダを実装していません。 |
WebLogic ServerでのJava EE管理モデルの使用については、『Oracle WebLogic Server Java EE管理アプリケーションの開発』を参照してください。
WLSTを使用してJDBCリソースを作成するには、次の基本タスクを実行する必要があります。
編集セッションを開始します。
JDBCシステム・リソース(プール、データ・ソース、マルチ・データ・ソース、JDBCドライバなど)を含むJDBCシステム・モジュールを作成します。
JDBCシステム・モジュールをターゲット指定します。
例2-1 JDBCリソースを作成するWLSTスクリプト
#----------------------------------------------------------------------
# Create JDBC Resources
#----------------------------------------------------------------------
import sys
from java.lang import System
print "@@@ Starting the script ..."
global props
url = sys.argv[1]
usr = sys.argv[2]
password = sys.argv[3]
connect(usr,password, url)
edit()
startEdit()
servermb=getMBean("Servers/examplesServer")
if servermb is None:
print '@@@ No server MBean found'
else:
def addJDBC(prefix):
print("")
print("*** Creating JDBC resources with property prefix " + prefix)
# Create the Connection Pool. The system resource will have
# generated name of <PoolName>+"-jdbc"
myResourceName = props.getProperty(prefix+"PoolName")
print("Here is the Resource Name: " + myResourceName)
jdbcSystemResource = wl.create(myResourceName,"JDBCSystemResource")
myFile = jdbcSystemResource.getDescriptorFileName()
print ("HERE IS THE JDBC FILE NAME: " + myFile)
jdbcResource = jdbcSystemResource.getJDBCResource()
jdbcResource.setName(props.getProperty(prefix+"PoolName"))
# Create the DataSource Params
dpBean = jdbcResource.getJDBCDataSourceParams()
myName=props.getProperty(prefix+"JNDIName")
dpBean.setJNDINames([myName])
# Create the Driver Params
drBean = jdbcResource.getJDBCDriverParams()
drBean.setPassword(props.getProperty(prefix+"Password"))
drBean.setUrl(props.getProperty(prefix+"URLName"))
drBean.setDriverName(props.getProperty(prefix+"DriverName"))
propBean = drBean.getProperties()
driverProps = Properties()
driverProps.setProperty("user",props.getProperty(prefix+"UserName"))
e = driverProps.propertyNames()
while e.hasMoreElements() :
propName = e.nextElement()
myBean = propBean.createProperty(propName)
myBean.setValue(driverProps.getProperty(propName))
# Create the ConnectionPool Params
ppBean = jdbcResource.getJDBCConnectionPoolParams()
ppBean.setInitialCapacity(int(props.getProperty(prefix+"InitialCapacity")))
ppBean.setMaxCapacity(int(props.getProperty(prefix+"MaxCapacity")))
if not props.getProperty(prefix+"ShrinkPeriodMinutes") == None:
ppBean.setShrinkFrequencySeconds(int(props.getProperty(prefix+"ShrinkPeriodMinutes")))
if not props.getProperty(prefix+"TestTableName") == None:
ppBean.setTestTableName(props.getProperty(prefix+"TestTableName"))
if not props.getProperty(prefix+"LoginDelaySeconds") == None:
ppBean.setLoginDelaySeconds(int(props.getProperty(prefix+"LoginDelaySeconds")))
# Adding KeepXaConnTillTxComplete to help with in-doubt transactions.
xaParams = jdbcResource.getJDBCXAParams()
xaParams.setKeepXaConnTillTxComplete(1)
# Add Target
jdbcSystemResource.addTarget(wl.getMBean("/Servers/examplesServer"))
.
.
.
MBeanから使用できる適切なメソッドを使用すると、JDBCオブジェクトや属性を変更およびモニターできます。
JDBCオブジェクトや属性を変更する場合は、set、target、untargetおよびdeleteメソッドを使用します。
JDBCランタイム・オブジェクトをモニターするには、getメソッドを使用します。
詳細は、『WebLogic Scripting Toolの理解』のMBeanのナビゲート(WLSTオンライン)に関する項を参照してください。
この項では、WLSTを使用してJDBCリソースを構成する場合のベスト・プラクティスについて説明します。
MBeanオブジェクトを操作する前に、Null MBeanオブジェクト(プール、データ・ソース、ドライバなど)をトラップします。
WLSTをオフラインで使用する場合、管理オブジェクト名で次の文字は無効です: ピリオド(.)、スラッシュ(/)またはバックスラッシュ(\)。詳細は、WebLogic Scripting Toolの理解のWLSTコマンドの構文に関する項を参照してください。
WebLogic Server管理コンソールを使用してJDBCデータ・ソースをターゲットに指定したり、クラスタ・メンバーにデプロイして、JDBCリソースの可用性やリソース間通信のロード・バランシングを向上させることができます。ただし、なんらかの理由でクラスタ・メンバーが使用できなくなった場合、接続はフェイルオーバーを行いません。新しい接続は、使用可能なクラスタ・メンバーで必要になった場合に作成されます。第15章「サーバーおよびクラスタへのデータ・ソースのデプロイ」を参照してください。
|
注意: マルチ・データ・ソースで使用できるのは、同じクラスタ・メンバー(同じJVMの)にデプロイされている汎用データ・ソースのみです。 |
