3 接続管理

この章では、OC4Jの管理者がリソース・アダプタ接続用の構成を設定する方法の詳細について説明し、J2CAの接続管理規約を要約し、アプリケーションのコンポーネントが接続を取得する方法について説明します。ここでは次の項目を含みます。

• EIS接続の取得の方法

• コネクション・ファクトリのバインドと構成: 基本的な設定

• OC4Jにおける接続プーリングの構成

• 接続プールの共有

• コネクション・ファクトリ用のOC4Jのロギングの構成

• リソース・アダプタ接続の取得

• 接続管理規約の要約

• リソース・アダプタ接続のメトリック

注意: ここで説明されているApplication Server Controlコンソール・ページの概要は、「リソース・アダプタ用のApplication Server Controlページの概要」を参照してください。この章の説明は適切な「リソース・アダプタ」ホームページを開いた時点から始めます。

EIS接続の取得の方法

EISのリソースを使用するために、J2EEアプリケーションのコンポーネントは接続オブジェクトを取得し、基礎となる接続を使用してその機能（希望どおりのデータの読取りまたは書込み）を実行し、その後接続を閉じます。

接続オブジェクトはリソース・アダプタ・プロバイダによって実装されるコネクション・ファクトリを通して取得されます。コネクション・ファクトリ・オブジェクトは構成手順を通してJNDIのネームスペースに登録され、接続オブジェクトを返すメソッドを持っています。アプリケーションのコンポーネントはJNDIルックアップを行ってファクトリを取得し、その後そのファクトリを通して接続を取得するためにリクエストします。ファクトリはリクエストをOC4Jに委任します。（OC4JのJNDI実装の詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。）

CCIを実装するリソース・アダプタにとって、ファクトリはCCI（javax.resource.cci）のConnectionFactoryインタフェースを実装するクラスのインスタンスであり、それはCCIのConnectionインタフェースを実装するクラスのインスタンスを返すgetConnection()メソッドを指定します。

J2EE Connector Architectureにおいて、ここで説明した機能は接続管理規約の中で指定されており、「接続管理規約の要約」で完全に要約されています。この規約はEISへの接続の作成方法、およびコネクション・ファクトリ用のJNDI構成の設定方法を指定しています。それはまた、OC4JのようなJ2EEコンテナが、EISのリソースおよびアプリケーションのスケーラビリティの効果的な使用においてクリティカルである接続プーリングをどのようにサポートできるかについての概要を提供し、接続プールの中で一致する物理接続の検索方法について指定します。管理者の接続プーリングのOC4J実装の構成方法については、「OC4Jにおける接続プーリングの構成」を参照してください。

次の「コネクション・ファクトリのバインドと構成: 基本的な設定」では、管理者がコネクション・ファクトリをどのように設定するかについて説明します。

コネクション・ファクトリのバインドと構成: 基本的な設定

アプリケーションのコンポーネントがEISへの接続を使用する前に、1つ以上のコネクション・ファクトリが構成される必要があります。この項では、リソース・アダプタを構成し、それをJNDIにバインドする最も基本的な手順を示します。コネクション・ファクトリ用の接続プーリングの構成といったより高度な手順については、この章の後の方で説明します。セキュリティの構成といったその他の手順については、このドキュメントの後の方で説明します。

「リソース・アダプタ接続の取得」 はアプリケーションのコードの中でのコネクション・ファクトリの使用方法について示しています。

コネクション・ファクトリの作成とバインド

リソース・アダプタをデプロイするときに、OC4Jはra.xmlファイルにパッケージ化された対応するエントリをデフォルトとして使用して（RARファイル内にパッケージ化されていない場合）oc4j-ra.xmlファイルを生成します。

定義されたそれぞれの接続タイプ用に、OC4Jはデプロイの間にoc4j-ra.xmlの<connector-factory>要素を生成します。（J2EE Connector Architecture Specificationのバージョン1.5では、接続のタイプはra.xmlファイルの<connection-definition>要素に対応します。）さらにリソース・アダプタの構成の際にOC4Jは、Application Server Controlコンソールを通して指定され、ra.xmlのエントリを補足したりオーバーライドしたりする任意の設定用に、<connector-factory>要素の下にサブ要素を生成します。

ra.xmlファイルの中の接続タイプ用の一意の識別子がコネクション・ファクトリ・インタフェースです。1つのインタフェースは、それぞれのra.xmlの接続定義の一部として指定されます。しかしoc4j-ra.xmlにおいて、同じコネクション・ファクトリ・インタフェースを使用しており、それゆえに同じra.xml接続定義に対応している複数のコネクション・ファクトリ（すなわち複数の<connector-factory>要素）が最終的には存在する場合があります。ここでの要点は、要望に応じて、それぞれのコネクション・ファクトリを異なったプロパティ設定で構成することです。たとえば、異なるサーバーに接続するために異なるコネクション・ファクトリを使用できます。（それぞれのコネクション・ファクトリ用に指定するJNDIロケーションはそのコネクション・ファクトリに一意である必要があります。）

コネクション・ファクトリの作成における重要な手順はそれをバインドすることであり、バインディングはJNDIロケーションの指定でなり立っています。このための最も簡単なシナリオは、構成プロパティ用にデフォルトのアセンブルされた値、すなわちra.xmlファイルからの値を使用することです。（この説明では、ra.xmlの中にオプションである値が指定されていると仮定します。）しかし、コネクション・ファクトリを作成するときに、構成プロパティ用に新しいデプロイの値を指定することもできます。

コネクション・ファクトリ用に接続プーリングが必要かどうかも指定しますが、もし必要であれば、プライベート・プールと共有プールのどちらを使用するかを指定します。

Application Server Controlコンソールで次のようにします。

1. 適切なリソース・アダプタ（もしデプロイされていれば、たとえばジェネリックJMSリソース・アダプタ）用の「リソース・アダプタ」ホームページからアクセスした「コネクション・ファクトリ」タブで、「作成」機能を選択して新しいコネクション・ファクトリのバインディングのプロセスを始めます。

