Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング 11gリリース1 (10.3.6) B60996-04 |
|
前 |
次 |
次の項では、WebLogic Serverリソース・アダプタの接続管理について説明します。接続管理の詳細については、J2CA 1.5仕様(http://java.sun.com/j2ee/connector/
)の第6章「Connection Management」を参照してください。
J2CA 1.5仕様の要件の1つに接続管理規約があります。WebLogic Serverとリソース・アダプタの間の接続管理規約は以下のとおりです。
管理対象と非管理対象(2層)の両方のアプリケーションに対して、接続の取得に関する一貫性のあるアプリケーション・プログラミング・モデルを提供します。
リソース・アダプタが、リソース・アダプタのタイプとEISに固有のCCI (common client interface)に基づいた接続ファクトリと接続インタフェースを提供できるようにします。これにより、既存のJDBC APIへの影響を最小限に抑えながら、JDBCドライバとJava EE 1.5コネクタ・アーキテクチャを協調させることができます。
アプリケーション・サーバーが、構成されたリソース・アダプタに対して様々なサービス(トランザクション、セキュリティ、高機能なプール、エラーの追跡とロギングなど)を提供できるようにします。
接続プールをサポートします。
リソース・アダプタ側の接続管理規約は、リソース・アダプタのConnection
、ConnectionFactory
、ManagedConnection
およびManagedConnectionFactory
クラスで具体化されます。
Java EEアプリケーション・コンポーネントは、接続ファクトリと呼ばれるパブリック・インタフェースを使用して接続インスタンスにアクセスし、そのインスタンスを使用して基底のEISに接続します。接続の例には、データベース接続やJMS (Java Message Service)接続があります。
リソース・アダプタは接続と接続ファクトリを提供して、EIS接続の接続ファクトリとして機能します。たとえば、javax.sql.DataSource
およびjava.sql.Connection
インタフェースは、リレーショナル・データベースに接続するためのJDBCベースのインタフェースです。
アプリケーションは、Java Naming and Directory Interface (JNDI)ネームスペースで接続ファクトリ・インスタンスをルックアップし、そのインスタンスを使用してEIS接続を取得します。ConnectionFactoryの取得(クライアントとJNDI間の対話)を参照してください。
バージョン1.5のリソース・アダプタは、独立したオブジェクトとしてJNDIツリーにバインドされるので、独立したシステム・リソースとして、またはメッセージドリブンBean (MDB)のメッセージ・ソースとして使用できます。一方、バージョン1.0のリソース・アダプタは、JNDIツリーにバインドされたConnectionFactory
オブジェクトによって識別されます。
バージョン1.5のリソース・アダプタでは、デプロイメント時に、ResourceAdapter
Beanがある場合は、weblogic-ra.xml
ファイルのjndi-name要素の値を使用してJNDIツリーにバインドされます。その結果、管理者はリソース・アダプタを1つのデプロイ可能エンティティとして参照し、リソース・アダプタ・プロバイダによって公開されたリソース・アダプタの機能とやり取りすることができます。詳細は、付録A「weblogic-ra.xmlスキーマ」のjndi-nameを参照してください。
アプリケーション・アセンブラまたはコンポーネント・プロバイダは、アプリケーションのデプロイメント記述子で、そのアプリケーション・コンポーネントの接続ファクトリの要件を構成します。例:
res-ref-name: eis/myEIS res-type: javax.resource.cci.ConnectionFactory res-auth: Application or Container
リソース・アダプタ・デプロイヤは、リソース・アダプタの構成情報を提供します。
アプリケーションは、Java Naming and Directory Interface (JNDI)ネームスペースでConnectionFactory
インスタンスをルックアップし、そのインスタンスを使用してEIS接続を取得します。管理対象の環境にあるアプリケーションが、res-type
変数で指定された接続ファクトリからEISインスタンスとの接続を取得すると、以下のようなイベントが発生します。
注意: 管理対象のアプリケーションの環境によって、EISにアクセスするJava EEベースのWeb対応多層アプリケーションの操作環境が定義されます。 |
アプリケーション・サーバーは、構成済みのリソース・アダプタを使用して、基底のEISとの物理接続を作成します。
アプリケーション・コンポーネントは、JNDIインタフェースを使用して、コンポーネントの環境でConnectionFactory
インスタンスをルックアップします(例 5-1を参照)。
例5-1 JNDIルックアップ
//obtain the initial JNDI Naming context Context initctx = new InitialContext(); // perform JNDI lookup to obtain the connection factory javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory) initctx.lookup("java:comp/env/eis/MyEIS");
メソッドNamingContext.lookup
で渡されるJNDI名は、デプロイメント記述子のres-ref-name
要素で指定されているものと同じです。JNDIルックアップによって、res-type
要素で指定されたjava.resource.cci.ConnectionFactory
型のインスタンスが取得されます。
アプリケーション・コンポーネントは、返された接続を使用して基底のEISにアクセスします。
アプリケーション・コンポーネントは、ConnectionFactory
のgetConnection
メソッドを呼び出してEIS接続を取得します。返された接続インスタンスは、基底の物理接続へのアプリケーション・レベルのハンドルを表します。アプリケーション・コンポーネントは、接続ファクトリのgetConnection
メソッドを複数回呼び出して、複数の接続を取得します。
javax.resource.cci.Connection cx = cxf.getConnection();
接続を使い終わると、コンポーネントはConnection
インタフェースのcloseメソッドを使用して接続を閉じます。
cx.close();
アプリケーション・コンポーネントが割り当てられた接続を使用後に閉じなかった場合、その接続は未使用の接続と見なされます。未使用の接続のクリーン・アップはアプリケーション・サーバーによって管理されます。
大半の場合、アダプタのManagedConnectionFactory
は、Java EEコネクタ・アーキテクチャの仕様1.5(http://java.sun.com/j2ee/connector/
を参照)の7.9項で定義されるように、接続の共有をサポートします。また、この仕様では、コール元アプリケーションのデプロイメント記述子またはアノテーションでres-sharing-scope
を共有不可
に設定することによって、接続が共有不可能にできると説明しています。
ただし、コール元アプリケーションで共有不可能なリソースの参照を定義するのには不都合がある可能性があります。たとえば、コール元アプリケーションはWebLogicのグローバルJNDIから直接にConnectionFactory
プールへの参照を実行できますが、アプリケーションはこのプールへの共有不可能なリソースの参照を定義しません。WebLogic Serverは、このようなプールの使用をデフォルトで共有不可能として処理します。その結果、アダプタが接続の共有をサポートしない場合、アダプタは機能しません。
この問題を回避するため、WebLogic Serverはweblogic.connector.extensions.Unshareable
というパブリック注釈をサポートします。この注釈は、ManagedConnectionFactory
が共有をサポートしない場合にManagedConnectionFactory
クラスで使用できます。このようなアダプタがデプロイされると、WebLogic ServerはManagedConnectionFactory
クラスをチェックし、ManagedConnectionFactory
および関連プールを共有不可能として処理します。WebアプリケーションまたはEnterprise Java Beanでこの共有不可能なプールへの共有可能なリソースの参照を構成する場合、WebLogic Serverは警告メッセージを表示しますが、それでもWebアプリケーションまたはEJBはプールを共有不可能として処理します。weblogic-ra.xml
または管理コンソールでは何も構成する必要がありません。
ManagedConnectionFactory
が共有可能な場合、アダプタのコードでは何も変更する必要はありません。すべてのManagedConnectionFactory
およびプールは、ManagedConnectionFactory
に共有不可
アノテーションが含まれない場合でも、デフォルトでは共有可能とみなされます。
J2CA 1.5仕様に基づいた発信リソース・アダプタでは、1つまたは複数の発信接続を用意し、各接続でWebLogic Server固有の認証やトランザクションをサポートするように構成できます。ra.xml
およびweblogic-ra.xml
デプロイメント記述子ファイルで発信接続のプロパティを構成します。
weblogic-ra.xml
デプロイメント記述子のoutbound-resource-adapter
要素とそのサブ要素を使用して、リソース・アダプタの発信コンポーネントについて記述します。
発信接続プールは以下の3つのレベルで定義できます。
グローバル - default-connection-properties
要素を使用して、リソース・アダプタのすべての発信接続グループに適用するパラメータを指定します。「default-connection-properties」を参照してください。
グループ - connection-definition-group
要素を使用して、ra.xml
デプロイメント記述子で指定された特定の接続ファクトリに属する、すべての発信接続インスタンスに適用するパラメータを指定します。ra.xml
の接続ファクトリとweblogic-ra.xml
の接続定義グループの間には、1対1の対応関係があります。グループで指定されたプロパティは、グローバル・レベルで指定されたパラメータをオーバーライドします。「connection-definition-group」を参照してください。
connection-factory-interface
要素(connection-definition-group
要素のサブ要素)は、各connection-definition-group
に必須の一意の要素(キー)として機能します。weblogic-ra.xml
のconnection-definition-interface
要素とra.xml
のconnectiondefinition-interface
要素の間には1対1の関係がなければなりません。
インスタンス - weblogic-ra.xml
デプロイメント記述子のconnection-instance
要素を使用して、各接続定義グループの下で接続インスタンスを指定できます。これは、リソース・アダプタに対する個別の接続プールに相当します。connection-properties
のサブ要素を使用して、インスタンス・レベルでプロパティを指定することもできます。インスタンス・レベルで指定されたプロパティは、グループ・レベルやグローバル・レベルで指定されたプロパティをオーバーライドします。「connection-instance」を参照してください。
例5-2は、複数の発信接続を構成したweblogic-ra.xml
デプロイメント記述子の例です。
例5-2 weblogic-ra.xmlデプロイメント記述子:複数の発信接続
<?xml version="1.0" ?> <weblogic-connector xmlns="http://xmlns.oracle.com/weblogic/weblogic-connector"> <jndi-name>900eisaNameOfBlackBoxXATx</jndi-name> <outbound-resource-adapter> <connection-definition-group> <connection-factory-interface>javax.sql.DataSource </connection-factory-interface> <connection-instance> <jndi-name>eis/900eisaBlackBoxXATxConnectorJNDINAME1 </jndi-name> <connection-properties> <pool-params> <initial-capacity>2</initial-capacity> <max-capacity>10</max-capacity> <capacity-increment>1</capacity-increment> <shrinking-enabled>true</shrinking-enabled> <shrink-frequency-seconds>60</shrink-frequency-seconds> </pool-params> <properties> <property> <name>ConnectionURL</name> <value> jdbc:oracle:thin:@bcpdb:1531:bay920;create=true;autocommit=false </value> </property> <property> <name>XADataSourceName</name> <value>OracleXAPool</value> </property> <property> <name>TestClassPath</name> <value>HelloFromsetTestClassPathGoodDay</value> </property> <property> <name>unique_ra_id</name> <value>eisablackbox-xa.oracle.900</value> </property> </properties> </connection-properties> </connection-instance> <connection-instance> <jndi-name>eis/900eisaBlackBoxXATxConnectorJNDINAME2 </jndi-name> <connection-properties> <pool-params> <initial-capacity>2</initial-capacity> <max-capacity>10</max-capacity> <capacity-increment>1</capacity-increment> <shrinking-enabled>true</shrinking-enabled> <shrink-frequency-seconds>60 </shrink-frequency-seconds> </pool-params> <properties> <property> <name>ConnectionURL</name> <value> jdbc:oracle:thin:@bcpdb:1531:bay920;create=true;autocommit=false </value> </property> <property> <name>XADataSourceName</name> <value>OracleXAPool</value> </property> <property> <name>TestClassPath</name> <value>HelloFromsetTestClassPathGoodDay</value> </property> <property> <name>unique_ra_id</name> <value>eisablackbox-xa.oracle.900</value> </property> </properties> </connection-properties> </connection-instance> </connection-definition-group> <connection-definition-group> <connection-factory-interface>javax.sql.DataSourceCopy </connection-factory-interface> <connection-instance> <jndi-name>eis/900eisaBlackBoxXATxConnectorJNDINAME3</jndi-name> <connection-properties> <pool-params> <initial-capacity>2</initial-capacity> <max-capacity>10</max-capacity> <capacity-increment>1</capacity-increment> <shrinking-enabled>true</shrinking-enabled> <shrink-frequency-seconds>60</shrink-frequency-seconds> </pool-params> <properties> <property> <name>ConnectionURL</name> <value>jdbc:oracle:thin:@bcpdb:1531:bay920;create=true;autocommit=false</value> </property> <property> <name>XADataSourceName</name> <value>OracleXAPoolB</value> </property> <property> <name>TestClassPath</name> <value>HelloFromsetTestClassPathGoodDay</value> </property> <property> <name>unique_ra_id</name> <value>eisablackbox-xa-two.oracle.900</value> </property> </properties> </connection-properties> </connection-instance> </connection-definition-group> </outbound-resource-adapter> </weblogic-connector>
J2CA 1.5仕様(http://java.sun.com/j2ee/connector/
)では、着信メッセージ接続をサポートするようにリソース・アダプタを構成できます。着信接続を構成する主な手順は以下のとおりです。
weblogic-ra.xml
デプロイメント記述子でリソース・アダプタのJNDI名を指定します。「表A-1 Weblogic-connectorのサブ要素」の「jndi-name」を参照してください。
ra.xml
デプロイメント記述子で、サポートされる着信メッセージ・タイプごとに、メッセージ・リスナーとActivationSpec
を構成します。ActivationSpec
クラスの要件の詳細については、J2CA 1.5仕様の第12章「Message Inflow」を参照してください。
パッケージ化されるエンタープライズ・アプリケーションの中に、構成済みのEJBメッセージドリブンBean (MDB)を含めます。weblogic-ejb-jar.xml
デプロイメント記述子のresource-adapter-jndi-name
要素で、上記の手順でリソース・アダプタに割り当てた同じJNDI名を指定します。この値を設定すると、MDBとリソース・アダプタが互いに通信できるようになります。
リソース・アダプタが着信接続で使用するセキュリティIDを構成します。リソース・アダプタがメッセージを受信するとき、その作業は特定のセキュリティIDで実行される必要があります。「リソース・アダプタのセキュリティIDの構成」を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の説明に従ってリソース・アダプタをデプロイします。
MDBをデプロイします。詳細は、『Oracle Fusion Middleware WebLogic Enterprise JavaBeansのプログラミング』および『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「メッセージドリブンEJB」を参照してください。
例5-3では、ra.xml
デプロイメント記述子で、2つのメッセージ・リスナーおよびアクティブ化仕様を持つ着信接続を構成する方法を示しています。
例5-3 着信接続の構成の例
<inbound-resourceadapter> <messageadapter> <messagelistener> <messagelistener-type> weblogic.qa.tests.connector.adapters.flex.InboundMsgListener </messagelistener-type> <activationspec> <activationspec-class> weblogic.qa.tests.connector.adapters.flex.ActivationSpecImpl </activationspec-class> </activationspec> </messagelistener> <messagelistener> <messagelistener-type> weblogic.qa.tests.connector.adapters.flex.ServiceRequestMsgListener </messagelistener-type> <activationspec> <activationspec-class> weblogic.qa.tests.connector.adapters.flex.ServiceRequestActivationSpec </activationspec-class> </activationspec> </messagelistener> </messageadapter> </inbound-resourceadapter>
この項では、weblogic-ra.xml
デプロイメント記述子で、WebLogic Serverリソース・アダプタの接続プール・パラメータを構成する方法について説明します。詳細は、付録A「weblogic-ra.xmlスキーマ」を参照してください。
ManagedConnection
が表すエンタープライズ情報システム(EIS)の複雑さによっては、ManagedConnection
の作成にコストがかかる可能性があります。WebLogic Serverの起動時に、接続プールに初期数のManagedConnection
を登録し、実行時には作成しないようにすることができます。この設定は、weblogic-ra.xml
記述子ファイルのinitial-capacity
要素を使用して構成します。この要素のデフォルト値は、1
ManagedConnection
です。
WebLogic Serverの起動時には開始セキュリティ・プリンシパルまたはリクエスト・コンテキスト情報が不明なので、サーバー・インスタンスは初期接続用の特別な資格証明マッピングをルックアップすることにより、セキュリティ・サブジェクトを使用して、初期接続を作成します。「初期接続:アプリケーションのリクエストがない場合、アダプタからのManagedConnectionが必要」を参照してください。
注意: マッピングが見つからない場合は、WebLogic Serverはサブジェクトとしてnull を使用します。
|
作成されるManagedConnection
の数が増えるほど、メモリーやディスク容量などのシステム・リソースが多く消費されます。エンタープライズ情報システム(EIS)によっては、この消費がシステム全般のパフォーマンスに影響します。システム・リソースに対するManagedConnection
の影響を制御するために、weblogic-ra.xml
デプロイメント記述子のmax-capacity
要素で、割り当てるManagedConnection
の最大数を指定できます。
接続リクエスト中にManagedConnection
(capacity-increment
が2以上の場合は複数のManagedConnection
)を新規作成する必要がある場合、WebLogic Serverが最大許容数を超えてManagedConnection
を作成することはありません。この制限を超えてManagedConnection
の割当をリクエストすると、呼出し側にResourceAllocationException
が返されます。
J2CA 1.5仕様(http://java.sun.com/j2ee/connector/
)に従って、アプリケーション・コンポーネントがリソース・アダプタを介してEISとの接続を要求すると、WebLogic Serverはまず、接続プール内の既存で利用可能なManagedConnection
の中に、リクエストされている接続の種類と一致するものがないか探します。しかし、一致するものが見つからない場合には、新規のManagedConnection
を作成して接続リクエストに応じます。
weblogic-ra.xml
記述子ファイルのcapacity-increment
要素を使用して、一致するものが見つからない場合に作成される追加のManagedConnection
の数を指定できます。この機能により、時間の経過と共に増加する接続プールのサイズとサイズが増加するたびに低下するサーバーのパフォーマンスを柔軟に制御できます。
ManagedConnection
の最大数を設定すると、処理能力を超えた数のManagedConnection
が割り当てられてサーバーが過負荷になることはありませんが、常に必要に応じてシステム・リソースの量が効率的に制御されるわけではありません。WebLogic Serverでは、リソース・アダプタの接続プール内のManagedConnection
の動作状況をモニターするサービスを利用できます。使用量が減少しそのレベルで一定期間とどまっている場合、接続プールのサイズは初期容量まで、またはできる限りそれに近く、継続的な接続リクエストを十分満たせる大きさにまで縮小されます。
このシステム・リソース使用量サービスはデフォルトで有効です。ただし、weblogic-ra.xml
記述子ファイルのshrinking-enabled
要素をfalse
に設定すると、このサービスを無効にできます。
weblogic-ra.xml
記述子ファイルのshrink-frequency-seconds
要素を使用すると、接続プール・マネージャが未使用のManagedConnection
を再利用しようとする間隔(秒単位)を指定できます。この要素のデフォルト値は、900
秒です。
接続の最大数に達していて、利用可能な接続がない場合、WebLogic Serverは呼出しがタイムアウトするまで再試行します。highest-num-waiters
要素は、同時に接続を待機するクライアントの数を制御します。
接続が作成されて失敗した場合、その接続は使用不可リストに置かれます。WebLogic Serverは使用不可リストにある失敗した接続を再作成しようとします。highest-num-unavailable
要素は、使用不可リストに同時に存在できる使用不可接続の数を制御します。
追加のManagedConnection
の作成中に、失敗した接続を再作成するようにWebLogic Serverを構成するには、connection-creation-retry-frequency-seconds
要素を有効にします。デフォルトでは、この機能は無効です。
接続リクエストにはパラメータ情報が含まれています。デフォルトでは、コネクタ・コンテナはManagedConnectionFactory
のmatchManagedConnections()
メソッドを呼び出して、プール内の使用可能な接続をリクエスト内のパラメータと一致させます。一致に成功した接続が返されます。
ManagedConnectionFactory
がmatchManagedConnections()
の呼出しをサポートしていない場合もあります。その場合、matchManagedConnections()
メソッドの呼出しはjavax.resource.NotSupportedException
を返します。この例外が捕捉された場合、コネクタ・コンテナはManagedConnectionFactory
のmatchManagedConnections()
メソッドの呼出しを自動的に停止します。
match-connections-supported
要素を設定して、リソース・アダプタが接続のマッチングをサポートするかどうかを指定できます。デフォルトでは、この要素はtrueに設定されており、matchManagedConnections()
メソッドは少なくとも1回呼び出されます。falseに設定されている場合、このメソッドは呼び出されません。
接続のマッチングがサポートされていない場合は、リソースの最大数にまだ達していなければ、新しいリソースが作成されて返されます。最大数に達しているときは、最も古い使用不可のリソースがリフレッシュされて返されます。
test-connections-on-create
要素を設定して、接続が作成されるときの接続のテストを有効にすることができます。デフォルト値はfalse
です。
test-connections-on-release
要素を設定して、接続が接続プールに解放されるときの接続のテストを有効にすることができます。デフォルト値はfalse
です。
接続プロキシ・ラッパー機能は、Java EE 1.0コネクタ・アーキテクチャに基づいて作成されたリソース・アダプタでのみ有効です。接続がリクエストされると、WebLogic Serverは、接続オブジェクトをラップするプロキシ・オブジェクトを(リソース・アダプタを介して)クライアントに返します。WebLogic Serverはこのプロキシを使用して以下の機能を提供します。
接続リーク検出機能
接続を使用するグローバル・トランザクションの開始前に接続がリクエストされた場合のXAResourceの遅延登録
接続リクエストで返された接続オブジェクトが(Connection
クラスによって実装されたインタフェースではなく) Connection
実装クラスとしてキャストされた場合、ClassCastException
が発生することがあります。この例外は、以下のいずれかの原因で発生します。
リソース・アダプタがキャストを実行した
接続リクエストでクライアントがキャストを実行した
WebLogic Serverは、リソース・アダプタが原因のClassCastException
を検出しようとします。リソース・アダプタからのキャストが失敗したことが検出された場合は、プロキシ・ラッパー機能が無効にされ、接続リクエスト時のラップされていない接続オブジェクトを戻すことで処理が進められます。サーバーは、プロキシ生成が無効になったことを示す警告メッセージをログに記録します。この状況が発生すると、接続リーク検出機能とXAResourceの遅延登録機能も無効になります。
WebLogic Serverは、コンテナ管理によるセキュリティを使用するクライアントとして動作し、リソース・アダプタのデプロイメント時にテストを実行することで、ClassCastException
を検出しようとします。そのためには、セキュリティ資格証明を定義してリソース・アダプタをデプロイする必要があります。
クライアントがキャストを実行し、ClassCastException
を受け取った場合は、クライアント・コードを以下の例のように変更します。
クライアントが接続オブジェクトをMyConnection
にキャストするものとします。
MyConnection
をリソース・アダプタのConnection
インタフェースを実装するクラスとするのではなく、Connection
を拡張するインタフェースとなるようにMyConnection
を変更します。
MyConnection
インタフェースを実装するMyConnectionImpl
クラスを実装します。
リソース・アダプタで接続プロキシを使用できるかどうかわかっている場合は、WebLogic Server 8.1のweblogic-ra.xml
にあるuse-connection-proxies
要素をtrue
またはfalse
に明示的に設定することで、プロキシ・テストを避けることができます。
注意: WebLogic ServerはJ2CA 1.0リソース・アダプタを引続きサポートしています。1.0リソース・アダプタの場合は、weblogic-ra.xmlにあるWebLogic Server 8.1デプロイメント記述子を引き続き使用します。この記述子には1.0リソース・アダプタに対応する要素が含まれています。 |
true
に設定した場合、プロキシ・テストは実行されず、接続プロパティが生成されます。
false
に設定した場合、プロキシ・テストは実行されず、接続プロキシが生成されます。
use-connection-proxies
が指定されていない場合、プロキシ・テストが実行されて、テストに合格するとプロキシが生成されます。(リソース・アダプタからClassCastException
がスローされなければ、テストに合格します)。
注意: テストでは、クライアント・コードによって発生したClassCastException は検出できません。 |
次の場合には、接続プールをリセットする必要があります。
他の実行中の接続プールに影響を与えずに接続プールを異常な状態から回復します。
更新操作により有効にならない、動的でない構成変更を行います。たとえば、ManagedConnectionFactory
のプロパティを変更するか、接続のトランザクション・サポートを変更します。
次のいずれかの方法で接続プールをリセットできます。
リセット: プール内の接続が使用中でない場合、プールが作成されます。新しいプールは、リセットする前に行われた構成の変更をすべて含みます。使用中の接続がある場合、プールはリセットされません。
強制リセット: すべての使用接続と未使用接続をすぐに廃棄し、プールが再作成されます。新しいプールは、リセットする前に行われた構成の変更をすべて含みます。
管理コンソールから接続プールをリセットするには、次の手順に従います。
「デプロイメント」表のサマリーから「リソース・アダプタ」を選択します。
「制御」>「アウトバウンド接続プール」を選択します。
リセットする接続プールを選択します。
リセットまたは、強制リセットをクリックします。
リソース・アダプタのManagedConnectionFactory
がValidatingManagedConnectionFactory
インタフェースを実装している場合、アプリケーション・サーバーでは既存の接続の有効性をテストできます。特定のManagedConnectionFactory
で、特定の発信接続または発信接続のプール全体をテストすることができます。プール全体のテストでは、プール内の各接続が個々にテストされます。この機能の詳細については、J2CA 1.5仕様(http://java.sun.com/j2ee/connector/
)の項6.5.3.4「Detecting Invalid Connections」を参照してください。
weblogic-ra.xml
デプロイメント記述子で以下の省略可能な要素を使用すると、プール内の接続のテストを制御できます。
test-frequency-seconds
: コネクタ・コンテナは、プール内のすべての空き接続を定期的にテストします。この要素を使用して、接続がテストされる頻度を指定します。デフォルトは0で、接続がテストされないことを意味します。
test-connections-on-create
: 作成時に接続をテストするかどうかを決定します。デフォルトはfalseです。
test-connections-on-release
: 解放時に接続をテストするかどうかを決定します。デフォルトはfalseです。
test-connections-on-reserve
: 予約時に接続をテストするかどうかを決定します。デフォルトはfalseです。
リソース・アダプタの接続プールをテストするには:
管理コンソールで、「デプロイメント」ページを開いて、「デプロイメント」表でリソース・アダプタを選択します。
「テスト」タブを選択します。
そのリソース・アダプタの接続プールの表と、各プールのテスト・ステータスが表示されています。
テストする接続プールを選択して、「テスト」をクリックします。
Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの発信接続のテストに関する項を参照してください。