第15章 Java Connector Architecture (JCA) の管理

15.1. Java Connector Architecture (JCA)

Java EE Connector Architecture (JCA) は外部にある異種のエンタープライズ情報システム (EIS) に対して Java EE システムの標準アーキテクチャーを定義します。EIS の例として、 エンタープライズリソースプランニング (ERP) システム、メインフレームトランザクション処理 (TP)、データベース、メッセージングシステムなどが挙げられます。リソースアダプターは Java EE Connector API アーキテクチャーを実装するコンポーネントです。

データソースオブジェクトと似ていますが、JCA 1.7 は以下を管理する機能を提供します。

  • connections
  • transactions
  • security
  • life-cycle
  • work instances
  • transaction inflow
  • message inflow

JCA 1.7 は Java Community Process で JSR-322 として開発されました。

15.2. リソースアダプター

リソースアダプターは、 Java Connector Architecture (JCA) 仕様を使用して Java EE アプリケーションとエンタープライズ情報システム (EIS) との間の通信を提供するデプロイ可能な Java EE コンポーネントです。EIS ベンダーの製品と Java EE アプリケーションの統合を容易にするため、リソースアダプターは通常 EIS ベンダーによって提供されます。

エンタープライズ情報システムは、組織内における他のあらゆるソフトウェアシステムのことです。例としては、エンタープライズリソースプランニング (ERP) システム、データベースシステム、電子メールサーバー、商用メッセージングシステムなどが挙げられます。

リソースアダプターは、JBoss EAP にデプロイできる Resource Adapter Archive (RAR) ファイルでパッケージ化されます。また、RAR ファイルは、Enterprise Archive (EAR) デプロイメントにも含めることができます。

リソースアダプター自体は、IronJacamar プロジェクトによって提供される resource-adapters サブシステム内に定義されます。

15.3. JCA サブシステムの設定

jca サブシステムは、JCA コンテナーおよびリソースアダプターデプロイメントの一般的な設定を制御します。管理コンソールまたは管理 CLI を使用して jca サブシステムを設定できます。

設定する主な JCA 要素は次のとおりです。

管理コンソールでの JCA の設定

管理コンソールで jca サブシステムを設定するには、ConfigurationSubsystemsJCA と選択し、適切なタブを選択します。

  • Common Config タブ - キャッシュ接続マネージャー、アーカイブバリデーション、および Bean バリデーションの設定が含まれます。これらの項目は独自のタブに含まれます。設定を変更するには、タブを開き、Edit ボタンをクリックします。
  • Bootstrap Contexts タブ - 設定されたブートストラップコンテキストのリストが含まれます。新しいブートストラップコンテキストオブジェクトを追加、削除、および設定できます。各ブートストラップコンテキストをワークマネージャーに割り当てる必要があります。
  • Work Managerタブ - 設定されたワークマネージャーのリストが含まれます。新しいワークマネージャーを追加および削除でき、スレッドプールをここで設定できます。各ワークマネージャーは短時間実行されるスレッドプールを 1 つ持つことができ、任意で長時間実行されるスレッドプールを 1 つ持つことができます。

    スレッドプール属性を設定するには、選択したワークマネージャーの View をクリックします。

管理 CLI での JCA の設定
/subsystem=jca アドレスから管理 CLI で jca サブシステムを設定できます。管理対象ドメインでは、コマンドの前に /profile=PROFILE_NAME を追加する必要があります。
注記

以下のセクションの表には、管理モデルで使用される属性名を示しています (管理 CLI を使用している場合など)。XML で使用される名前は管理モデルの名前と異なる場合があるため、XML で使用される要素を EAP_HOME/docs/schema/wildfly-jca_5_0.xsd のスキーマ定義ファイルで確認してください。

アーカイブバリデーション

デプロイメントユニットでアーカイブバリデーションを実行するかどうかを決定します。以下の表はアーカイブバリデーションに設定できる属性を表しています。

表15.1 アーカイブバリデーション属性