2. 「コネクション・ファクトリの作成」の「インタフェースの選択」ページで希望のコネクション・ファクトリ・インタフェースを選択します。J2CA 1.5アダプタの場合、各選択はra.xmlファイル内の1つの接続定義のみに対応します。バージョン1.0のアダプタの場合、選択肢は1つのみです。（たとえば、通常のJMSリソース・アダプタの場合は、QueueConnectionFactory、XAQueueConnectionFactory、TopicConnectionFactoryおよびXATopicConnectionFactoryの選択肢があります。）

3. 表示された「コネクション・ファクトリの作成」ページにおいて次の手順を行います。

   • JNDIロケーションを指定します（必須）。

   • コネクション・ファクトリについて、接続プールを使用しない（デフォルト）、プライベート接続プールを使用する、共有接続プールを使用する、の内のどれかを指定します。共有プーリングを使用するためには、少なくとも1つの共有プールがすでに存在している必要があり、またどの共有プールを使用するかを選択する必要があります。接続プールの詳細は、「OC4Jにおける接続プーリングの構成」および「接続プールの共有」を参照してください。

   • オプションで、コネクション・ファクトリの構成プロパティを編集します。

4. 「コネクション・ファクトリの作成」ページにおいて「終了」機能を選択してコネクション・ファクトリをバインドします。

この構成の結果、OC4Jはoc4j-ra.xmlファイル内に<connector-factory>要素を生成します。表3-1はコネクション・ファクトリ・インタフェースとJNDIロケーションを表すプロパティを示しています。

Application Server Controlオンライン・ヘルプの「コネクション・ファクトリの作成:インタフェースの選択」ページに関する状況依存トピックも参照してください。

表3-1 コネクション・ファクトリの基本的なプロパティ

Application Server Controlプロパティ	対応するXMLエンティティ	説明
コネクション・ファクトリ・インタフェース。	<connectionfactory-interface>サブ要素	コネクション・ファクトリ用に使用するJavaインタフェースです。
JNDIロケーション。	location属性	コネクション・ファクトリ・オブジェクトがバインドされるJNDIロケーションです。
リソース・アダプタに適用され、構成プロパティに示されている名前および値属性。または編集中には、名前、アセンブルされた値およびデプロイ済の値によって示されるもの。（名前およびアセンブルされた値はra.xmlによる。）	<config-property>のNameおよびValue属性	これらの属性はコネクション・ファクトリ構成プロパティの名前および目的のデプロイ済の値に対応します。

注意: コネクション・ファクトリのバインディングはすぐに有効になり、OC4Jの再起動は必要ありません。（アプリケーションとともにパッケージ化されたoc4j-ra.xmlファイルの中にあらかじめ構成されたコネクション・ファクトリのバインディングは、リソース・アダプタのデプロイまたはOC4Jの起動に続いて関連するリソース・アダプタが初期化されるときに発生します。）

既存のコネクション・ファクトリの構成プロパティの編集

以前に作成し、バインドしたコネクション・ファクトリの設定を編集できます。

Application Server Controlコンソールで次のようにします。

1. 適切なリソース・アダプタ用の「リソース・アダプタ」ホームページからアクセスした「コネクション・ファクトリ」タブで、以前に構成済のコネクション・ファクトリのJNDIロケーションを選択します。JNDIロケーションはコネクション・ファクトリの識別子として機能しており、編集できないことに注意してください。アセンブルされた値はra.xmlエントリからのものです。

2. 「コネクション・ファクトリの編集」ページが表示されたら「一般」タブにアクセスし、そこで任意の編集可能な構成プロパティの新しいデプロイ済の値を指定できます。コネクション・ファクトリがプライベート接続プーリングまたは共有接続プーリングを有効にして作成された場合は、このページから接続プールも構成できます。詳細は次の項、「OC4Jにおける接続プーリングの構成」を参照してください。

3. 同じページで変更を適用します。

コネクション・ファクトリを編集するとき、OC4Jはra.xmlまたはoc4j-ra.xmlの以前の設定をオーバーライドするためにoc4j-ra.xmlに<config-property>要素を追加するか更新します。

Application Server Controlオンライン・ヘルプの「リソース・アダプタ」の「コネクション・ファクトリ」ページに関する状況依存トピックも参照してください。

注意: これらの変更を有効にするためにはOC4Jを再起動する必要があります。

OC4Jにおける接続プーリングの構成

パフォーマンスとスケーラビリティのために、J2EE Connector Architectureはいかなるアプリケーション・サーバー・プロバイダによる接続プーリングの実装もサポートしています。この項では、基本的な構成から始め、次にOC4J 10.1.3実装において追加された接続プーリングの拡張機能を取り上げながら、OC4Jにおいて接続プーリングをどのように構成するかを説明します。

コネクション・ファクトリを作成するときに接続プーリングを有効にするかどうかを決め、コネクション・ファクトリを編集するときに適切なプールを構成できます。

注意: OC4Jの起動中またはリソース・アダプタがデプロイされるときに、接続プールは初期化されます。 接続プールは1つのコネクション・ファクトリに対してプライベートであるか、または複数のコネクション・ファクトリの間で共有可能ですが、ここで説明される構成情報は一般的にどちらの場合にも適用されます。共有可能なプールについては、「接続プールの共有」を参照してください。

oc4j-ra.xmlファイルの<connector-factory>要素の下に<connection-pooling>サブ要素が存在することは、<connection-pooling>要素がuse="none"属性設定を持たないかぎり、接続プーリングが対応するコネクション・ファクトリ用に使用されることを暗示しています。Application Server Controlを通して接続プーリングを構成するとき、OC4Jは、それぞれの接続プーリングに設定したプロパティ用の<property>サブ要素とともに<connection-pooling>要素を生成します。

接続プーリングを構成しない場合、OC4Jはアプリケーションが接続をリクエストするときはいつでも新しい物理接続を作成するというデフォルトの動作を提示します。Application Server Controlコンソールを通して、任意のコネクション・ファクトリ用に接続プーリングを明示的に指定しないこともできます。

注意: J2EE Connector Architectureはデータベースに固有であるよりむしろ一般的であるので、コネクタ・アーキテクチャの接続プーリング・インタフェースはJDBCの接続プーリング・インタフェースとは著しく異なっています。

接続プールの構成の残りの説明は次のようになっています。

• コネクション・ファクトリ用の接続プーリングの有効化

• 接続プールの構成

• プーリング・スキーム、最小接続数と最大接続数および初期容量

