| Oracle® Fusion Middleware Oracle WebLogic Serverリソース・アダプタの開発 12c (12.2.1) E70013-01 |
|
 前 |
 次 |
この章では、コネクタ・アーキテクチャ1.6の要件に従って、WebLogic Serverとリソース・アダプタの間の接続管理規約について説明します。アウトバウンド接続とインバウンド接続、接続プール・パラメータ、および接続のテスト方法についても説明します。
この章の内容は以下のとおりです。
接続管理規約の詳細は、『JSR 322: Java EE Connector Architecture 1.6』の第6章「Connection Management」を参照してください。
コネクタ・アーキテクチャ1.6の要件の1つは接続管理規約です。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間の対話)を参照してください。
バージョン1.5および1.6のリソース・アダプタは、独立したオブジェクトとしてJNDIツリーにバインドされるので、独立したシステム・リソースとして、またはメッセージドリブンBean (MDB)のメッセージ・ソースとして使用できます。一方、バージョン1.0のリソース・アダプタは、JNDIツリーにバインドされたConnectionFactoryオブジェクトによって識別されます。
バージョン1.5または1.6のリソース・アダプタでは、デプロイメント時に、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インスタンスをルックアップします(例6-1を参照)。
例6-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();
アプリケーション・コンポーネントが割り当てられた接続を使用後に閉じなかった場合、その接続は未使用の接続と見なされます。未使用の接続のクリーン・アップはアプリケーション・サーバーによって管理されます。
『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は、『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に共有不可注釈が含まれない場合でも、デフォルトでは共有可能とみなされます。
コネクタ・アーキテクチャ1.6に基づいたアウトバウンド・リソース・アダプタでは、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」を参照してください。
アプリケーション・コンポーネントが、ConnectionFactoryにおけるgetConnection()メソッドを使用して接続プールから接続インスタンスを取得しようと試みても、プールが一時的に停止している場合は、WebLogic Serverでjavax.resource.spi.RetryableExceptionを実装する例外が発生します。アプリケーション・コンポーネントはRetryableExceptionのインスタンスを使用して、接続の失敗が一過性かどうかを判別できます。
デフォルトでは、リソース・アダプタに複数のアウトバウンド接続プールがある場合に、いずれかの接続プールでエラーが発生すると、リソース・アダプタ・デプロイメント全体が失敗します。ただし、deploy-as-a-wholeデプロイメント・オプションを使用できるため、これを設定して、個々のアウトバウンド接続プール・エラーをリソース・アダプタ・デプロイメントから分離できます。このデプロイメント・オプションを使用すると、アダプタのヘルス監視機能を使用して接続プール・エラーを識別できます。これにより、リソース・アダプタを再デプロイすることなく、トラブルシューティングと修復が行えます。
リソース・アダプタのヘルス監視機能の全般的な情報については、「リソース・アダプタのヘルス監視」を参照してください。weblogic-ra.xmlファイルの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アクションを実行する場合と同じような短所があります。この方法でも、最初に動的更新を実行することなく、既存の構成データを使用するからです。また、修正はされたものの、動的更新で使用可能になっていない構成データは使用されません。こうした理由から、リソース・アダプタの停止と再起動は、ほとんどの場合、失敗した接続プールの回復で推奨されるオプションではありません。
例6-2は、複数の発信接続を構成したweblogic-ra.xmlデプロイメント記述子の例です。
例6-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>
コネクタ・アーキテクチャ1.6では、インバウンド・メッセージ接続をサポートするリソース・アダプタを構成できます。インバウンド接続を構成する主な手順は以下のとおりです。
weblogic-ra.xmlデプロイメント記述子でリソース・アダプタのJNDI名を指定します。「表A-1 Weblogic-connectorのサブ要素」の「jndi-name」を参照してください。
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 Enterprise JavaBeansバージョン2.1の開発』のメッセージドリブンEJBに関する項および『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。
例6-3では、ra.xmlデプロイメント記述子で、2つのメッセージ・リスナーおよびアクティブ化仕様を持つ着信接続を構成する方法を示しています。
例6-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が返されます。
コネクタ・アーキテクチャ1.6に従って、アプリケーション・コンポーネントがリソース・アダプタを介して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です。
test-connections-on-reserve要素を設定して、接続が接続プールから予約されるときの接続のテストを有効にすることができます。デフォルト値はfalseです。
deploy-as-a-whole要素を設定して、複数のアウトバウンド接続プールを含むリソース・アダプタのデプロイメントが、いずれかの接続プールにエラーが発生した場合に失敗になるかどうかを決定できます。デフォルト値はtrueです。この設定では、(接続プールのエラーのみならず)なんらかのエラーが発生した場合にリソース・アダプタ・デプロイメント全体が失敗します。
この要素をfalseに設定すると、少なくとも1つのアウトバウンド接続プールが正常であるかぎり、リソース・アダプタ・デプロイメントは成功し、再デプロイすることなく、リソース・アダプタの分離、診断、修復および動的更新が行えます。
接続プロキシ・ラッパー機能は、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では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です。
リソース・アダプタの接続プールをテストするには:
WebLogic Server管理コンソールで、「デプロイメント」ページを開いて、「デプロイメント」表でリソース・アダプタを選択します。
「テスト」タブを選択します。
そのリソース・アダプタの接続プールの表と、各プールのテスト・ステータスが表示されています。
テストする接続プールを選択して、「テスト」をクリックします。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのアウトバウンド接続のテストに関する項を参照してください。