属性デフォルト値説明

enabled

true

アーカイブバリデーションが有効であるかどうかを指定します。

fail-on-error

true

アーカイブバリデーションのエラーレポートによってデプロイメントが失敗するかどうかを指定します

fail-on-warn

false

アーカイブバリデーションの警告レポートによってデプロイメントが失敗するかどうかを指定します。

アーカイブバリデーションが有効な状態で、アーカイブが JCA 仕様を正しく実装しない場合、デプロイメント中に問題を説明するエラーメッセージが表示されます。例は次のとおりです。

Severity: ERROR
Section: 19.4.2
Description: A ResourceAdapter must implement a "public int hashCode()" method.
Code: com.mycompany.myproject.ResourceAdapterImpl

Severity: ERROR
Section: 19.4.2
Description: A ResourceAdapter must implement a "public boolean equals(Object)" method.
Code: com.mycompany.myproject.ResourceAdapterImpl

アーカイブバリデーションが指定されていない場合は、アーカイブバリデーションが指定されているとみなされ、enabled 属性のデフォルトが true に設定されます。

Bean バリデーション

この設定は、JSR-303 で定義されている Bean バリデーションがデプロイメントユニットで実行されるかどうかを決定します。以下の表は Bean バリデーションに設定できる属性について表しています。

表15.2 Bean バリデーションの属性

属性デフォルト値説明

enabled

true

Bean バリデーションが有効であるかどうかを指定します。

Bean バリデーションが指定されていない場合は、Bean バリデーションが指定されているとみなされ、enabled 属性のデフォルトが true に設定されます。

ワークマネージャー

ワークマネージャーには次の 2 種類があります。

デフォルトワークマネージャー
デフォルトのワークマネージャーおよびそのスレッドプール。
カスタムワークマネージャー
カスタムワークマネージャーの定義およびそのスレッドプール。

ワークマネージャーに設定できる属性は下表のとおりです。

表15.3 ワークマネージャーの属性

属性説明

name

ワークマネージャーの名前を指定します。

elytron-enabled

この属性は、workmanager の Elytron セキュリティーを有効にします。

ワークマネージャーには以下の子要素もあります。

表15.4 ワークマネージャーの子要素

子要素説明

short-running-threads

標準の Work インスタンスのスレッドプール。ワークマネージャーごとに短時間実行されるスレッドプールが 1 つあります。

long-running-threads

LONG_RUNNING ヒントを設定する JCA 1.7 Work インスタンスのスレッドプール。各ワークマネージャーはオプションの長期スレッドプールを 1 つ持てます。

ワークマネージャーのスレッドプールに設定できる属性は下表のとおりです。

表15.5 スレッドプールの属性

属性説明

allow-core-timeout

コアスレッドがタイムアウトするかどうかを決定するブール値の設定。デフォルト値は false です。

core-threads

コアスレッドプールのサイズ。スレッドプールの最大サイズ以下である必要があります。

handoff-executor

タスクが受け入れられない場合、タスクを委譲するエグゼキューター。指定されていない場合、受け入れられないタスクは警告なしに破棄されます。

keepalive-time

ワーク実行後にスレッドプールが保持される期間を指定します。

max-threads

スレッドプールの最大サイズ。

name

スレッドプールの名前を指定します。

queue-length

キューの最大長。

thread-factory

スレッドファクトリーへの参照。

分散ワークマネージャー

分散ワークマネージャーは、別のワークマネージャーインスタンスでワークの実行スケジュールを変更できるワークマネージャーです。

以下の管理 CLI コマンドの例は、分散ワークマネージャーを設定します。スタンドアロンサーバーの standalone-ha.xml または standalone-full-ha.xml 設定ファイルなど、高可用性を提供する設定を使用する必要があることに注意してください。

例: 分散ワークマネージャーの設定