• 期限切れまたは無効な接続のチェック

• 接続プールの実行時構成のOC4Jサポート

コネクション・ファクトリ用の接続プーリングの有効化

「コネクション・ファクトリの作成とバインド」に記載のとおり、コネクション・ファクトリを作成するときにコネクション・ファクトリ用の接続プーリングを使用するかどうかを選択します。作成の際に、コネクション・ファクトリが接続プールを使用しない（デフォルト）、プライベート接続プールを使用する、または共有接続プールを使用するの内のどれかを指定する必要があります。共有プーリングを使用するためには、少なくとも1つの共有プールがすでに存在している必要があり、どの共有プールを使用するかを選択する必要があります。（共有プールについては、「接続プールの共有」を参照してください。）

表3-2は、Application Server Controlコンソールの「コネクション・ファクトリの作成」ページの関連するプロパティを示しています。

表3-2 接続プーリングを有効化、無効化するプロパティ

Application Server Controlプロパティ	対応するXMLエンティティ	説明
接続プールなし	use="none"を持つ<connection-pooling>	構成中のコネクション・ファクトリ用に接続プーリングを無効にします。
プライベート接続プールの使用	use="private"を持つ<connection-pooling>	構成中のコネクション・ファクトリ用にプライベート接続プールの使用を指定します。
共有接続プールの使用	use="shared"を持つ<connection-pooling>	構成中のコネクション・ファクトリ用に共有接続プールの使用を指定します。
（指示された共有接続プールの名前）	<use-connection-pool>	使用する共有接続プールの名前です。

注意: oc4j-ra.xmlのOC4Jのバージョン9.0.4がOC4J 10.1.3を実装するサーバーにデプロイされる場合、任意の<connection-pooling>要素の属性にはデフォルトでuse="private"が設定されます。この属性はOC4J 9.0.4実装においては使用されていませんでした。その他のサポートされる設定には、この章の後の方で説明するように、接続プーリングがない場合のnone、共有プールを使用する場合のsharedがあります。

接続プールの構成

プールがプライベートであるか共有であるかにかかわらず、接続プールの構成はそれを使用するコネクション・ファクトリを編集することによって変更可能です。

Application Server Controlコンソールで次のようにします。

1. 「リソース・アダプタ」ホームページからアクセスした「コネクション・ファクトリ」タブで、適切なJNDIロケーションを選択し、該当するコネクション・ファクトリを選択します。

2. 「コネクション・ファクトリの編集」ページが表示されたら「一般」タブから、共有接続プールまたは「プライベート」のうち該当するものを選択します。

3. 「プライベート接続プール」ページ（または共有プール用の「共有接続プール」ページ）が表示されたら、そこで接続プール・パラメータ用に目的の設定を指定します。これらのパラメータの詳細は次の項、「プーリング・スキーム、最小接続数と最大接続数および初期容量」および 「期限切れまたは無効な接続のチェック」を参照してください。

4. 変更を適用します。

Application Server Controlオンライン・ヘルプの「プライベート接続プール」ページおよび「共有接続プール」ページに関する状況依存トピックも参照してください。

プーリング・スキーム、最小接続数と最大接続数および初期容量

表3-3はOC4J 9.0.4実装からサポートされている基本的な接続プーリングの設定を要約しています。Application Server Controlコンソールの「プライベート接続プール」ページ（または共有プール用の「共有接続プール」ページ）においてこれらを表示し、編集できます。OC4Jはoc4j-ra.xml内の適切な<connection-pooling>要素（または共有プール用には適切な<connection-pool>要素）の<property>サブ要素にそれぞれの設定を反映します。

表3-3 基本的な接続プール・プロパティ

Application Server Controlプロパティ	対応するXMLエンティティ	説明
接続プーリング・スキーム	name="scheme"およびvalue="dynamic"、"fixed"または"fixed_wait"を持つ<property>	接続が最大数に達した後でOC4Jが接続リクエストをどのように扱うかを示します。この表の後の方で説明するように、この属性は「動的」、「固定」または「固定待機」の設定をサポートします。
最大接続数	name="maxConnections"および必要に応じてvalueを持つ<property>	プログラム実行中にプール内で維持する接続の望ましい最大数です。値が指定されないか0が指定される場合は接続数の制限はありません。
最小接続数	name="minConnections"および必要に応じてvalueを持つ<property>	プログラム実行中にプール内で維持する接続の望ましい最小数です。デフォルト値は0です。
初期容量	name="initial-capacity"および必要に応じてvalueを持つ<property>	接続プールの初期化中に作成するOC4J用の接続の望ましい数です。指定した初期容量が指定した最小接続数よりも小さい場合、追加の接続は一度作成されると接続の数が最小数を超えるまでプールから削除されません。 注意: 初期容量はプライベート接続プールだけに適用され、共有接続プールには適用されません。 注意: 初期化のときJNDIコンテキストといった必要な情報が不足しているために、OC4Jが指定された数の接続を開くことができない場合があります。
固定待機タイムアウト	name="waitTimeout"および必要に応じてvalueを持つ<property>	接続数が最大数を超えていて、かつ固定待機スキームが有効である場合に、使用できる接続を待つ最大秒数です。（そうでない場合はこのプロパティは無視されます。）デフォルトはタイムアウトなしです。

サポートされている3つの接続プーリング・スキームを次に説明します。

• 動的は最大数の制限に違反しても常に新しい接続を作成し、アプリケーションにそれを返します。プールが最大数の制限を超えている場合は、次に接続が閉じられるときに接続はプールに返されるかわりに破棄されます。これはデフォルトの設定です。

• 固定は最大数の制限に達した後にアプリケーションが接続をリクエストすると例外を上げます。

• 固定待機は接続が使用できるようになるまでアプリケーションをブロックし、接続をプールに返します。固定待機タイムアウトのプロパティが指定されると、指定された待機タイムアウト期間内に接続が使用可能にならない場合、OC4Jは例外をスローします。

初期容量パラメータは、起動時に接続の需要が特に多いと予想される場合に便利です。たとえば、最小接続数の設定が5であり、最大接続数の設定が50である接続プールがあり、起動時に接続の需要が多いと想定される場合、初期容量を25に設定できます。初期要求が終わったとき、非アクティブ接続タイムアウトのパラメータ（次の項「期限切れまたは無効な接続のチェック」において説明）を使用して、次のピーク使用期間までプールを最小接続数まで縮小することが可能です。

