| Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング 11gリリース1 (10.3.6) B60996-04 |
|
 前 |
 次 |
| 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管理コンソール・ヘルプの発信接続のテストに関する項を参照してください。