batch
/subsystem=jca/distributed-workmanager=myDistWorkMgr:add(name=myDistWorkMgr)
/subsystem=jca/distributed-workmanager=myDistWorkMgr/short-running-threads=myDistWorkMgr:add(queue-length=10,max-threads=10)
/subsystem=jca/bootstrap-context=myCustomContext:add(name=myCustomContext,workmanager=myDistWorkMgr)
run-batch

注記

short-running-threads 要素の名前は distributed-workmanager 要素の名前と同じである必要があります。

以下の表は、分散ワークマネージャーに設定できる属性を表しています。

表15.6 分散ワークマネージャーの属性

属性説明

elytron-enabled

ワークマネージャーの Elytron セキュリティーを有効にします。

name

分散ワークマネージャーの名前。

policy

ワークインスタンスをいつ再分散するかを決定します。使用できる値は次のとおりです。

  • NEVER - ワークインスタンスを別のノードに分散しません。
  • ALWAYS - 常にワークインスタンスを別のノードに分散します。
  • WATERMARK - 現在のノードで使用できる空きのワーカースレッドの数に応じてワーカーインスタンスを別のノードに分散します。

policy-options

ポリシーのキーバリューペアのオプションリスト。WATERMARK ポリシーを使用する場合、watermark ポリシーオプションを使用して、ワークが分散される空きスレッドの数を指定します。例を以下に示します。

/subsystem=jca/distributed-workmanager=myDistWorkMgr:write-attribute(name=policy-options,value={watermark=3})

selector

ワークインスタンスを再分散するネットワークのノードを決定します。使用できる値は次のとおりです。

  • FIRST_AVAILABLE - リストの最初に利用できるノードを選択します。
  • PING_TIME - ping の時間が最も短いノードを選択します。
  • MAX_FREE_THREADS - 空きワーカースレッドの数が最も多いノードを選択します。

selector-options

セレクターのキーバリューペアのオプションリスト。

分散ワークマネージャーには以下の子要素もあります。

表15.7 分散ワークマネージャーの子要素

子要素説明

long-running-threads

LONG_RUNNING ヒントを設定するワークインスタンスのスレッドプール。各分散ワークマネージャーはオプションで長時間実行スレッドプールを持つことができます。

short-running-threads

標準ワークインスタンスのスレッドプール。各分散ワークマネージャーには短期間実行スレッドプールがある必要があります。

ブートストラップコンテキスト

カスタムのブートストラップコンテキストを定義するために使用されます。以下の表は、ブートストラップコンテキストに設定できる属性を表しています。

表15.8 ブートストラップコンテキストの属性

属性説明

name

ブートストラップコンテキストの名前を指定します。

workmanager

このコンテキストに使用するワークマネージャーの名前を指定します。

キャッシュ接続マネージャー

トランザクションの接続における接続のデバッグおよび Lazy Enlistment のサポートに使用され、アプリケーションによって使用およびリリースされるかどうかを追跡します。以下の表はキャッシュ接続マネージャーに設定できる属性を表しています。

表15.9 キャッシュ接続マネージャーの属性

属性デフォルト値説明

debug

false

接続を明示的に閉じるため、障害時に警告を出力します。

error

false

接続を明示的に閉じるため、障害時に例外が発生します。

ignore-unknown-connections

false

未知の接続はキャッシュされないことを指定します。

install

false

キャッシュされた接続マネージャーバルブおよびインターセプターを有効または無効にします。

15.4. リソースアダプターの設定

15.4.1. リソースアダプターのデプロイ

リソースアダプターは管理 CLI または管理コンソールを使用して他のデプロイメントと同様にデプロイできます。また、スタンドアロンサーバー実行時にアーカイブをデプロイメントディレクトリーにコピーして、デプロイメントスキャナーによって検出されるようにすることもできます。

管理 CLI を使用したリソースアダプターのデプロイ

リソースアダプターをスタンドアロンサーバーへデプロイするには、以下の管理 CLI コマンドを実行します。

deploy /path/to/resource-adapter.rar

リソースアダプターを管理対象ドメインのすべてのサーバーグループにデプロイするには、以下の管理 CLI コマンド を入力します。