注意: 任意のoc4j-ra.xmlファイルにおいて、 use="private"を持つ<connection-pooling>要素はあるが接続プール・プロパティが指定されていない場合、OC4Jは動的接続プーリング・スキームを使用し、最小接続数または最大接続数の初期設定を行わないでデフォルトのプール構成を行います。また、接続プールが初期化されるときに接続は事前に作成されません。

期限切れまたは無効な接続のチェック

OC4J 10.1.3実装では、接続プール内の期限切れまたは無効とマークされた接続の削除のサポートが追加されました。プール内の使用されていない接続をチェックすることにより、OC4JはJ2EEアプリケーションに接続を渡すときにそれが有効であることを保証できます。

接続はネットワークのタイムアウトまたは内部エラーによって無効になることがあります。OC4Jの無効な接続チェックを有効にするためには、リソース・アダプタ・プロバイダはオプションのValidatingManagedConnectionFactoryインタフェースを実装してどの接続が無効であるかを指定する必要があります。このインタフェースはコネクション・ファクトリの基礎となるManagedConnectionFactory実装クラスの中にあり、SPI（javax.resource.spi）パッケージの一部です。管理コネクション・ファクトリとその使用方法の詳細は、「接続管理規約の要約」を参照してください。

次のようにしてチェック機能を有効にします。

• OC4Jが無効または期限切れの接続をチェックする頻度は、期限切れ接続のクリーンアップのパラメータによります。

• 接続が期限切れになるタイムアウト値は非アクティブ接続タイムアウトのパラメータによります。プール内の接続がその時間使用されないと取り消されます。

Application Server Controlコンソールの「プライベート接続プール」ページ（または共有プール用の「共有接続プール」ページ）のこれらのパラメータは表3-4に要約されます。

これらのパラメータの設定によりOC4Jは、チェックを行わない、無効な接続だけをチェックする（接続が期限切れにならないと設定されている場合）、無効な接続および（指定されたタイムアウトにより）期限切れの接続の両方をチェックするのどれかを行います。

それぞれの設定はOC4Jによって、適切な<connection-pooling>要素の<property>サブ要素に反映されます。

表3-4 無効な接続または期限切れ接続のチェックの設定

Application Server Controlプロパティ	対応するXMLエンティティ	説明
期限切れ接続のクリーンアップ	name="inactivity-timeout-check"およびvalue="never"、"periodic"、"piggyback"または"all"を持つ<property>	期限切れの接続または非アクティブな接続のチェックを行うタイミングです。次に説明されるように、サポートされる値は"never"、"periodic"、"piggyback"（新しいコネクションがフェッチされるとき）および"all"（周期的および新しいコネクションがフェッチされるとき）です。 リソース・アダプタをデプロイする前に、oc4j-ra.xmlファイルのinactivity- timeout-checkプロパティを設定してください。
非アクティブ接続タイムアウト	name="inactivity-timeout"および必要に応じてvalueを持つ<property>	目的の接続のタイムアウト時間です。単位はミリ秒で、正の整数、または期限切れしない接続用には0を指定します。負の値は使用できません。

期限切れ接続のクリーンアップは次のように使用します。

• "never"は期限切れの接続または無効な接続をチェックしません。これは期限切れの接続または無効な接続のチェックを無効化するのに効果的です。ピークの使用に備えて最大接続数に大きな数を指定した場合、"never"を使用して接続プールのサイズを使用中の接続のセットにトリミングすることが可能です。常に使用中の接続の数が最大接続数に近いため接続プール内で非アクティブの状態がほとんど発生しない場合、"never"の指定はサーバーのパフォーマンスの最適化に役立ちます。

• "periodic"はデフォルト値で、たとえば10分ごとのように設定した時間の後で繰り返しチェックを行います。チェックに使用される期間はOC4Jのタスク・マネージャのgranularityの設定によります。（間隔はミリ秒単位です）これはApplication Server ControlのJMX管理コンソールを通して構成可能であり、OC4Jのserver.xmlファイルの<application-server>要素のtaskmanager-granularity属性の値に反映されます。このパラメータへのいかなる変更も、他のOC4JタスクおよびOC4Jのパフォーマンスに影響することに注意してください。タスク・マネージャの粒度の情報は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。

• "piggyback"（新しい接続がフェッチされるとき）は新しい接続がリクエストされるときだけチェックします。

• "all"（周期的および新しい接続がフェッチされるとき）は周期的チェックと接続がリクエストされるときのチェックとの両方を行います。

接続がプールから削除されるとき、destroy()メソッドがコールされます。

注意: 無効な接続または期限切れの接続の削除により、プール内の接続数が希望する最小数を下回る場合、OC4Jは必要に応じて新しい接続を作成します。

接続プールの実行時構成のOC4Jサポート

前の項で説明したパラメータへの変更をプログラム実行中に行うことができます。（初期容量は例外であり、OC4Jの起動時にのみ有効になります）変更は動的で、OC4Jの再起動を必要としません。次に実行時の変更がサポートされているパラメータを、関連するOC4Jの動作の注意とともにリストします。

• 接続プーリング・スキーム: 新しいスキームはアプリケーションによる次の接続リクエストによって適用されます。元のスキームが固定待機であった場合、新しいスキームは保留中のあらゆる接続リクエストに対して有効になります。新しいスキームが固定である場合、使用できる接続を待っているあらゆる接続リクエストに対して例外となります。元のスキームが動的であり、スキームを固定または固定待機に変更したときに、接続数が希望する最大数よりも大きい場合、OC4Jは使用されていないあらゆる接続を閉じてプールから削除することにより最大数の監視を試みます。

• 最大接続数: 新しい値がプール内に存在する接続数よりも小さい場合、OC4Jは使用されていないあらゆる接続を閉じます。使用中の接続数が新しい最大値よりもまだ大きい場合、接続がアプリケーションによって閉じられるとき、接続数が新しい最大数を下回るまではプールに返されません。

• 最小接続数: 新しい値がプールに存在する接続数よりも大きい場合、OC4Jは新しい最小数を満たすのに十分な数の新しい接続を作成します。

