5 接続管理
WebLogic Serverでは、Connector Architecture 1.6に準拠した接続管理をサポートしており、接続管理規約のサポート、アウトバンド接続、インバウンド接続および接続プーリングの構成のための標準モデル、接続テストのサポートなどを提供しています。
接続管理規約の詳細は、『JSR 322: Java EE Connector Architecture 1.6』の第6章「Connection Management」を参照してください。
接続管理規約
接続管理規約はConnector Architecture 1.6の要件であり、接続管理のための一貫したモデル、アプリケーション・サーバーがリソース・アダプタに提供する必要のある一連のサービスなどを指定しています。
WebLogic Serverとリソース・アダプタの間の接続管理規約は以下のとおりです。
-
管理対象と非管理対象(2層)の両方のアプリケーションに対して、接続の取得に関する一貫性のあるアプリケーション・プログラミング・モデルを提供します。
-
リソース・アダプタが、リソース・アダプタのタイプとEISに固有のCCI (common client interface)に基づいた接続ファクトリと接続インタフェースを提供できるようにします。これにより、既存のJDBC APIへの影響を最小限に抑えながら、JDBCドライバとJava EEコネクタ・アーキテクチャ1.6を協調させることができます。
-
アプリケーション・サーバーが、構成されたリソース・アダプタに対して様々なサービス(トランザクション、セキュリティ、高機能なプール、エラーの追跡とロギングなど)を提供できるようにします。
-
接続プールをサポートします。
リソース・アダプタ側の接続管理規約は、リソース・アダプタの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間の対話)を参照してください。
JNDIツリーにバインドされたリソース・アダプタ
バージョン1.5および1.6のリソース・アダプタは、独立したオブジェクトとしてJNDIツリーにバインドされるので、独立したシステム・リソースとして、またはメッセージドリブンBean (MDB)のメッセージ・ソースとして使用できます。一方、バージョン1.0のリソース・アダプタは、JNDIツリーにバインドされたConnectionFactory
オブジェクトによって識別されます。
バージョン1.5または1.6のリソース・アダプタでは、デプロイメント時に、ResourceAdapter
Beanがある場合は、weblogic-ra.xml
ファイルのExample A-要素の値を使用してJNDIツリーにバインドされます。その結果、管理者はリソース・アダプタを1つのデプロイ可能エンティティとして参照し、リソース・アダプタ・プロバイダによって公開されたリソース・アダプタの機能とやり取りすることができます。詳細は、「weblogic-ra.xmlスキーマ」のExample A-を参照してください。
ConnectionFactoryの取得(クライアントとJNDI間の対話)
アプリケーション・アセンブラまたはコンポーネント・プロバイダは、アプリケーションのデプロイメント記述子で、そのアプリケーション・コンポーネントの接続ファクトリの要件を構成します。たとえば:
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を参照)。 -
アプリケーション・コンポーネントは、返された接続を使用して基底のEISにアクセスします。
-
アプリケーション・コンポーネントは、
ConnectionFactory
のgetConnection
メソッドを呼び出してEIS接続を取得します。返された接続インスタンスは、基底の物理接続へのアプリケーション・レベルのハンドルを表します。アプリケーション・コンポーネントは、接続ファクトリのgetConnection
メソッドを複数回呼び出して、複数の接続を取得します。javax.resource.cci.Connection cx = cxf.getConnection();
-
接続を使い終わると、コンポーネントは
Connection
インタフェースのcloseメソッドを使用して接続を閉じます。cx.close();
アプリケーション・コンポーネントが割り当てられた接続を使用後に閉じなかった場合、その接続は未使用の接続と見なされます。未使用の接続のクリーン・アップはアプリケーション・サーバーによって管理されます。
例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
型のインスタンスが取得されます。
トランザクション・サポート・レベルの指定および取得
『JSR 322: Java EE Connector Architecture 1.6』の7.13項では、リソース・アダプタが実行時に提供するトランザクション・サポートのレベルを決定および分類できると指定されています。トランザクション・サポートのレベルを指定できるようにするには、リソース・アダプタのManagedConnectionFactory
クラスでTransactionSupport
インタフェースを実装する必要があります。このインタフェースが実装されないと、リソース・アダプタのra.xml
ファイルとConnector
注釈のマージ結果に指定されたトランザクション・サポートがコネクタ・コンテナによって使用されます。
『JSR 322: Java EE Connector Architecture 1.6』では、ra.xml
ファイル、Connector
注釈およびTransactionSupport
インタフェースで決定されるトランザクション・サポート・レベルの規則と優先度も定義されます。
WebLogic Serverは、次の2つのメソッドをConnectorConnectionPoolRuntimeMBean
で公開することで、トランザクション・サポート・レベルを取得するためのサポートを補完します。
-
ConnectorConnectionPoolRuntimeMBean.getRuntimeTransactionSupport()
— このコネクタ接続プールに対して使用中の実際のトランザクション・サポート・レベルを返します。この値は、WebLogic Server管理コンソールの「リソース・アダプタ」「監視」「アウトバウンド接続プール」ページでも参照できます。
-
ConnectorConnectionPoolRuntimeMBean.getTransactionSupport()
— このコネクタ接続プールのリソース・アダプタに対する、ra.xml
または@Connector注釈の使用によって構成されている、静的なトランザクション・サポート・レベルを返します。
共有不可能なManagedConnectionFactoryの指定
大半の場合、アダプタのManagedConnectionFactory
は、『JSR 322: Java EE Connector Architecture 1.6』の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
またはWebLogic Server管理コンソールでは何も構成する必要がありません。
ManagedConnectionFactory
が共有可能な場合、アダプタのコードでは何も変更する必要はありません。すべてのManagedConnectionFactory
インスタンスおよびプールは、ManagedConnectionFactory
に共有不可
注釈が含まれない場合でも、デフォルトでは共有可能とみなされます。
アウトバウンド接続の構成
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」を参照してください。
接続の再試行
アプリケーション・コンポーネントが、ConnectionFactory
におけるgetConnection()
メソッドを使用して接続プールから接続インスタンスを取得しようと試みても、プールが一時的に停止している場合は、WebLogic Serverでjavax.resource.spi.RetryableException
を実装する例外が発生します。アプリケーション・コンポーネントはRetryableException
のインスタンスを使用して、接続の失敗が一過性かどうかを判別できます。
アダプタの再デプロイなしの、アウトバウンド接続プール・エラーの分離、トラブルシューティングおよび修正
デフォルトでは、リソース・アダプタに複数のアウトバウンド接続プールがある場合に、いずれかの接続プールでエラーが発生すると、リソース・アダプタ・デプロイメント全体が失敗します。ただし、deploy-as-a-wholeデプロイメント・オプションを使用できるため、これを設定して、個々のアウトバウンド接続プール・エラーをリソース・アダプタ・デプロイメントから分離できます。このデプロイメント・オプションを使用すると、アダプタのヘルス監視機能を使用して接続プール・エラーを識別できます。これにより、リソース・アダプタを再デプロイすることなく、トラブルシューティングと修復が行えます。
リソース・アダプタのヘルス監視機能の詳細は、「リソース・アダプタのヘルス監視」を参照してください。weblogic-ra.xml
ファイルのdeploy-as-a-whole
要素の設定の詳細は、次のトピックを参照してください。
次の項では、deploy-as-a-wholeデプロイメント・オプションの使用方法およびアウトバウンド接続プール・エラーの診断方法と回復方法について説明します。
deploy-as-a-wholeオプションの使用
個々のアウトバウンド接続プールのエラーが原因でアダプタ・デプロイメント全体が失敗することがないように、リソース・アダプタをデプロイするには、weblogic-ra.xml
ファイルのdeploy-as-whole
要素をfalse
に設定する必要があります(デフォルトでは、この要素はtrue
に設定されます)。このデプロイメント・オプションの設定の詳細は、「複数のアウトバウンド接続プールで構成されたリソース・アダプタのデプロイ」を参照してください。
deploy-as-a-wholeオプションがfalse
に設定されている場合は、次のことに注意してください。
-
デプロイメント中にエラーが発生しなかった場合は、リソース・アダプタのデプロイメントが成功してアクティブ状態になります(ヘルス状態はHEALTH_OK)。
-
少なくとも1つのアウトバウンド接続プールを作成中または構成中にエラーが発生した場合は、アダプタ・デプロイメントのヘルス状態がHEALTH_CRITICALに設定されます。
-
次のようなその他のエラーが発生した場合は、アダプタのデプロイメントは失敗します。
-
ra.xml
ファイル、weblogic-ra.xml
ファイルまたはデプロイメント・プランの解析エラーまたは検証エラー。 -
リソース・アダプタや管理オブジェクトBeanの作成中または構成中に発生するエラー。
-
静的に検出可能な、『JSR 322: Java EE Connector Architecture 1.6』で定義された基本要件に合致しないプール関連のクラス。たとえば、必須の標準インタフェース
javax.resource.spi.ManagedConnectionFactory
を実装していないアダプタのManagedConnectionFactory
クラスなどがあります。
-
失敗した接続プールのトラブルシューティング
接続プールの状態がHEALTH_CRITICALである場合、ConnectorConnectionPoolRuntimeMBean
のほとんどのメソッド(testPool
など)では、起動してもIllegalStateException
がスローされます。起動できるのは次のメソッドのみです。これらは、静的情報を提供し、接続プール・エラーの影響は受けません。
-
getKey()
-
getPoolName()
-
getState()
(失敗したプールには常にShutdown
が返されます) -
getHealthState()
-
getManagedConnectionFactoryClassName()
-
getMCFClassName()
(getManagedConnectionFactoryClassName()
と同様) -
getConnectionFactoryClassName()
(接続プールのConnectionFactoryNameが返されます) -
reset()
-
forceReset()
次の点に注意してください。
-
次のいずれかのアクションの実行後は、リソース・アダプタ・モジュールのヘルス状態はHEALTH_OKからHEALTH_CRITICALに変わる可能性があります。
-
動的更新の実行
-
アウトバウンド接続プールの
reset
またはforce reset
のいずれかの実行 -
リソース・アダプタの停止と再起動
-
アダプタの再デプロイ
-
-
接続プールの状態がHEALTH_CRITICALである場合は、そのプールに対する
suspend
およびresume
アクションは効果がありません。
接続プールの回復ステップ
接続プールが失敗してHEALTH_CRITICAL状態になった場合は、失敗の理由を確認して、エラーを修正します。たとえば、プールの各プロパティの更新された値が有効で、適切に割り当てられていることを確認します。
不適切な構成により引き起こされたエラーのほとんどについて、次のステップを実行することをお薦めします。
- 必要に応じて、失敗した各プールの構成を変更します。
- 新しい構成をアダプタのデプロイメント・プランに保存します。
- 更新済のアダプタのデプロイメント・プランを使用して、リソース・アダプタの動的更新を実行します。
前述のステップでは、正常に機能している使用中の接続プールには影響を与えることなく、失敗したプールを回復できます。動的更新プロセスでは、失敗した接続プールはすべて、新しい構成データを使用して再作成されます。プールの構成変更が新しいデプロイメント・プランで行われたのかどうか、構成変更が動的に更新可能なのかどうかは関係ありません。正常に機能している既存の接続プールについては、動的でない構成変更は無視されます。ただし、失敗した接続プールの場合、構成の更新は動的更新プロセスから有効になります。
失敗した接続プールを回復するためのその他のオプション
失敗した接続プールを動的更新を実行して回復するかわりに、次のいずれかの方法を実行できます。失敗の原因が無効なプール構成以外の場合は、次のいずれかの方法が適しています。
-
「接続プールのリセット」に記載されているように、失敗した接続プールをリセットまたは強制リセットします。失敗の理由によっては、これらのアクションを実行しても、失敗したプールを回復できない場合があります。ただし、失敗したプールとの接続はアクティブでないため、リセットと強制リセットの効果は同じです。次の点に注意してください。
-
プール・エラーの原因が無効な構成でない場合は、リセットすると、プールを回復できる可能性があります。この場合は、既存の構成データが使用されます。たとえば、エラーの原因がJNDIの競合である場合は、JNDIツリーからの競合するオブジェクトを削除すると、プールを回復できます。このシナリオでは、接続プールのリセットをお薦めします。
-
接続プールの失敗の原因が無効な構成にある場合は、接続プールのリセットはお薦めしません。リセットでは、既存のデプロイメント・プランまたは既存のデプロイメント記述子情報が使用されるため、無効な構成データが含まれるからです。
-
-
アダプタを再デプロイします。このアクションは、正常に機能しているものも含めて、リソース・アダプタ内のすべてのアウトバウンド接続プールに影響します。
-
リソース・アダプタを停止してから再起動します。このアクションも、アダプタ内のすべてのアウトバウンド接続プールに影響します。この方法には、
reset
やforce reset
アクションを実行する場合と同じような短所があります。この方法でも、最初に動的更新を実行することなく、既存の構成データを使用するからです。また、修正はされたものの、動的更新で使用可能になっていない構成データは使用されません。こうした理由から、リソース・アダプタの停止と再起動は、ほとんどの場合、失敗した接続プールの回復で推奨されるオプションではありません。
複数のアウトバウンド接続の例
例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>
インバウンド接続の構成
Java EE Connector Architecture 1.7では、インバウンド・メッセージ接続をサポートするリソース・アダプタを構成できます。
着信接続を構成する主なステップは以下のとおりです。
weblogic-ra.xml
デプロイメント記述子でリソース・アダプタのJNDI名を指定します。表A-1のExample A-を参照してくださいra.xml
デプロイメント記述子で、サポートされる着信メッセージ・タイプごとに、メッセージ・リスナーとActivationSpec
を構成します。ActivationSpec
クラスの要件の詳細は、『JSR 322: Java EE Connector Architecture 1.6』の第13章「Message Inflow」を参照してください。- パッケージ化されるエンタープライズ・アプリケーションの中に、構成済みのEJBメッセージドリブンBean (MDB)を含めます。
weblogic-ejb-jar.xml
デプロイメント記述子のresource-adapter-jndi-name
要素で、上記のステップでリソース・アダプタに割り当てた同じJNDI名を指定します。この値を設定すると、MDBとリソース・アダプタが互いに通信できるようになります。 - リソース・アダプタがインバウンド接続で使用するセキュリティIDを構成します。リソース・アダプタがメッセージを受信するとき、その作業は特定のセキュリティIDで実行される必要があります。「リソース・アダプタのセキュリティIDの構成」を参照してください
- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』の説明に従ってリソース・アダプタをデプロイします。
- MDBをデプロイします。『Oracle WebLogic ServerメッセージドリブンBeanの開発』および『Oracle WebLogic Serverへのアプリケーションのデプロイ』のMDBのデプロイに関する項を参照してください。
例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>
例5-3では、ra.xml
デプロイメント記述子で、2つのメッセージ・リスナーおよびアクティブ化仕様を持つ着信接続を構成する方法を示しています。
接続プール・パラメータの構成
weblogic-ra.xml
デプロイメント記述子で、WebLogic Serverリソース・アダプタの接続プール・パラメータを構成します。
initial-capacity : ManagedConnectionの初期数の設定
ManagedConnection
が表すエンタープライズ情報システム(EIS)の複雑さによっては、ManagedConnection
の作成にコストがかかる可能性があります。WebLogic Serverの起動時に、接続プールに初期数のManagedConnection
を登録し、実行時には作成しないようにすることができます。この設定は、weblogic-ra.xml
記述子ファイルのinitial-capacity
要素を使用して構成します。この要素のデフォルト値は、1
ManagedConnection
です。
WebLogic Serverの起動時には開始セキュリティ・プリンシパルまたはリクエスト・コンテキスト情報が不明なので、サーバー・インスタンスは初期接続用の特別な資格証明マッピングをルックアップすることにより、セキュリティ・サブジェクトを使用して、初期接続を作成します。「初期接続:アプリケーションのリクエストがない場合、アダプタからのManagedConnectionが必要」を参照してください
ノート:
マッピングが見つからない場合は、WebLogic Serverはサブジェクトとしてnull
を使用します。
max-capacity : ManagedConnectionの最大数の設定
作成されるManagedConnection
の数が増えるほど、メモリーやディスク容量などのシステム・リソースが多く消費されます。エンタープライズ情報システム(EIS)によっては、この消費がシステム全般のパフォーマンスに影響します。システム・リソースに対するManagedConnection
の影響を制御するために、weblogic-ra.xml
デプロイメント記述子のmax-capacity
要素で、割り当てるManagedConnection
の最大数を指定できます。
接続リクエスト中にManagedConnection
(capacity-increment
が2以上の場合は複数のManagedConnection
)を新規作成する必要がある場合、WebLogic Serverが最大許容数を超えてManagedConnection
を作成することはありません。この制限を超えてManagedConnection
の割当をリクエストすると、呼出し側にResourceAllocationException
が返されます。
capacity-increment : ManagedConnectionの数の制御
コネクタ・アーキテクチャ1.6に従って、アプリケーション・コンポーネントがリソース・アダプタを介してEISとの接続を要求すると、WebLogic Serverはまず、接続プール内の既存で利用可能なManagedConnection
の中に、要求されている接続の種類と一致するものがないか探します。しかし、一致するものが見つからない場合には、新規のManagedConnection
を作成して接続リクエストに応じます。
weblogic-ra.xml
記述子ファイルのcapacity-increment
要素を使用して、一致するものが見つからない場合に作成される追加のManagedConnection
の数を指定できます。この機能により、時間の経過と共に増加する接続プールのサイズとサイズが増加するたびに低下するサーバーのパフォーマンスを柔軟に制御できます。
shrinking-enabled :システム・リソースの使用量の制御
ManagedConnection
の最大数を設定すると、処理能力を超えた数のManagedConnection
が割り当てられてサーバーが過負荷になることはありませんが、常に必要に応じてシステム・リソースの量が効率的に制御されるわけではありません。WebLogic Serverでは、リソース・アダプタの接続プール内のManagedConnection
の動作状況をモニターするサービスを利用できます。使用量が減少しそのレベルで一定期間とどまっている場合、接続プールのサイズは初期容量まで、またはできる限りそれに近く、継続的な接続リクエストを十分満たせる大きさにまで縮小されます。
このシステム・リソース使用量サービスはデフォルトで有効です。ただし、weblogic-ra.xml
記述子ファイルのshrinking-enabled
要素をfalse
に設定すると、このサービスを無効にできます。
shrink-frequency-seconds :未使用のManagedConnectionの再利用を試みるまで待機する時間の設定
weblogic-ra.xml
記述子ファイルのshrink-frequency-seconds
要素を使用すると、接続プール・マネージャが未使用のManagedConnection
を再利用しようとする間隔(秒単位)を指定できます。この要素のデフォルト値は、900
秒です。
highest-num-waiters :接続を待機するクライアントの数の制御
接続の最大数に達していて、利用可能な接続がない場合、WebLogic Serverは呼出しがタイムアウトするまで再試行します。highest-num-waiters
要素は、同時に接続を待機するクライアントの数を制御します。
highest-num-unavailable :使用できない接続の数の制御
接続が作成されて失敗した場合、その接続は使用不可リストに置かれます。WebLogic Serverは使用不可リストにある失敗した接続を再作成しようとします。highest-num-unavailable
要素は、使用不可リストに同時に存在できる使用不可接続の数を制御します。
connection-creation-retry-frequency-seconds :接続の再作成
追加のManagedConnection
の作成中に、失敗した接続を再作成するようにWebLogic Serverを構成するには、connection-creation-retry-frequency-seconds
要素を有効にします。デフォルトでは、この機能は無効です。
match-connections-supported :接続のマッチング
接続リクエストにはパラメータ情報が含まれています。デフォルトでは、コネクタ・コンテナはManagedConnectionFactory
のmatchManagedConnections()
メソッドを呼び出して、プール内の使用可能な接続をリクエスト内のパラメータと一致させます。一致に成功した接続が返されます。
ManagedConnectionFactory
がmatchManagedConnections()
の呼出しをサポートしていない場合もあります。その場合、matchManagedConnections()
メソッドの呼出しはjavax.resource.NotSupportedException
を返します。この例外が捕捉された場合、コネクタ・コンテナはManagedConnectionFactory
のmatchManagedConnections()
メソッドの呼出しを自動的に停止します。
match-connections-supported
要素を設定して、リソース・アダプタが接続のマッチングをサポートするかどうかを指定できます。デフォルトでは、この要素はtrueに設定されており、matchManagedConnections()
メソッドは少なくとも1回呼び出されます。falseに設定されている場合、このメソッドは呼び出されません。
接続のマッチングがサポートされていない場合は、リソースの最大数にまだ達していなければ、新しいリソースが作成されて返されます。最大数に達しているときは、最も古い使用不可のリソースがリフレッシュされて返されます。
test-connections-on-create :作成時の接続のテスト
test-connections-on-create
要素を設定して、接続が作成されるときの接続のテストを有効にすることができます。デフォルト値はfalse
です。
test-connections-on-release :接続プールへの解放時の接続のテスト
test-connections-on-release
要素を設定して、接続が接続プールに解放されるときの接続のテストを有効にすることができます。デフォルト値はfalse
です。
test-connections-on-reserve :予約時の接続のテスト
test-connections-on-reserve
要素を設定して、接続が接続プールから予約されるときの接続のテストを有効にすることができます。デフォルト値はfalse
です。
deploy-as-a-whole: アダプタ・デプロイメント全体からのアウトバウンド接続プール・エラーの分離
deploy-as-a-whole
要素を設定して、複数のアウトバウンド接続プールを含むリソース・アダプタのデプロイメントが、いずれかの接続プールにエラーが発生した場合に失敗になるかどうかを決定できます。デフォルト値はtrue
です。この設定では、(接続プールのエラーのみならず)なんらかのエラーが発生した場合にリソース・アダプタ・デプロイメント全体が失敗します。
この要素をfalse
に設定すると、少なくとも1つのアウトバウンド接続プールが正常であるかぎり、リソース・アダプタ・デプロイメントは成功し、再デプロイすることなく、リソース・アダプタの分離、診断、修復および動的更新が行えます。
接続プロキシ・ラッパー - 1.0リソース・アダプタ
-
接続リーク検出機能
-
接続を使用するグローバル・トランザクションの開始前に接続がリクエストされた場合のXAResourceの遅延登録
発生する可能性のあるClassCastException
接続リクエストで返された接続オブジェクトが(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ではJava EEコネクタ・アーキテクチャ1.0のリソース・アダプタが引続きサポートされます。1.0リソース・アダプタの場合は、weblogic-ra.xmlにあるWebLogic Server 8.1デプロイメント記述子を引き続き使用します。この記述子には1.0リソース・アダプタに対応する要素が含まれています。
true
に設定した場合、プロキシ・テストは実行されず、接続プロパティが生成されます。
false
に設定した場合、プロキシ・テストは実行されず、接続プロキシが生成されます。
use-connection-proxies
が指定されていない場合、プロキシ・テストが実行されて、テストを通過するとプロキシが生成されます(リソース・アダプタからClassCastException
がスローされなければ、テストに合格します)。
ノート:
テストでは、クライアント・コードによって発生したClassCastException
は検出できません。
接続プールのリセット
ManagedConnectionFactory
のプロパティを変更するか、接続のトランザクション・サポートを変更します。
次のいずれかの方法で接続プールをリセットできます。
-
リセット—プール内の接続が使用中でない場合、プールが作成されます。新しいプールは、リセットする前に行われた構成の変更をすべて含みます。使用中の接続がある場合、プールはリセットされません。
-
強制リセット—すべての使用接続と未使用接続をすぐに廃棄し、プールが再作成されます。新しいプールは、リセットする前に行われた構成の変更をすべて含みます。
WebLogic Server管理コンソールから接続プールをリセットするには、次のステップを実行します。
- 「デプロイメント」表のサマリーから「リソース・アダプタ」を選択します。
- 「制御」>「アウトバウンド接続プール」を選択します。
- リセットする接続プールを選択します。
- リセットまたは、強制リセットをクリックします。
接続のテスト
ManagedConnectionFactory
がValidating
インタフェースを実装している場合、アプリケーション・サーバーでは既存の接続の有効性をテストできます。 特定のManagedConnectionFactory
で、特定の発信接続または発信接続のプール全体をテストすることができます。プール全体のテストでは、プール内の各接続が個々にテストされます。『JSR 322: Java EE Connector Architecture 1.6』の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です。