deploy /path/to/resource-adapter.rar --all-server-groups
管理コンソールを使用したリソースアダプターのデプロイ
  1. 管理コンソールにログインし、Deployments タブをクリックします。
  2. 追加 をクリックします。管理対象ドメインの場合は、最初に Content Repository を選択する必要があります。
  3. 新規デプロイメントのアップロードオプションを選択し、次へ をクリックします。
  4. リソースアダプターアーカイブを閲覧し、次へ をクリックします。
  5. アップロードを確認してから 完了をクリックします。
  6. 管理対象ドメインでは、デプロイメントを適切なサーバーグループに割り当て、デプロイメントを有効にします。
デプロイメントスキャナーを使用したリソースアダプターのデプロイ

リソースアダプターを手作業でスタンドアロンサーバーにデプロイするには、リソースアダプターアーカイブをサーバーデプロイメントディレクトリー (例: EAP_HOME/standalone/deployments/) にコピーします。これにより、デプロイメントスキャナーによって検出され、デプロイされます。

注記

このオプションは管理対象ドメインでは使用できません。管理コンソールまたは管理 CLI を使用してリソースアダプターをサーバーグループにデプロイする必要があります。

15.4.2. リソースアダプターの設定

管理インターフェースを使用してリソースアダプターを設定できます。以下の例は、管理 CLI を使用してリソースアダプターを設定する方法を示しています。サポートされるプロパティーやその他の重要な情報は、リソースアダプターベンダーのマニュアルを参照してください。

リソースアダプター設定の追加

リソースアダプター設定を追加します。

/subsystem=resource-adapters/resource-adapter=eis.rar:add(archive=eis.rar, transaction-support=XATransaction)
リソースアダプターの設定

必要に応じて以下を設定します。

  • config-properties を設定します。

    server 設定プロパティーを追加します。

    /subsystem=resource-adapters/resource-adapter=eis.rar/config-properties=server:add(value=localhost)

    port 設定プロパティーを追加します。

    /subsystem=resource-adapters/resource-adapter=eis.rar/config-properties=port:add(value=9000)
  • admin-objects を設定します。

    管理オブジェクトを追加します。

    /subsystem=resource-adapters/resource-adapter=eis.rar/admin-objects=aoName:add(class-name=com.acme.eis.ra.EISAdminObjectImpl, jndi-name=java:/eis/AcmeAdminObject)

    管理オブジェクト設定プロパティーを設定します。

    /subsystem=resource-adapters/resource-adapter=eis.rar/admin-objects=aoName/config-properties=threshold:add(value=10)
  • connection-definitions を設定します。

    管理接続ファクトリーの接続定義を追加します。

    /subsystem=resource-adapters/resource-adapter=eis.rar/connection-definitions=cfName:add(class-name=com.acme.eis.ra.EISManagedConnectionFactory, jndi-name=java:/eis/AcmeConnectionFactory)

    管理接続ファクトリーの設定プロパティーを設定します。

    /subsystem=resource-adapters/resource-adapter=eis.rar/connection-definitions=cfName/config-properties=name:add(value=Acme Inc)

    エンリストメントトレースを記録するかどうかを設定します。エンリストメントトレースの記録を有効にするには、enlistment-trace 属性を true に設定します。

    /subsystem=resource-adapters/resource-adapter=eis.rar/connection-definitions=cfName:write-attribute(name=enlistment-trace,value=true)
    警告

    エンリストメントトレースを有効にすると、トランザクションエンリストメント中のエラーを容易に追跡できますが、パフォーマンスに影響します。

リソースアダプターの利用可能なすべてのオプションについては、「リソースアダプターの属性」を参照してください。

リソースアダプターのアクティベート

リソースアダプターをアクティベートします。

/subsystem=resource-adapters/resource-adapter=eis.rar:activate
注記

リソースアダプターのキャパシティーポリシーを定義することも可能です。詳細は「キャパシティーポリシー」の項を参照してください。