• 待機タイムアウト: 新しい値はスキームが固定待機であると仮定して次の接続リクエストによって適用されます。

• 非アクティブ接続タイムアウト: 新しい値は次にOC4Jが期限切れの接続をチェックするときに適用されます。0であった値が今は正の整数である場合、OC4Jは期限切れの接続のチェックを開始します。この場合、期限切れ接続のクリーンアップの値が"never"であれば"periodic"に変更されます。

• 期限切れ接続のクリーンアップ: 古い値が"periodic"または"all"（周期的および新しい接続がフェッチされるとき）であった場合、次の周期的なチェックは依然として行われる場合があります。

接続プールの共有

すべてのファクトリが同じリソース・アダプタ用であり同じ管理コネクション・ファクトリの実装クラスを使用するのであれば、OC4J 10.1.3実装を始めとして、1つの接続プールを共有するための複数のコネクション・ファクトリ用のサポートが存在します。このことによって、ユーザーは同じタイプのEISへの同時接続の数をよりよく管理でき、また1つのリソース・アダプタとともに使用されているすべてのコネクション・ファクトリ用に同じ接続プールを活用できます。

この項では次の項目を含む共有接続プールについて説明します。

• 共有接続プールの作成および構成

• 共有接続プールの編集および再構成

• 共有接続プールの使用

共有接続プールの作成および構成

共有可能な接続プールを作成するために、Application Server Controlコンソールで次のようにします。

1. 「リソース・アダプタ」ホームページからアクセスできる「コネクション・ファクトリ」タブに移動します。

2. 「共有接続プール」の下の「作成」機能を選択します。

3. 「共有接続プールの作成」ページが表示されたらそこでSharedPool1といった希望するプール名を指定します。後にコネクション・ファクトリ用に使用するときにこの名前で参照します。このプロパティを表3-5にまとめます。

4. 希望どおりパラメータを設定します。これらは「プーリング・スキーム、最小接続数と最大接続数および初期容量」および「期限切れまたは無効な接続のチェック」で説明されているように、プライベート接続プールと同じ方法で使用されます。

5. 変更を適用します。

OC4Jは、1つのコネクション・ファクトリに関連付けられるプライベート・プール用には<connector-factory>要素の下に<connection-pooling>要素を生成しますが、共有接続プール用にはoc4j-ra.xmlファイルの<oc4j-connector-factories>ルート要素の直下に<connection-pool>要素を生成します。

共有プール用にサポートされるプロパティは、特定のコネクション・ファクトリに特有のプール用のプロパティと同じです。oc4j-ra.xmlファイルで、これらは<connector-factory>要素のサブ要素である<connection-pooling>要素の<property>サブ要素のかわりに、<connection-pool>要素の<property>サブ要素に含まれます。

Application Server Controlオンライン・ヘルプの「共有接続プールの作成」ページに関する状況依存トピックも参照してください。

表3-5 共有接続プールのName属性

Application Server Controlプロパティ	対応するXMLエンティティ	説明
接続プール名（共有接続プールにのみ適用可能）	<connection-pool>のname属性	コネクション・ファクトリ間での共有を可能にする接続プールの希望する名前です。

注意: 実行時の変更は、プライベート接続プールと同様に共有接続プールにおいてもサポートされています。「接続プールの実行時構成のOC4Jサポート」を参照してください。

共有接続プールの編集および再構成

存在する共有接続プールの編集は次のようにします。

1. Application Server Controlコンソールで、次の2つの方法のいずれかで「共有接続プール」ページに移動できます。

   • 「リソース・アダプタ」ホームページからアクセスできる「コネクション・ファクトリ」タブにおいて、「共有接続プール」の下のリストから編集するプールを選択します。

   • 「コネクション・ファクトリ」タブにおいて、編集する共有接続プールを使用するコネクション・ファクトリを選択します。

2. 「コネクション・ファクトリの編集」ページが表示されたら共有接続プールを選択します。

3. 「共有接続プール」ページが表示されたら希望するパラメータを設定します。

   パラメータは、「プーリング・スキーム、最小接続数と最大接続数および初期容量」および「期限切れまたは無効な接続のチェック」で説明されているように、プライベート接続プールと同じ方法で使用されます。

4. 変更を適用します。

Application Server Controlオンライン・ヘルプの「共有接続プール」ページに関する状況依存トピックも参照してください。

注意: 存在する共有接続プールの名前を変更することはできません。

共有接続プールの使用

「コネクション・ファクトリ用の接続プーリングの有効化」に記載のとおり、Application Server Controlコンソールの「コネクション・ファクトリの作成」ページにおいて、最初にコネクション・ファクトリを作成するときに、共有接続プーリングを使用するか、プライベート接続プーリングを使用するか、接続プーリングは使用しないかを指定します。共有接続プーリングの使用を選択した場合、どの共有プールを使用するかも指定する必要があります。

コネクション・ファクトリが共有接続プールを使用する際に、OC4Jは（適切な<connector-factory>要素の下に）適切なコネクション・ファクトリ用の<connection-pooling>要素を追加し、その属性にuse="shared"を設定し、また共有プールの名前を指定する値とともに<use-connection-pool>サブ要素を設定してoc4j-ra.xmlファイルを更新します。この名前は使用されている共有可能なプールを指定する<connection-pool>要素のname属性に対応します。

注意: <connection-pooling>要素が<use-connection-pool>サブ要素を持つ場合、OC4Jはプライベート・プールに関連するどのような<property>サブ要素も無視します。 <connection-pooling>要素の属性設定がuse="shared"であっても、<use-connection-pool>サブ要素がない場合、OC4Jは例外をスローします。 コネクション・ファクトリが共有接続プールを使用することを指定した後、変更を有効にするためにOC4Jを再起動する必要があります。

コネクション・ファクトリ用のOC4Jのロギングの構成

J2EE Connector Architectureはシステム・レベルのエラーのロギングおよび特定の管理コネクション・ファクトリのトレースのオプション機能を含んでいます。これらの機能を使用して、アプリケーション・サーバーはリソース・アダプタまたはEISのエラー状態を検出し、エラー情報を問題のデバッグにおいて使用できます。アプリケーション・サーバーはログ・ライターと管理コネクション・ファクトリとの関連付けを管理します。