15.4.3. Elytron サブシステムを使用するようリソースアダプターを設定

IronJacamar では、サーバーとリソースアダプターの間で 2 種類の通信が発生します。

その通信の 1 つは、サーバーがリソースアダプター接続を開いた場合に発生します。仕様によって定義されたとおり、コンテナ管理のサインオンでセキュアにすることができます。これには、接続を開いたときにプリンシパルとクレデンシャルで JAAS サブジェクトをリソースアダプターへ伝搬する必要があります。

IronJacamar はセキュリティーインフローをサポートします。このメカニズムは、ワークをワークマネージャーに提出するときや、同じ JBoss EAP インスタンスにあるエンドポイントにメッセージを配信するときに、リソースアダプターがセキュリティー情報を確立できるようにします。

コンテナ管理のサインオン

Elytron でコンテナ管理のサインオンを実現するには、elytron-enabled 属性を true に設定する必要があります。これにより、リソースアダプターへのすべての接続が Elytron によってセキュア化されます。

/subsystem=resource-adapters/resource-adapter=RAR_NAME/connection-definitions=FACTORY_NAME:write-attribute(name=elytron-enabled,value=true)

resource-adapters サブシステムの elytron-enabled 属性を true に設定すると、管理 CLI を使用して elytron-enabled 属性を設定できます。デフォルトではこの属性は false に設定されています。

authentication-context 属性は、サインオンの実行に使用される Elytron 認証コンテキストの名前を定義します。

Elytron の authentication-context 属性には 1 つ以上の authentication-configuration 要素を含めることができ、使用を希望するクレデンシャルが含まれます。

authentication-context 属性が設定されていない場合、JBoss EAP は現在の authentication-context を使用します。これは、接続を開く呼び出し元コードによって使用される authentication-context です。

例: authentication-configuration の作成

/subsystem=elytron/authentication-configuration=exampleAuthConfig:add(authentication-name=sa,credential-reference={clear-text=sa})

例: 上記設定を使用した authentication-context の作成

/subsystem=elytron/authentication-context=exampleAuthContext:add(match-rules=[{authentication-configuration=exampleAuthConfig}])

セキュリティーインフロー

また、ワークマネージャーによって実行される予定のワークを提出するときに、リソースマネージャーはセキュリティークレデンシャルを流入 (インフロー) することもできます。セキュリティーインフローは、実行前にワークがワーク自体を認証できるようにします。認証に成功すると、提出されたワークは結果となる認証コンテキスト下で実行されます。認証に失敗すると、ワークの実行は拒否されます。

Elytron セキュリティーインフローを有効にするには、リソースアダプターのワークマネージャーを設定するときに wm-elytron-security-domain 属性を設定します。Elytron は指定のドメインを元に認証を実行します。

注記

リソースアダプターのワークマネージャーが Elytron セキュリティードメイン wm-elytron-security-domain を使用するよう設定された場合、参照されたワークマネージャーの elytron-enabled 属性を true に設定する必要があります。

/subsystem=jca/workmanager=customWM:add(name=customWM, elytron-enabled=true)
注記

wm-elytron-security-domain の代わりに wm-security-domain 属性が使用された場合、セキュリティーインフローはレガシーの security サブシステムによって実行されます。

以下の jca サブシステムの設定例では、ra-with-elytron-security-domain というリソースアダプターの設定を確認できます。このリソースアダプターは、Elytron セキュリティードメインの wm-realm を使用するようワークマネージャーセキュリティーを設定します。