OC4JではApplication Server Controlを通して対応するコネクション・ファクトリ用のログ・ファイルを指定することにより、リソース・アダプタ用のロギングを有効にできます。このためにはApplication Server Controlコンソールで次の手順を行います。

1. 適切な「リソース・アダプタ」ホームページから「コネクション・ファクトリ」タブに移動します。

2. ロギングを有効にするコネクション・ファクトリを選択します。

3. 「コネクション・ファクトリの編集」ページが表示されたら、そこから「オプション」タブに移動します。

4. ログ・ファイルの目的の絶対パスまたは相対パスおよびファイル名を指定します。

5. 変更を適用します。

表3-6に要約されるように、この設定はoc4j-ra.xmlファイルの<connector-factory>要素の<log>サブ要素に反映されます。

Application Server Controlオンライン・ヘルプのコネクション・ファクトリ・オプションの編集ページに関する状況依存トピックも参照してください。

表3-6 ログ・ファイル・プロパティ

Application Server Controlプロパティ	対応するXMLエンティティ	説明
ログ・ファイル	<log>要素の<file>サブ要素のpath属性	OC4Jがリソース・アダプタとEISに関連するロギングおよびトレース・メッセージを書き込むログ・ファイルの絶対パスまたは相対パスおよびログ・ファイルの名前を指定します。

相対パスはリソース・アダプタのデプロイ・ディレクトリへの相対位置です。「パッケージ化およびデプロイ機能」に記載のとおり次のようになります。ここでinstanceはOC4Jインスタンスの名前（Oracle Application Server環境においてはデフォルトでhomeであり、スタンドアロン環境においては常にhome）でありapp_nameはデプロイされたアプリケーションの名前（またはスタンドアロン・リソース・アダプタ用にはdefault）であり、ra_nameはデプロイされたリソース・アダプタの名前（スタンドアロン・リソース・アダプタ用には、デプロイ中に指定した名前、またEARファイル内にデプロイされたリソース・アダプタ用には.rar拡張子を取ったRARファイルの名前）です。

j2ee/instance/application-deployments/app_name/ra_name

たとえばmylog.logまたは./mylog.logを指定するとログ・ファイルの場所は次のようになります。

j2ee/instance/application-deployments/app_name/ra_name/mylog.log

mydir/mylog.logを指定すると次のようになります。

j2ee/instance/application-deployments/app_name/ra_name/mydir/mylog.log

注意: ログ・ファイル用に指定されたディレクトリが存在しない場合、またはOC4Jが指定されたディレクトリへの書込み権限を持たない場合、OC4Jはロギングすることができず、警告メッセージを出力します。 指定されたディレクトリは存在するがファイルが存在しない場合、OC4Jはファイルを作成してロギングを行います。 OC4Jによってログに書き込まれるメッセージは、リソース・アダプタのデプロイ中またはOC4Jがリソース・アダプタを起動しようとしたときに発生するエラー状態に関するものを含みます。 ログ・ファイルの場所は管理接続にも渡されます。

リソース・アダプタ接続の取得

この項では「コネクション・ファクトリの作成とバインド」において構成されたコネクション・ファクトリのJNDIルックアップを説明します。

この例もまた、ejb-jar.xmlおよびorion-ejb-jar.xmlファイル内の関連するJNDI構成によります。次は対応するサンプルのejb-jar.xmlエントリです。このファイルはアプリケーションのEARファイル内にパッケージ化されています。

<resource-ref>
   <res-ref-name>eis/myEIS</res-ref-name>
   <res-type>javax.resource.cci.ConnectionFactory</res-type>
   <res-auth>Application</res-auth>
</resource-ref>

Application Server Controlコンソールを使用してリソース参照マッピング・エントリを指定し、以前にバインドしたJNDIロケーションであるeis/ConnectionFactoryをejb-jar.xmlファイル内のJNDIの名前であるeis/myEISにリンクします。これによりorion-ejb-jar.xml内に次のようなエントリが生成されます。

<resource-ref-mapping name="eis/myEIS" location="eis/ConnectionFactory" />

リソース参照用のEJB構成の詳細は、『Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド』を参照してください。

次にコネクション・ファクトリを検索するためのサンプル・コードを示します。

try
{
 Context ic = new InitialContext();
 ConnectionFactory cf = (ConnectionFactory) ic.lookup("java:comp/env/eis/myEIS");
} catch (NamingException ex) {
 ex.printStackTrace();
}

CCIのConnectionFactoryインタフェースを実装するコネクション・ファクトリ用には、getConnection()メソッドを使用してEISへの接続を作成します。これはCCIのConnectionインタフェースを実装するコネクション・オブジェクトを返します。

Connection conn = cf.getConnection();

接続管理規約の要約

「EIS接続の取得の方法」では接続の取得の方法について簡単に説明しています。この章の前の方ではコネクション・ファクトリと接続プーリングに必要となる構成の手順を説明したので、この項では接続の取得のための接続管理規約の仕様についてさらに詳しく説明します。次のように手順を説明します。

1. アプリケーションのコンポーネントはJNDIルックアップを実行し、コネクション・ファクトリ・オブジェクトを取得します。コネクション・ファクトリはリソース・アダプタ・プロバイダによって実装されます。リソース・アダプタがCCIを実装する場合、CCIのConnectionFactoryインタフェースを実装するクラスを通して行われます。コネクション・ファクトリはOC4Jの管理者によってJNDIに登録されます。

2. アプリケーションのコンポーネントはコネクション・ファクトリのメソッドをコールしてEISへの接続をリクエストします。リソース・アダプタがCCIを実装する場合、ConnectionFactoryオブジェクトに対するgetConnection()のコールを通して行われます。さらにCCIにおいて、アプリケーションはオプションでgetConnection()コールの中で接続仕様オブジェクトを渡し、接続リクエストに固有のプロパティを渡すことができます。接続仕様はクラスのインスタンス、一般にはJavaBeanのインスタンスであり、CCIのConnectionSpecインタフェースを実装します。接続仕様のプロパティはgetterおよびsetterメソッド・パターンを通して定義される必要があります。

3. コネクション・ファクトリは接続リクエストを接続プールを保持するOC4Jに委任します。特にコネクション・ファクトリは、SPIのConnectionManagerインタフェースを実装するクラスのインスタンスである、OC4Jの接続マネージャのallocateConnection()メソッドをコールします。

4. OC4Jの接続マネージャは、SPIのManagedConnectionFactoryインタフェースを実装するリソース・アダプタの管理コネクション・ファクトリを必要に応じて使用し、接続を取得します。EISへの物理接続は管理接続と呼ばれており、SPIのManagedConnectionインタフェースを実装するクラスのインスタンスによって表されます。OC4Jは次のようにして接続を取得します。

   1. 最初に、すでに使用されている物理接続が同じトランザクションの有効範囲内で使用されており、それが（標準のejb-jar.xmlまたはweb.xmlファイルの<resource-ref>要素の<res-sharing-scope>サブ要素によって）共有不可とマークされていない場合は、新しい論理接続はその物理接続から作成されます。

   2. 最初のシナリオが実行可能でない場合、OC4Jは接続プール内で使用できる管理接続を探します。OC4Jの接続マネージャは管理コネクション・ファクトリのmatchManagedConnection()メソッドをコールします。プール内に適切なManagedConnectionオブジェクトが見つかった場合、OC4Jはそれを使用して接続リクエストに応じます。

   3. はじめの2つのシナリオのどちらも実行可能でない場合、OC4J接続マネージャは管理コネクション・ファクトリのcreateManagedConnection()メソッドをコールします。このメソッドは新しい物理接続を作成し、その物理接続を表すためにOC4Jに新しいManagedConnectionオブジェクトを返します。OC4Jはプールに新しい管理接続を設定し、それを使用して接続リクエストに応じます。

5. OC4Jは管理接続からアプリケーションレベルの接続ハンドルを取得します。そのハンドルはリソース・アダプタによって実装されるクラスのインスタンスです。リソース・アダプタがCCIインタフェースを実装する場合、このクラスはCCIのConnectionインタフェースを実装します。

6. OC4Jはアプリケーションに接続ハンドルを返します。

7. アプリケーションのコンポーネントはEISにアクセスするために接続ハンドルを使用します。（その後、終了したときに接続を閉じます。）

さらに、OC4Jは、SPIのConnectionEventListenerインタフェースを実装するクラスのインスタンスである接続イベント・リスナーを物理接続用のManagedConnectionインスタンスに登録します。OC4Jは管理接続のaddConnectionEventListener()メソッドをコールしてこれを行います。この目的は、接続プールの管理において利点となるように、管理接続に関連するイベントのOC4Jへの通知を可能にすることです。

リソース・アダプタ接続のメトリック

OC4Jは、Java 2 Platform, Enterprise Edition Management Specification（JSR-77）に規定されている業界標準のメトリックだけでなくOracle Dynamic Monitoring Service（DMS）に基づいた、リソース・アダプタ・コネクション・ファクトリおよび接続プール用のパフォーマンス・メトリックを提供しています。続く項において、これらのメトリックとそれにアクセスする方法について説明します。

• リソース・アダプタ接続プール・メトリックの表示

• 接続プール構成メトリックの説明

• コネクション・ファクトリ・パフォーマンス・メトリックの説明

• 接続プール・パフォーマンス・メトリックの説明

• リソース・アダプタ接続プール・メトリックのトラブルシューティング

OC4Jパフォーマンス・メトリックの詳細は、Application Server Controlオンライン・ヘルプのOC4Jのパフォーマンス・メトリックのサマリーに関するトピックを参照してください。

注意: DMSはOC4Jを含む多くのOracle Application Serverコンポーネントにパフォーマンス監視機能を追加しました。DMSの目的は、ユーザーがどのようなパフォーマンスに関する問題でも診断、分析およびデバッグできるように、組込みパフォーマンス測定を通して実行時の動作の情報を提供することです。DMSはこの情報を、ライブ・デプロイ中を含むどんなときでも使用できるパッケージの中に提供しています。データはHTTPを通して発行されブラウザによって表示されます。DMSの使用方法、利用できる組込みDMSメトリック、および他のOC4Jのパフォーマンスの検討事項の概要は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。

リソース・アダプタ接続プール・メトリックの表示

Application Server Controlコンソールで次の手順を行うことによって、リソース・アダプタ・コネクション・ファクトリおよびプール用のメトリックを表示できます。

1. 適切な「リソース・アダプタ」ホームページから「コネクション・ファクトリ」タブに移動します。

2. 該当するコネクション・ファクトリに対応する適切なJNDIロケーションについて、モニター機能を選択します。

3. 表示された「コネクション・ファクトリ・メトリック」ページは待機時間、使用時間、接続取得数/秒および接続解放数/秒などの統計を示します。

「一般」の下には1つのJNDIロケーションと対応する、選択した特定のコネクション・ファクトリ用のメトリックが一覧表示されます。「接続プール」の下には接続プール全体用のメトリックが一覧表示されます。これらは1つのJNDIロケーションに対応する1つのコネクション・ファクトリに使用されるプライベートか、複数のJNDIロケーションに対応する複数のコネクション・ファクトリに使用される共有かのどちらかです。

次のメトリックは「一般」カテゴリの下にあります。詳細は、「コネクション・ファクトリ・パフォーマンス・メトリックの説明」を参照してください。

• 接続待機時間（秒）

• 接続使用時間（秒）

• 接続取得数/秒

• 接続解放数/秒

次のメトリックは「接続プール」カテゴリの下にあります。詳細は、「接続プール・パフォーマンス・メトリックの説明」を参照してください。

• プール・タイプ（プライベートまたは共有）

• プール名

• 接続待機時間（秒）

• 接続使用時間（秒）

• 接続作成率/秒

• 接続終了率/秒

• 使用中の接続

• 使用可能な接続

• 待機スレッド

• 接続エラー数/秒

詳細はApplication Server Controlオンライン・ヘルプの「コネクション・ファクトリ・メトリック」ページに関する状況依存トピックも参照してください。

接続プール構成メトリックの説明

表3-7に一覧表示するように、「OC4Jにおける接続プーリングの構成」で説明されている接続プール構成パラメータに対応するDMSメトリックがあります。表のXMLエンティティは、oc4j-ra.xmlファイル内の適用可能な<connection-pooling>要素のサブ要素について言及しています。