<subsystem xmlns="urn:jboss:domain:jca:5.0">
    <archive-validation enabled="true" fail-on-error="true" fail-on-warn="false"/>
    <bean-validation enabled="true"/>
    <default-workmanager>
        <short-running-threads>
            <core-threads count="50"/>
            <queue-length count="50"/>
            <max-threads count="50"/>
            <keepalive-time time="10" unit="seconds"/>
        </short-running-threads>
        <long-running-threads>
            <core-threads count="50"/>
            <queue-length count="50"/>
            <max-threads count="50"/>
            <keepalive-time time="10" unit="seconds"/>
        </long-running-threads>
    </default-workmanager>
    <workmanager name="customWM">
        <elytron-enabled>true</elytron-enabled>
        <short-running-threads>
            <core-threads count="20"/>
            <queue-length count="20"/>
            <max-threads count="20"/>
        </short-running-threads>
    </workmanager>
    <bootstrap-contexts>
        <bootstrap-context name="customContext" workmanager="customWM"/>
    </bootstrap-contexts>
    <cached-connection-manager/>
</subsystem>

その後、ワークマネージャーは resource-adapter サブシステムからブートストラップコンテキストを使用して参照されます。

<subsystem xmlns="urn:jboss:domain:resource-adapters:5.0">
    <resource-adapters>
        <resource-adapter id="ra-with-elytron-security-domain">
            <archive>
                ra-with-elytron-security-domain.rar
            </archive>
            <bootstrap-context>customContext</bootstrap-context>
            <transaction-support>NoTransaction</transaction-support>
            <workmanager>
                <security>
                    <elytron-security-domain>wm-realm</elytron-security-domain>
                    <default-principal>wm-default-principal</default-principal>
                    <default-groups>
                        <group>
                            wm-default-group
                        </group>
                    </default-groups>
                </security>
            </workmanager>
        </resource-adapter>
    </resource-adapters>
</subsystem>

例: セキュリティードメインの設定

/subsystem=elytron/properties-realm=wm-properties-realm:add(users-properties={path=/security-dir/users.properties, plain-text=true}, groups-properties={path=/security-dir/groups.properties})

/subsystem=elytron/simple-role-decoder=wm-role-decoder:add(attribute=groups)

/subsystem=elytron/constant-permission-mapper=wm-permission-mapper:add(permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}])

/subsystem=elytron/security-domain=wm-realm:add(default-realm=wm-properties-realm, permission-mapper=wm-permission-mapper, realms=[{role-decoder=wm-role-decoder, realm=wm-properties-realm}])

Work クラスは、指定のドメイン下で Elytron の認証のクレデンシャルを提供する役割があります。これには javax.resource.spi.work.WorkContextProvider を実装する必要があります。

public interface WorkContextProvider {
   /**
    * Gets an instance of <code>WorkContexts</code> that needs to be used
    * by the <code>WorkManager</code> to set up the execution context while
    * executing a <code>Work</code> instance.
    *
    * @return an <code>List</code> of <code>WorkContext</code> instances.
    */
   List<WorkContext> getWorkContexts();
}

このインターフェースは、Work クラスが WorkContext を使用して、ワークが実行されるコンテキストの一部の機能を設定できるようにします。その機能の 1 つがセキュリティーインフローで、List<WorkContext> getWorkContexts メソッドは javax.resource.spi.work.SecurityContext を提供する必要があります。このコンテキストは、JSR-196 仕様 の定義どおりに javax.security.auth.callback.Callback オブジェクトを使用してクレデンシャルを提供します。

例: コンテキストを使用したコールバックの作成

public class ExampleWork implements Work, WorkContextProvider {

    private final String username;
    private final String role;

    public MyWork(TestBean bean, String username, String role) {
        this.principals = null;
        this.roles = null;
        this.bean = bean;
        this.username = username;
        this.role = role;
    }

    public List<WorkContext> getWorkContexts() {
        List<WorkContext> l = new ArrayList<>(1);
        l.add(new MySecurityContext(username, role));
        return l;
    }

    public void run() {
        ...
    }

    public void release() {
        ...
    }

    public class ExampleSecurityContext extends SecurityContext {