表3-7 OC4Jの接続プール構成メトリック

DMSメトリック名（およびセンサー・タイプ）	Application Server Controlプロパティ	対応するXMLエンティティ
maxPoolSize (State)	最大接続数	name="maxConnections"を持つ<property>
minPoolSize (State)	最小接続数	name="minConnections"を持つ<property>
scheme (State)	接続プーリング・スキーム	name="scheme"を持つ<property>
waitTimeout (State)	固定待機タイムアウト	name="waitTimeout"を持つ<property>
inactivityTimeout (State)	非アクティブ接続タイムアウト	name="inactivity-timeout"を持つ<property>
inactivityTimeoutCheck (State)	期限切れ接続のクリーンアップ	name="inactivity-timeout-check"を持つ<property>

コネクション・ファクトリ・パフォーマンス・メトリックの説明

表3-8はコネクション・ファクトリ用のOC4JのDMSメトリックをリストして説明し、Application Server Controlの「コネクション・ファクトリ・メトリック」ページ（「一般」の下）およびJ2EE Management Specificationの中の対応するメトリックを記載しています。コネクション・ファクトリは1つのJNDIロケーションに対応します。

これらの統計は、接続プーリングが使用されるかどうかにかかわらず重要です。

表3-8 OC4Jのコネクション・ファクトリ・パフォーマンス・メトリック

DMSメトリック名（およびセンサー・タイプ）	Application Server Controlメトリック	J2EE Management Specification/JSR-77 Statistics（およびタイプ）	説明
waitTime (PhaseEvent)	接続待機時間	JCAConnectionStats.getWaitTime() (TimeStatistics)	このコネクション・ファクトリからの接続を待つ平均の秒数です。
useTime (PhaseEvent)	接続使用時間	JCAConnectionStats.getUseTime() (TimeStatistics)	接続を使用する平均の秒数です。
createCount (Event)	接続取得数/秒	JCAConnectionStats.getCreateCount() (CountStatistics)	取得した接続ハンドルの数です（Application Server Controlでは1秒当たりの値で表されます）。
closeCount (Event)	接続解放数/秒	JCAConnectionStats.getCloseCount() (CountStatistics)	解放した接続ハンドルの数です（Application Server Controlでは1秒当たりの値で表されます）。

注意: 接続プールを使用しない場合、接続を取得することは接続を作成することと同じで、接続を解放することは接続を閉じることと同じです。接続プールを使用する場合、1つの接続ハンドルが作成と閉包との間で複数回取得されたり開放されたりする場合があります。

接続プール・パフォーマンス・メトリックの説明

表3-9は接続プール用のOC4JのDMSメトリックをリストして説明し、Application Server Controlの「コネクション・ファクトリ・メトリック」ページ（「接続プール」の下）およびJ2EE Management Specificationの中の対応するメトリックを記載しています。接続プールがプライベートである場合は、1つのコネクション・ファクトリおよびJNDIロケーションに対応し、共有である場合は、複数のコネクション・ファクトリおよびJNDIロケーションに対応します。

これらの統計は、接続プーリングが使用される場合にのみ重要です。

表3-9 OC4Jの接続プール・パフォーマンス・メトリック

DMSメトリック名（およびセンサー・タイプ）	Application Server Controlメトリック	J2EE Management Specification/JSR-77 Statistics（およびタイプ）	説明
poolName (State)	プール名	n/a	接続プールの名前です。
waitTime (PhaseEvent)	接続待機時間	JCAConnectionPoolStats.getWaitTime() (TimeStatistics)	この接続プールからの接続を待つ平均の秒数です。共有プールでは、これはプール内のすべてのコネクション・ファクトリ用です。
useTime (PhaseEvent)	接続使用時間	JCAConnectionPoolStats.getUseTime() (TimeStatistics)	接続を使用する平均の秒数です。共有プールでは、これはプール内のすべてのコネクション・ファクトリ用です。
createCount (Event)	接続作成率/秒	JCAConnectionPoolStats.getCreateCount() (CountStatistics)	作成した接続ハンドルの数です（Application Server Controlでは1秒当たりの値で表されます）。共有プールでは、これはプール内のすべてのコネクション・ファクトリ用です。
closeCount (Event)	接続終了率/秒	JCAConnectionPoolStats.getCloseCount() (CountStatistics)	閉じた接続ハンドルの数です（Application Server Controlでは1秒当たりの値で表されます）。共有プールでは、これはプール内のすべてのコネクション・ファクトリ用です。
freePoolSize (State)	使用可能な接続	JCAConnectionPoolStats.getFreePoolSize() (BoundedRangeStatistics)	プール内の使用できる接続の数です。
poolSize (State)	該当なし、ただし使用中の接続プラス使用可能な接続と同等	JCAConnectionPoolStats.getPoolSize() (BoundedRangeStatistics)	接続プールのサイズ、すなわち空いている接続の数プラス使用中の接続の数です。
waitingThreadCount (PhaseEvent)	待機スレッド	JCAConnectionPoolStats.getWaitingThreadCount() (BoundedRangeStatistics)	接続を待っているスレッドの数です。
expiredCount (Event)	n/a	n/a	プールから削除される期限切れ接続の数です。
invalidCount (Event)	n/a	n/a	リソース・アダプタによって無効と決定される接続の数です。
requestTimeoutCount (Event)	n/a	n/a	タイムアウトのため失敗した接続リクエストの数です。
errorCount (Event)	接続エラー数/秒	n/a	接続エラー・イベントの数です（Application Server Controlでは1秒当たりの値で表されます）。

リソース・アダプタ接続プール・メトリックのトラブルシューティング

前の項で説明したOC4Jの接続メトリックは、使用しているリソース・アダプタおよびアプリケーション・サーバー環境の傾向を知るためのものです。これらのメトリックには望ましい値の範囲は特にありません。経験とともに、使用している環境においてどの範囲が正常で、どの範囲が問題を示唆しているかが解るようになります。

一般に、待機時間、待機スレッドの数、および接続エラー数/秒には特別の注意を払う必要があります。

注意: 接続のトラブルシューティング用の追加ツールにはOC4Jのシステム・プロパティであるjca.connection.debugがあり、J2CA接続の診断情報を出力するために使用できます。OC4Jのシステム・プロパティの概要は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。