        public void setupSecurityContext(CallbackHandler handler, Subject executionSubject, Subject serviceSubject) {
            try {
                List<javax.security.auth.callback.Callback> cbs = new ArrayList<>();
                cbs.add(new CallerPrincipalCallback(executionSubject, new SimplePrincipal(username)));
                cbs.add(new GroupPrincipalCallback(executionSubject, new String[]{role}));
                handler.handle(cbs.toArray(new javax.security.auth.callback.Callback[cbs.size()]));
            } catch (Throwable t) {
                throw new RuntimeException(t);
            }
        }
    }

上記の例では、ExampleWorkWorkContextProvider インターフェースを実装し、ExampleSecurityContext を提供します。そのコンテキストは、ワークの実行時に Elytron によって認証されるセキュリティー情報の提供に必要なコールバックを作成します。

15.4.4. WebSphere MQ リソースアダプターのデプロイおよび設定

JBoss EAP の『Configuring Messaging』には、Websphere MQ リソースアダプターのデプロイメント の手順が記載されています。

15.4.5. 汎用 JMS リソースアダプターのデプロイおよび設定

JBoss EAP の『Configuring Messaging』には、汎用 JMS リソースアダプターの設定 の手順が記載されています。

15.5. 管理接続プールの設定

JBoss EAP は ManagedConnectionPool インターフェースの 3 つの実装を提供します。

org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedQueueManagedConnectionPool
これは、JBoss EAP 7 のデフォルトの接続プールで、追加設定がない場合のパフォーマンスが最も優れています。
org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool
過去の JBoss EAP バージョンではデフォルトの接続プールでした。
org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool
この接続プールはデバッグの目的でのみ使用され、シャットダウンやプールのフラッシュ時にリークが報告されます。

以下の管理 CLI コマンドを使用して、データソースの管理接続プール実装を設定できます。

/subsystem=datasources/data-source=DATA_SOURCE:write-attribute(name=mcp,value=MCP_CLASS)

以下の管理 CLI コマンドを使用して、リソースアダプターの管理接続プール実装を設定できます。

/subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:write-attribute(name=mcp,value=MCP_CLASS)

以下の管理 CLI コマンドを使用して、メッセージングサーバーの管理接続プール実装を設定できます。

/subsystem=messaging-activemq/server=SERVER/pooled-connection-factory=CONNECTION_FACTORY:write-attribute(name=managed-connection-pool,value=MCP_CLASS)

15.6. 接続統計の表示

/deployment=NAME.rar サブツリーから定義された接続の統計を読み取りできます。これは、standalone.xml または domain.xml 設定に定義されていなくても、すべての RAR の統計にアクセスできるようにするためです。

/deployment=NAME.rar/subsystem=resource-adapters/statistics=statistics/connection-definitions=java\:\/testMe:read-resource(include-runtime=true)
注記

統計はすべてランタイムのみの情報であるため、必ず include-runtime=true 引数を指定してください。

利用できる統計については、「リソースアダプターの統計」を参照してください。

15.7. リソースアダプター接続のフラッシュ

以下の管理 CLI コマンドを使用して、リソースアダプターの接続をフラッシュします。

注記

管理対象ドメインでは、コマンドの前に /host=HOST_NAME/server=SERVER_NAME を追加する必要があります。

  • プールの接続をすべてフラッシュします。

    /subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-all-connection-in-pool
  • プールの接続をすべて正常にフラッシュします。

    /subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-gracefully-connection-in-pool

    サーバーは、接続がアイドル状態なるまで待ってから接続をフラッシュします。

  • プールのアイドル状態の接続をすべてフラッシュします。

    /subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-idle-connection-in-pool
  • プールの無効な接続をすべてフラッシュします。

    /subsystem=resource-adapters/resource-adapter=RESOURCE_ADAPTER/connection-definitions=CONNECTION_DEFINITION:flush-invalid-connection-in-pool

    サーバーは無効であると判断したすべての接続をフラッシュします。

15.8. Resource Adapters サブシステムの調整

resource-adapters サブシステムのパフォーマンスを監視および最適化するための情報は、『Performance Tuning Guide』の「Datasource and Resource Adapter Tuning」の項を参照してください。