| Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の管理 12c (12.2.1) E69984-01 |
|
 前 |
 次 |
この章では、Concurrency Utilities for Java EE 1.0 (JSR 236)の定義および実装をサポートする目的でWebLogic Serverが実装する同時管理対象オブジェクト(CMO)について説明します。
この章の内容は次のとおりです。
Concurrency Utilities for Java EE 1.0 (JSR 236)は、サーブレットやEJBなどのJava EEアプリケーション・コンポーネントに非同期実行機能を提供する標準APIを実装しています。
Java EE 7のチュートリアルで説明するように、同時実行の2つの主要概念はプロセスとスレッドになります。
プロセスは、主にオペレーティング・システム(OS)で実行するアプリケーションに関連付けられます。プロセスには、JVMプロセスと同様に、基本のOSと連携して他のリソース(独自のメモリーなど)を割り当てる固有のランタイム・リソースがあります。JVMは、実際はプロセスになります。
スレッドは一部の機能をプロセスと共有します。これは、どちらもOSまたは実行環境のリソースを消費するためです。ただし、スレッドの方がプロセスよりも作成しやすく、消費するリソースはかなり少なくなります。
同時実行性ユーティリティのプライマリ・コンポーネントは次のとおりです。
ManagedExecutorService (MES): 発行されたタスクを非同期的に実行するためにアプリケーションによって使用されます。タスクは、コンテナによって開始および管理されるスレッドで実行されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。
ManagedScheduledExecutorService (MSES): 発行されたタスクを特定の時点で非同期的に実行するためにアプリケーションによって使用されます。タスクは、コンテナによって開始および管理されるスレッドで実行されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。
ManagedThreadFactory (MTF): 管理対象スレッドを作成するためにアプリケーションによって使用されます。スレッドは、コンテナによって開始および管理されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。
ContextService: コンテナのコンテキストを取得する動的プロキシ・オブジェクトを作成して、アプリケーションがそのコンテキスト内で後で実行されるようにするか、管理対象エグゼキュータ・サービスに発行されるようにするために使用されます。コンテナのコンテキストは、タスクを実行するスレッドに伝播されます。
詳細は、Java EE 7チュートリアルのConcurrency Utilities for Java EEに関する項を参照してください。「Java Specification Request 236: Concurrency Utilities for Java EE 1.0」(http://jcp.org/en/jsr/detail?id=236)も参照してください。
サンプルを備えたWebLogic Server一式をインストールする場合、サンプル・ソース・コードは、EXAMPLES_HOME\examples\src\examplesディレクトリに配置されます。デフォルト・パスはORACLE_HOME\wlserver\samples\serverです。このディレクトリから、サンプル・ドメインを設定せずに、Concurrency 1.0サンプルのソース・コードと手順ファイルにアクセスできます。
ORACLE_HOME\user_projects\domains\wl_serverディレクトリには、WebLogic Serverのサンプル・ドメインが含まれています。このドメインには、アプリケーション、アプリケーションおよびOracle WebLogic Serverの動作を定義するXML構成ファイル、および起動スクリプトと環境スクリプトが含まれます。WebLogic Serverサンプル・コードの詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。
Concurrency ContextServiceの使用 - ContextServiceインタフェースを使用して動的プロキシ・オブジェクトを作成する方法を示します。
EXAMPLES_HOME/wl_server/examples/src/examples/javaee7/concurrency/dynamicproxy
Concurrency Executorの使用 - タスク発行用のjavax.enterprise.concurrent.ManagedExecutorServiceの使用方法を示します。
EXAMPLES_HOME/examples/src/examples/javaee7/concurrency/executor
Concurrency Scheduleの使用 - 遅延タスクまたは定期タスク発行用のjavax.enterprise.concurrent.ManagedScheduledExecutorServiceの使用方法を示します。
EXAMPLES_HOME/examples/src/examples/javaee7/concurrency/schedule
Concurrency Threadsの使用: javax.enterprise.concurrent.ManagedThreadFactoryを使用して、Java EEコンテナからスレッドを取得する方法を示します。
EXAMPLES_HOME/examples/src/examples/javaee7/concurrency/threads
同時実行を使用する独自のアプリケーションをプログラミングする前に、これらのサンプルを実行することをお薦めします。
この項では、Concurrency UtilitiesのAPIをワーク・マネージャと関連付けてスレッドをコンテナ管理にすることで、WebLogic ServerがJava EEアプリケーションに同時機能を提供する方法について説明します。
JSR236 Concurrent Utilitiesを使用する場合、WebLogic Serverでは、サーバー・アプリケーション・コンポーネントの非同期タスクを認識し、次の方法で管理できます。
適切な実行コンテキストの提供。「CMOコンテキストの伝播」を参照してください。
単一のサーバー側自己チューニング・スレッド・プールにタスクを発行し、定義済ルールおよび実行時メトリックに基づき、それらの優先順位を決定。「CMOタスクの自己チューニング」を参照してください。
タスクを作成したコンポーネントの停止時にタスクが実行されるスレッドを中断。「CMOが停止する場合のスレッドの中断」を参照してください。
タスクが自己チューニング・スレッド・プールへのディスパッチに適していない場合、管理対象オブジェクトで作成される新しい実行スレッドの数を制限。「長時間実行スレッドに対するCMOの制約」を参照してください。
WebLogic Serverでは、非同期タスク管理は、4種類の同時管理対象オブジェクト(CMO)によって行われます。
表7-1に、非同期タスク管理を行うCMOの概要を示します。
表7-1 非同期タスク管理を行うCMO
| 管理対象オブジェクト | コンテキストの伝播 | 自己チューニング | 停止時のスレッド中断 | 同時長時間実行新規スレッドの制限 |
|---|---|---|---|---|
|
管理対象エグゼキュータ・サービス(MES) |
コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。 |
短時間実行タスクのみが、指定されたワーク・マネージャによって単一の自己チューニング・スレッド・プールにディスパッチされます。「CMOタスクの自己チューニング」を参照してください。 |
ワーク・マネージャの停止中に、すべての未完了タスクが取り消されます。「CMOが停止する場合のスレッドの中断」を参照してください。 |
過剰な数のスレッドによってサーバーが悪影響を受けないように、MESやMSESによって作成される長時間実行スレッドの最大数を構成できます。「長時間実行スレッドに対するCMOの制約」を参照してください。 |
|
管理対象スケジュール済エグゼキュータ・サービス(MSES) |
コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。 |
MESと同じ動作。「CMOタスクの自己チューニング」を参照してください。 |
MESと同じ動作。「CMOが停止する場合のスレッドの中断」を参照してください。 |
MESと同じ動作。「長時間実行スレッドに対するCMOの制約」を参照してください。 |
|
コンテキスト・サービス |
コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。 |
該当なし |
該当なし |
該当なし |
|
管理対象スレッド・ファクトリ(MTF) |
コンテキストは構成に基づいて伝播されます。「CMOコンテキストの伝播」を参照してください。 |
|
|
過剰な数のスレッドによってサーバーが悪影響を受けないように、MTFによって作成される新規スレッドの最大数を構成できます。「長時間実行スレッドに対するCMOの制約」を参照してください。 |
WebLogic Serverには3つのタイプのJSR236 CMOがあり、各CMOは、そのスコープ、およびその定義方法や使用方法で特徴付けられます。
デフォルトJava EE CMO - アプリケーションがデフォルト・リソースを利用できるようにJava EE標準で必要となり、これらのデフォルト・リソースに固有のJNDI名を定義します。
構成ファイル内のカスタマイズ済CMO - アプリケーションおよびモジュール・レベルで定義するか、JNDIにバインドされたアプリケーション・コンポーネント環境(ENC)から参照できます。
グローバルCMOテンプレート - WebLogic Server管理コンソールおよび構成MBeanを使用して、ドメインの構成でテンプレートとしてグローバルに定義できます。
グローバルCMOテンプレートは、ワーク・マネージャと同様に、WebLogic Server管理コンソールまたは構成MBeanを使用して、ドメイン・レベルまたはサーバー・レベルで定義できます。詳細は、「管理コンソールを使用したCMOテンプレートの構成」および「MBeanを使用したCMOテンプレートの構成」を参照してください。
WebLogic ServerのCommonJ API (commonj.work)は、アプリケーションがコンテナ内で複数の作業項目を同時に実行できるようにするインタフェースのセットを提供します。CMOとCommonJ APIは同じレベルで機能します。つまり、どちらもタスクをワーク・マネージャにディスパッチして、アプリケーション内の作業をプログラムで処理します。ただし、CMOとCommonJ APIには、次のような明らかな違いがあります。
CommonJ APIはWeblogicに固有であり、CMOは標準化されています。
CommonJ APIには、CMO管理対象エグゼキュータ・サービス、管理対象スケジュール済エグゼキュータ・サービスのような機能がありますが、管理対象スレッド・ファクトリやコンテキスト・サービスのようなCMO機能はありません。
CommonJ APIの使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server CommonJアプリケーションの開発』のタイマーおよびワーク・マネージャAPIの使用に関する項を参照してください。
この項では、CMOについて伝播される4つのコンテキスト・タイプと、MESおよびMSES管理対象オブジェクトに関するWebLogic Serverでのコンテキスト呼出しポイントについて説明します。
表7-2に、4種類の管理対象オブジェクトについて伝播されるコンテキスト・タイプの概要を示します。
表7-2 伝播されるコンテキスト・タイプ
| コンテキスト・タイプ | 説明 | 実行されるコンテキスト・タスク |
|---|---|---|
|
JNDI |
JNDIネームスペース |
MES、MSESおよびContextServiceの場合、タスクは、発行スレッドのアプリケーション・スコープ指定JNDIツリー( MTFの場合、タスクは、ManagedThreadFactoryインスタンスを作成したコンポーネントのアプリケーション・スコープ指定JNDIツリーにアクセスできます。 |
|
ClassLoader |
コンテキスト・クラス・ローダー |
MES、MSESおよびContextServiceの場合、タスクは、発行スレッドのコンテキスト・クラス・ローダーで実行します。 MTFの場合、タスクは、ManagedThreadFactoryインスタンスを作成したコンポーネントのクラス・ローダーで実行します |
|
セキュリティ |
サブジェクト・アイデンティティ |
MES、MSESおよびContextServiceの場合、タスクは、発行スレッドのサブジェクト・アイデンティティで実行します。MTFの場合、匿名のサブジェクトで実行します。 |
|
ワークエリア |
PropagationModeの |
MES、MSESおよびContext Serviceの場合、新しいWorkAreaコンテキスト・タイプがあるため、すべてのタスクはWorkContextMapで実行します。この中には、WORKモードによる発行スレッドのコンテキストがすべて含まれます。 MTFの場合、すべてのタスクは空のWorkContextMapで実行します。 注意: WorkContextMapは新しいインスタンスですが、含まれる値は新しいものではないため、値の内容を更新すると、発行スレッドの内容に影響を与える場合があります。 |
表7-3に、WebLogic Serverでのコンテキスト呼出しポイントのコールバック・メソッドと、MESおよびMSES管理対象オブジェクトの場合にコンテキスト呼出しポイントが実行するコンテキストの概要を示します。
表7-3 コンテキスト呼出しポイント
| 同時管理対象オブジェクト | コンテキスト呼出しポイント | コンテキスト呼出しポイントが実行するコンテキスト |
|---|---|---|
|
ManagedExecutorService |
コールバック・メソッド: |
コンテキスト呼出しポイントは、 |
|
ManagedScheduledExecutorService |
コールバック・メソッド: j |
|
MESまたはMSESに発行される短時間実行タスクは、デプロイメント・ディスクリプタで指定されるワーク・マネージャに関連付けることで、単一の自己チューニング・スレッド・プールにディスパッチされます。
タスクの実行は、指定のワーク・マネージャに定義されているルールと一致します。MESおよびMSESの実行メソッドに発行されるタスクの場合、ワーク・マネージャの過負荷ポリシーによってタスクが拒否されると、次のイベントが発生します。
java.util.concurrent.RejectedExecutionExceptionは、発行メソッドまたは実行メソッドでスローされます。
weblogic.work.Workに渡される過負荷理由パラメータは、RejectedExecutionExceptionに設定されます。
ユーザーがタスクをManagedTaskListenerに登録した場合、ユーザーはRejectedExecutionException経由で過負荷メッセージを受信できるため、このリスナーには通知されません。
注意: ManagedTaskListenerは、タスクの将来の状態を監視する場合に使用されます。詳細は、「Package javax.enterprise.concurrent」を参照してください。
MESおよびMSESのinvokeAll()メソッドおよびinvokeAny()メソッドでは、ワーク・マネージャの過負荷ポリシーで拒否される発行済タスクの場合、次のイベントが発生します。
ユーザーが登録したManagedTaskListenerのtaskSubmitted()メソッドが呼び出されます。
ユーザーが登録したManagedTaskListenerのtaskDone()メソッドが呼び出され、throwableParamがjavax.enterprise.concurrent.AbortedExceptionになります。
weblogic.work.Workに渡される過負荷理由パラメータは、AbortedExceptionに設定されます。
schedule()、scheduleAtFixRate()、scheduleAtFixDelay()およびschedule(Trigger)()メソッドの場合、ワーク・マネージャの過負荷ポリシーによってタスクが拒否されると、次のイベントが発生します。
ユーザーが登録したManagedTaskListenerのtaskDone()メソッドがコールされ、throwableParamはjavax.enterprise.concurrent.AbortedExceptionになります。
weblogic.work.Workに渡される過負荷理由パラメータは、AbortedExceptionに設定されます。
タスクが周期的な場合、タスクの次の実行は引き続きスケジュールされます。
MESまたはMSESのいずれかが停止した場合:
待機中のタスクは実行されません。
実行中のタスクはすべて中断されます。ユーザーは、Thread.isInterrupted()メソッドを確認して、そのタスクを終了する必要があります。これは、WebLogic Serverによって強制的に終了されないためです。
Future.get()メソッドをコールする場合、エグゼキュータが返すFutureオブジェクトによって、java.util.concurrent.CancellationException()がスローされます。
ユーザーが登録したManagedTaskListenerのtaskAborted()メソッドがコールされ、paramThrowableはCancellationException()になります。
MTFが停止した場合:
newThread()メソッドを使用して作成されたメソッドはすべて中断されます。これらのスレッドに対してManageableThreadインタフェースでisShutdown()メソッドをコールすると、trueが返されます。
newThread()メソッドの後続のすべてのコールで、java.lang.IllegalStateExceptionがスローされます。
ContextServiceの場合、スレッドは中断されません。ただし、次の例外があります。
プロキシされたインタフェース・メソッドの呼出しはすべて、java.lang.IllegalStateExceptionが発生して失敗します。
前述のように、MESおよびMSESに発行された長時間実行タスクと、MTFのnewThread()メソッドのコールでは、自己チューニング・スレッド・プールの一部として管理されない新しいスレッドを作成する必要があります。実行中のスレッドの数が過大になると、サーバーのパフォーマンスと安定性に悪影響を与える可能性があるため、同時実行性ユーティリティAPIによって作成される実行中のスレッドの最大数を指定する構成が用意されています。
MESおよびMSESに発行される同時長時間実行リクエストの制限は、管理対象オブジェクト・レベルとサーバー・レベルで指定できます。すべての構成レベルは独立しており、最大同時長時間実行リクエストはそれらのいずれも超えることはできません。
表7-4は、デプロイメント・ディスクリプタで定義できるmax-concurrent-long-running-requests要素を含む同時長時間実行リクエストの制限をまとめたものです。
表7-4 同時長時間実行リクエストの制限
| 有効範囲 | デプロイメント・ディスクリプタ | 説明 | <max-concurrent-long-running-requests>要素の詳細 |
|---|---|---|---|
|
サーバー |
|
該当サーバーに指定される同時長時間実行リクエストの制限。 |
省略可能 範囲: [0-65534]。範囲外の場合、デフォルト値が使用されます デフォルト値: 100 |
|
管理対象オブジェクト |
|
該当のMESまたはMSESに指定される同時長時間実行リクエストの制限。 |
デフォルト値が10であることを除き、前述と同様です。 |
指定された制限を超えた場合、MESまたはMSESは、発行された新しい長時間実行タスクに対して次のアクションを実行します。
タスク発行APIを呼び出すときにjava.util.concurrent.RejectedExecutionExceptionがスローされます。
ユーザーがManagedTaskListenerを使用してタスクを登録している場合、発行メソッドが失敗しているためこのリスナーには通知されません。
前述の規則は、invokeAll()メソッドとinvokeAny()メソッドには適用されないことに注意してください。これらのメソッドによって発行されたすべてのタスクは、指定済の制限によって拒否され、次のイベントが発生します。
ユーザーが登録したManagedTaskListenerのtaskSubmitted()メソッドが呼び出されます。
ユーザーが登録したManagedTaskListenerのtaskDone()メソッドが呼び出され、throwableParamがjavax.enterprise.concurrent.AbortedExceptionになります。
その他の発行済タスクは影響を受けません。
メソッドは、RejectedExecutionExceptionをスローしません。
例7-1に、config.xml内のmax-concurrent-long-running-requests要素に指定された値が長時間実行リクエストの最大数にどのように影響する可能性があるかを示します。
例7-1 config.xml内のmax-concurrent-long-running-requestsの配置例
<domain>
<server>
<name>myserver</server>
<max-concurrent-long-running-requests>50</max-concurrent-long-running-requests> (place 1)
</server>
<max-concurrent-long-running-requests>10</max-concurrent-long-running-requests> (place 2)
<server-template>
<name>mytemplate</name>
<max-concurrent-long-running-requests>50</max-concurrent-long-running-requests> (place 3)
</server-template>
</domain>
place 1 - サーバー・インスタンスmyserverで定義されているMESとMSESに影響します。そのサーバー・インスタンスで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大50だけ作成できます。
place 2 – ドメインで定義されるMESおよびMSESにのみ影響します。ドメインで実行するすべてのMESおよびMSESは、長時間実行リクエストを合計で最大10作成できます。
place 3 - テンプレートmytemplateに適用されるサーバー・インスタンスで定義されているMESとMSESに影響します。そのサーバー・インスタンスで実行されているすべてのMESとMSESは、長時間実行リクエストを合計で最大50だけ作成できます。
例7-2に、config.xml内のmax-concurrent-long-running-requests要素に指定された値が長時間実行リクエストの最大数にどのように影響する可能性があるかを示します。
例7-2 max-concurrent-long-running-requestsの構成のサンプル
server1(100)
|---application1
|---managed-scheduled-executor-service1(not specified)
|---module1
|---managed-executor-service1(20)
|---managed-scheduled-executor-service2(not specified)
|---application2
次の場合は、いずれの制限も超過しておらず、前述のアクションは実行されません。
120の長時間実行タスクがmanaged-executor-service1に発行され、それらのうち115は完了し、5つが実行中であると仮定すると、1つの長時間実行タスクがmanaged-executor-service1に追加で発行された場合、制限は超えていないため実行されます。
次の場合は、1つの制限が超過しているため、前述のアクションが実行されます。
10の長時間実行タスクがmanaged-scheduled-executor-service1によって実行されていると仮定すると、1つの長時間実行タスクがmanaged-scheduled-executor-service1に追加で発行された場合、managed-scheduled-executor-service1の制限を超過します。
10の長時間実行タスクがapplication1によって実行され、90がapplication2によって実行されていると仮定すると、1つの長時間実行タスクがapplication1またはapplication2に追加で発行された場合、server1の制限を超過します。
MTFのnewThread()メソッドを呼び出して作成された同時新規実行スレッドの制限は、管理対象オブジェクト、ドメインおよびサーバー・レベルで指定できます。すべての構成レベルは独立しており、同時新規実行スレッドの最大数はそれらのいずれも超えることはできません。
実行スレッドとは、MTFによって作成され、そのrun()メソッドがまだ完了していないスレッドであることに注意してください。
表7-5は、デプロイメント・ディスクリプタで定義できる要素<max-concurrent-new-threads>を含む同時新規実行スレッドの制限をまとめたものです。
表7-5 同時新規実行スレッドの制限
| 有効範囲 | デプロイメント・ディスクリプタ | 説明 | <max-concurrent-long-running-requests>要素の詳細 |
|---|---|---|---|
|
サーバー |
|
該当サーバーに指定される新しい同時実行スレッドの制限。 |
省略可能 範囲: [0-65534]。範囲外の場合、デフォルト値が使用されます デフォルト値: 100 |
|
管理対象オブジェクト |
|
該当のManagedThreadFactoryに指定される新しい同時実行スレッドの制限 |
デフォルト値が10であることを除き、前述と同様です。 |
指定された制限を超えた場合、MTFのnewThread()メソッドへの呼出しでは、ThreadFactory.newThread Javadocに一致するようにnullを返します。
max-concurrent-new-threadsを使用するサンプル・スニペットを確認するには、例7-2「max-concurrent-long-running-requestsの構成のサンプル」を参照してください。
Java EE標準では、アプリケーションが特定のデフォルト・リソースにアクセスできるようにすることが指定され、それらのデフォルト・リソースに固有のJNDI名が定義されます。WebLogic Serverでは、次のようにして、Java EE標準のJNDI名を特定のWebLogic Serverリソースにマップする論理JNDI名を使用することで、それらの名前を使用可能にします。
アプリケーションごとにデフォルトのMESインスタンスがあります。これは、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultManagedExecutorServiceのデフォルトJNDI名に自動でバインドされます。
デフォルトのワーク・マネージャをディスパッチ・ポリシーとして使用
すべてのコンテキスト情報の伝播
長時間実行リクエストの制限のデフォルトは10
長時間実行スレッドの優先順位をデフォルトでnormalに設定
アプリケーションのデフォルトのMESを@Resourceアノテーションとともに使用することもできます。例:
package com.example;
public class TestServlet extends HttpServlet {
@Resource
private ManagedExecutorService service;
デフォルトMESのオーバーライド
デフォルトMESの動作は、次の方法でオーバーライドできます。
config.xmlでDefaultManagedExecutorServiceというエグゼキュータ・テンプレートを定義します。すべてのアプリケーションでは、このテンプレートを使用してデフォルトMESを作成します。
デプロイメント・ディスクリプタまたはアノテーションのいずれかを使用して、weblogic-application.xmlでカスタムのmanaged-executor-serviceを定義します。これにより、アプリケーションのconfig.xmlでデフォルトMESの定義もオーバーライドされます。「カスタム管理対象エグゼキュータ・サービスの構成要素」を参照してください。
weblogic.xmlまたはweblogic-ejb-jar.xmlでDefaultManagedExecutorServiceというデフォルト・エグゼキュータを定義できません。定義した場合、デプロイメントが失敗します。
デフォルトMSESインスタンスは、デフォルトMESインスタンスと似ていますが、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultManagedScheduledExecutorServiceのデフォルトJNDI名に自動でバインドされます。デフォルト設定は同じで、すべてのコンテキスト情報が伝播されます。
アプリケーションのデフォルトのMSESを@Resourceアノテーションとともに使用することもできます。例:
package com.example;
public class TestServlet extends HttpServlet {
@Resource
private ManagedScheduledExecutorService service;
デフォルトMSESのオーバーライド
デフォルトMSESの動作は、次の方法でオーバーライドできます。
config.xmlでDefaultManagedScheduledExecutorServiceというスケジュール済エグゼキュータ・テンプレートを定義します。すべてのアプリケーションでは、このテンプレートを使用してデフォルトMSESを作成します。
デプロイメント・ディスクリプタまたはアノテーションのいずれかを使用して、weblogic-application.xmlでカスタムの<managed-scheduled-executor-service>を定義します。これにより、アプリケーションのconfig.xmlでデフォルトMSESの定義もオーバーライドされます。「カスタム管理対象スケジュール済エグゼキュータ・サービスの構成要素」を参照してください。
weblogic.xmlまたはweblogic-ejb-jar.xmlでDefaultManagedExecutorServiceというデフォルトのスケジュール済エグゼキュータを定義できません。定義した場合、デプロイメントが失敗します。
アプリケーションごとにデフォルトのコンテキスト・サービス・インスタンスがあります。これは、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultContextServiceのデフォルトJNDI名に自動でバインドされ、すべてのタイプのサポート対象コンテキストが伝播されます。
デフォルト・コンテキスト・サービスは、resource-env-refまたは@Resourceアノテーションを使用して、アプリケーション・コンポーネント環境(ENC)でjava:comp/env/concurrent/csにバインドすることもできます。
デフォルト・コンテキスト・サービスの動作はオーバーライドできないことに注意してください。
例7-3に、resource-env-ref要素を使用して、webl.xmlファイルでデフォルト・コンテキスト・サービスを使用する方法を示します。
例7-3 Webアプリケーションでの<resource-env-ref>によるデフォルト・コンテキスト・サービスの使用
<!-- web.xml --> <resource-env-ref> <resource-env-ref-name>concurrent/cs</resource-env-ref-name> <resource-env-ref-type>javax.enterprise.concurrent.ContextService</resource-env-ref-type> </resource-env-ref>
例7-4に、@Resourceアノテーションを使用して、サーブレットでデフォルト・コンテキスト・サービスを使用する方法を示します。
例7-4 サーブレットでの@Resourceによるデフォルト・コンテキスト・サービスの使用
// when using @Resource, the following 2 ways are correct.
@Resource(lookup="java:comp/env/concurrent/cs")
// @Resource(name="concurrent/cs")
private ContextService service;
// when using JNDI Naming Context to lookup:
// initialContext.lookup("java:comp/env/concurrent/cs")
アプリケーションごとにデフォルトのMTFインスタンスがあります。これは、デプロイ時にすべてのサブ・コンポーネントのjava:comp/DefaultManagedThreadFactoryのデフォルトJNDI名に自動でバインドされます。
新しいスレッドに対してサポートされるすべてのタイプのコンテキストを伝播
newThread()で作成される長時間実行スレッドのデフォルトの優先順位はnormal
新しい同時スレッドの実行のデフォルト制限は10
アプリケーションのデフォルトのMTFを@Resourceアノテーションとともに使用することもできます。例:
package com.example;
public class TestServlet extends HttpServlet {
@Resource
private ManagedThreadFactory service;
デフォルトMTFのオーバーライド
デフォルトMTFの動作は、次の方法でオーバーライドできます。
config.xmlでDefaultManagedThreadFactoryというスレッド・ファクトリ・テンプレートを定義します。すべてのアプリケーションでは、このテンプレートを使用してデフォルトMTFを作成します。
デプロイメント・ディスクリプタまたはアノテーションのいずれかを使用して、weblogic-application.xmlでカスタムのmanaged-thread-factoryを定義します。これにより、アプリケーションのconfig.xmlでデフォルトMTFの定義もオーバーライドされます。「カスタム管理対象スレッド・ファクトリの構成要素」を参照してください。
weblogic.xmlまたはweblogic-ejb-jar.xmlでDefaultManagedThreadFactoryというデフォルト・スレッド・ファクトリを定義できません。定義した場合、デプロイメントが失敗します。
カスタマイズ済CMOは、アプリケーションおよびモジュール・レベルで定義するか、JNDIにバインドされるアプリケーション・コンポーネント環境(ENC)から参照できます。
|
注意: 現行リリースでは、カスタム・コンテキスト・サービスは構成できません。 |
カスタマイズ済CMOは、次のいずれかの構成ファイルで、アプリケーションおよびモジュール・レベルで定義できます。
weblogic-application.xml - アプリケーション・レベルで指定したCMOは、そのアプリケーション、またはそのアプリケーションのコンポーネントに割り当てることができます。
weblogic-ejb-jar.xmlまたはweblogic.xml - コンポーネント・レベルで指定したCMOは、そのコンポーネントに割り当てることができます。
エグゼキュータおよびスレッド・ファクトリCMOは、resource-env-ref要素または@Resourceアノテーションを使用して、アプリケーション・コンポーネント環境(ENC)でJNDIにバインドすることもできます。CMOを参照するresource-env-refは、web.xml、ejb-jar.xmlまたはapplication.xmlでのみ定義できます。
4つのENCネームスペース(java:comp、java:module、java:applicationおよびjava:global)は、resource-env-ref-nameおよび@Resourceに対してサポートされます。
アプリケーションAppAでエグゼキュータをjava:global JNDIネームスペースにバインドする場合、そのエグゼキュータを別のアプリケーションAppBで参照および使用できます。AppBで発行されるタスクは、AppAまたはAppBが停止すると取り消されます
例7-5に、MyExecutorというMESをjava:comp/env JNDIネームスペースにマップする方法を示します。
例7-5 <resource-env-ref>を使用した、エグゼキュータのJNDIへのバインド
weblogic.xml
<resource-env-description>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name>
<resource-link>MyExecutor</resource-link>
</resource-env-description>
web.xml
<resource-env-ref>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name>
<resource-env-ref-type>javax.enterprise.concurrent.ManagedExecutorService</resource-env-ref-type>
</resource-env-ref>
weblogic.xmlでは、resource-link要素によって、マップするエグゼキュータが指定されます。例7-5ではMyExecutorが指定されています。
weblogic.xmlで定義されているエグゼキュータが最初に検索され、次にweblogic-application.xml、config.xmlのmanaged-executor-service-templateの検索が続き、resource-linkで指定されたエグゼキュータに一致するエグゼキュータ名属性を見つけます。
resource-env-descriptionをweblogic-ejb-jar.xmlで定義する場合、weblogic-ejb-jar.xmlが最初に検索され、次にweblogic-application.xml、config.xmlの検索が続きます。
@Resourceアノテーションのマッピング・ルールは、resource-env-refのルールに相当しますが、次の異なる命名規則を使用します。
resource-env-ref-nameは、@Resourceのname属性値です。
resource-linkは、@Resourceで定義されるmappedName属性値に相当します。
Webコンポーネントで@Resourceを使用する場合、web.xmlでのresource-env-refの定義に相当します
EJBコンポーネントで@Resourceを使用する場合、ejb-jar.xmlでのresource-env-refの定義に相当します。
Java EE仕様で定義されるように、アノテーションをクラスまたはメソッドで使用することもできます。
resource-env-ref定義を使用する例7-6は、@Resourceを使用する例7-6に相当します。
例7-6 @Resourceを使用した、エグゼキュータのJNDIへのバインド
package com.example;
public class TestServlet extends HttpServlet {
@Resource(name="concurrent/MyExecutor" mappedName="MyExecutor")
private ManagedExecutorService service;
この例では、@ResourceのmappedName属性を指定しない場合、デフォルトのエグゼキュータが使用されます。
resource-env-refと@Resourceをどちらも定義し、@Resourceのresource-env-ref-nameとname属性が同じ場合、resource-env-ref定義のエグゼキュータは@Resourceフィールドに挿入されます。
参照属性またはInitialContext.lookupで@Resourceを使用して、resource-env-refによってバインドされるエグゼキュータを見つけることもできます。
次のWebLogic Serverスキーマには、CMOデプロイメント・ディスクリプタを構成するための要素が含まれています。
weblogic-javee.xsd – WebLogic固有のすべてのデプロイメント・ディスクリプタ間で共有される共通の要素を記述します。
http://xmlns.oracle.com/weblogic/weblogic-javaee/1.4/weblogic-javaee.xsd
weblogic-application.xml - application.xml Java EEデプロイメント・ディスクリプタを拡張したWebLogic Server固有のデプロイメント・ディスクリプタです。ここでは、アプリケーションやEJBキャッシングで参照される共有Java EEライブラリなどの機能を構成します。
『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』のweblogic-application.xmlのデプロイメント・ディスクリプタ要素に関する項を参照してください。
weblogic-web-app.xsd – WebアプリケーションのWebLogic Server固有のデプロイメント・ディスクリプタ。
『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。
weblogic-ejb-jar.xsd – EJBデプロイメントのWebLogic固有のXMLスキーマベース(XSD)デプロイメント・ディスクリプタ・ファイル。
Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発のweblogic-ejb-jar.xmlデプロイメント・ディスクリプタのリファレンスに関する項を参照してください。
例7-7に、weblogic-web-app.xsdのCMO関連要素を示します。
例7-7 weblogic-web-app.xsdのCMO要素
<xs:complexType name="weblogic-web-appType">
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded">
...
<!-- added for JSR236 -->
<xs:element name="managed-executor-service" type="wls:managed-executor-serviceType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="managed-scheduled-executor-service" type="wls:managed-scheduled-executor-serviceType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="managed-thread-factory" type="wls:managed-thread-factoryType" minOccurs="0" maxOccurs="unbounded"/>
<!-- added end -->
...
次のWebLogic Serverシステム・モジュールBeanには、アプリケーションおよびモジュールでCMOを構成するための属性が含まれています。
WebLogicEjbJarBean
WebLogicWebAppBean
詳細は、Oracle WebLogic Server MBeanリファレンスのWebLogic Serverシステム・モジュールMBeanに関する項を参照してください。
この項では、管理対象エグゼキュータ・サービスの構成要素を定義します。
表7-6 管理対象エグゼキュータ・サービスの構成要素
| 名前 | 説明 | 必須 | デフォルト値 | 範囲 |
|---|---|---|---|---|
|
name |
MESの名前。 同じ名前のMESを同じスコープで構成することはできません。たとえば、同じMES名をアプリケーションまたはモジュールのスコープで使用する場合、そのアプリケーションのデプロイメントが失敗します。 MESでは、ContextServiceなど他の種類の管理対象オブジェクトと同じ名前をスコープ内で使用できますが、その間に関連はありません。 同じ名前のMESは、次の場合、異なるスコープでのみ構成できます。
|
はい |
該当なし |
任意の空でない文字列。 |
|
dispatch-policy |
ワーク・マネージャの名前。どのワーク・マネージャを使用するかについてのルールは次のとおりです。
|
いいえ |
デフォルトのワーク・マネージャ |
該当なし |
|
max-concurrent-long-running-requests) |
同時長時間実行タスクの最大数。 「最大同時長時間実行リクエストの制限の設定」を参照してください。 |
いいえ |
10 |
[0-65534]. 範囲外の場合、デフォルト値が使用されます。 |
|
long-running-priority |
長時間実行デーモン・スレッドの優先度を指定する整数。指定すると、すべての長時間実行スレッドが影響を受けます。 「最大同時新規スレッドの制限の設定」を参照してください。 |
いいえ |
|
1-10
|
例7-8は、Webアプリケーションのweblogic.xmlファイルでのカスタムMES定義の例です。
例7-8 デプロイメント・ディスクプタを使用した、アプリケーションでのカスタムMESの定義
<!-- weblogic.xml -->
<managed-executor-service>
<name>MyExecutor</name>
<dispatch-policy>MyWorkManager</dispatch-policy>
<long-running-priority>10</long-running-priority>
<max-concurrent-long-running-requests>10</max-concurrent-long-running-requests>
</managed-executor-service>
例7-9は、<resource-env-ref>要素を使用した、weblogic.xmlディスクリプタでのカスタムMES参照の例です。
例7-9 <resource-env-ref>を使用した、アプリケーションでのカスタムMESの参照
weblogic.xml
<resource-env-description>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name
<resource-link>MyExecutor</resource-link>
</resource-env-description>
例7-10は、<resource-env-ref>要素を使用した、webl.xmlファイルでのカスタムMES参照の例です。
例7-10 <resource-env-ref>を使用した、WebアプリケーションでのカスタムMESの参照
web.xml
<resource-env-ref>
<resource-env-ref-name>concurrent/MyExecutor</resource-env-ref-name
<resource-env-ref-type>javax.enterprise.concurrent.ManagedExecutorService</resource-env-ref-type>
</resource-env-ref>
例7-11は、@Resourceアノテーションを使用した、サーブレットでのカスタムMES参照の例です。
この項では、管理対象スケジュール済エグゼキュータ・サービスの構成要素を定義します。
表7-7 管理対象スケジュール済エグゼキュータ・サービスの構成要素
| 名前 | 説明 | 必須 | デフォルト値 | 範囲 |
|---|---|---|---|---|
|
name |
MSESの名前。 命名規則のルールについては、表7-6「管理対象エグゼキュータ・サービスの構成要素」を参照してください。 |
はい |
該当なし |
任意の空でない文字列。 |
|
dispatch-policy |
ワーク・マネージャの名前。 ワーク・マネージャの使用ルールについては、表7-6「管理対象エグゼキュータ・サービスの構成要素」を参照してください。 |
いいえ |
デフォルトのワーク・マネージャ |
該当なし |
|
max-concurrent-long-running-requests |
同時長時間実行タスクの最大数。 「最大同時長時間実行リクエストの制限の設定」を参照してください。 |
いいえ |
10 |
[0-65534]. 範囲外の場合、デフォルト値が使用されます。 |
|
long-running-priority |
長時間実行デーモン・スレッドの優先度を指定する整数。指定すると、すべての長時間実行スレッドが影響を受けます。 「最大同時新規スレッドの制限の設定」を参照してください。 |
いいえ |
5 |
1-1
|
ScheduledFuture.get()メソッドは、タスクの最新の実行が完了するまでブロックします。たとえば、Triggerメソッドで、スケジュール予定のタスクを2回実行する必要があり(Trigger.getNextRunTimeは3回目のコールに対してnullを返す)、タスクの最初の実行が時間Aで完了し、タスクの2回目の実行が時間Bで完了する場合、次のようになります。
時間Aの前にFuture.get()をコールする場合、最初の実行が完了して最初の実行結果が返されるまで待機します。時間Aの後、時間Bの前にコールする場合、2回目の実行が完了して2回目の実行結果が返されるまで待機します。
時間Bの後にFuture.get()をコールする場合、2回目の実行結果がすぐに返されます。また、最初の実行が失敗して例外がスローされる場合、Futhur.getの最初のコールによって該当の例外がスローされ、2回目の実行は引き続きスケジュールされます(これはscheduleAtFixRateでは異なります)。Trigger.skipRunで最初の実行時にtrueが返される場合、Future.getの最初のコールでSkipExceptionがスローされます。
この項では、管理対象スレッド・ファクトリの構成要素を定義します。
表7-8 管理対象スレッド・ファクトリの構成要素
| 名前 | 説明 | 必須 | デフォルト値 | 範囲 |
|---|---|---|---|---|
|
name |
MTFの名前。 命名規則のルールについては、表7-6「管理対象エグゼキュータ・サービスの構成要素」を参照してください。 |
はい |
該当なし |
任意の空でない文字列。 |
|
priority |
スレッドに割り当てる優先度。(数が大きいほど、高い優先度を示します。) 「最大同時新規スレッドの制限の設定」を参照してください。 |
いいえ |
5 |
1-10 |
|
max-concurrent-new-threads |
MTFによって作成され、タスクの 「最大同時新規スレッドの制限の設定」を参照してください。 |
いいえ |
10 |
[0-65534] 範囲外の場合、デフォルト値が使用されます。 |
JSR236に従う場合、管理対象スレッド・ファクトリは、それ以外の管理対象オブジェクトとは異なります。これは、Thread.start()メソッドを使用してスレッドを開始した場合、実行される実行可能ファイルは、ManagedThreadFactoryインスタンスを作成したアプリケーション・コンポーネント・インスタンスのコンテキストで実行するためです。そのため、実行可能ファイルのコンテキストは、MTFインスタンスを作成したアプリケーション・コンポーネントによって異なります。
WebLogic Serverでは、アプリケーションまたはコンポーネントを開始すると、新しいMTFインスタンスが次のように作成されます。(コンポーネントは、WebモジュールまたはEJBを表します。)
デフォルトMTFは該当のコンポーネントで作成されます。
MTFを取得する@Resourceアノテーションがある場合、MTFインスタンスは該当コンポーネントで作成されます。
web.xml/ejb-jar.xmlで<resource-env-ref>が定義されており、MTFの<resource-link>を含むweblogic.xml/weblogic-ejb-jar.xmlで、対応する<resource-env-description>も定義されている場合、MTFインスタンスは該当コンポーネントで作成されます。
application.xmlで<resource-env-ref>が定義されており、MTFの<resource-link>を含むweblogic-application.xmlで、対応する<resource-env-description>も定義されている場合、MTFインスタンスは該当アプリケーションで作成されます。
前述の項目1、2、3の場合にMTFがコンポーネントで作成される場合、実行可能ファイルは、次のように該当コンポーネントのコンテキストで実行します。
ClassLoader: 該当コンポーネントのクラス・ローダー。
JNDI: java:app、java:moduleおよびjava:compが含まれる該当コンポーネントのJNDIツリー。
Security: コンポーネントに固有のサブジェクトがないため、匿名サブジェクトに固定されます。
WorkArea: コンポーネントに固有のWorkContextMapがないため、空のWorkContextMapに固定されます。
4の場合にMTFがアプリケーションで作成される場合、実行可能ファイルは、次のように該当アプリケーションのコンテキストで実行します。
ClassLoader: 該当アプリケーションのクラス・ローダー。
JNDI: java:appは含まれるが、java:moduleおよびjava:compは含まれない該当コンポーネントのJNDIツリー。
Security: アプリケーションに固有のサブジェクトがないため、匿名サブジェクトに固定されます。
WorkArea: アプリケーションに固有のWorkContextMapがないため、空のWorkContextMapに固定されます。
例7-13は、Webアプリケーションのweblogic.xmlファイルでのカスタムMTF定義の例です。
例7-13 デプロイメント・ディスクプタを使用した、アプリケーションでのカスタムMTFの定義
<!-- weblogic.xml -->
<managed-thread-factory>
<name>factory1</name>
<priority>3</priority>
<max-concurrent-new-threads>20</max-concurrent-new-threads>
</managed-executor-service>
例7-9は、Webアプリケーションのweblogic.xmlファイルでのカスタムMTF参照の例です。
例7-14 <resource-env-ref>を使用した、アプリケーションでのカスタムMTFの参照
weblogic.xml
<resource-env-description>
<resource-env-ref-name>ref-factory1</resource-env-ref-name
<resource-link>factory1</resource-link>
</resource-env-description>
例7-10は、Webアプリケーションのweblogic.xmlファイルでのカスタムMTF参照の例です。
例7-15 <resource-env-ref>を使用した、WebアプリケーションでのカスタムMTFの参照
web.xml
<resource-env-ref>
<resource-env-ref-name>ref-factory1</resource-env-ref-name
<resource-env-ref-type>javax.enterprise.concurrent.ManagedThreadFactory</resource-env-ref-type>
</resource-env-ref>
例7-11は、@Resourceアノテーションを使用した、サーブレットでのカスタムMTF参照の例です。
この項では、CMOについてトランザクションがWebLogic Serverでどのように管理されるかについて説明します。
MESを使用する場合、トランザクションは次のように管理されます。
タスクを開始する前に、ワーク・マネージャのスレッドに実行中のトランザクションはありません。
トランザクションAPIを使用して新しいトランザクションを開始する場合を除き、UserTransaction.getStatus()メソッドは常にStatus.STATUS_NO_TRANSACTIONになります。
ユーザーは、必ずユーザー・タスクでそのトランザクションを完了する必要があります。完了しない場合、トランザクションはロールバックされます。
そのため、ManagedTask.TRANSACTIONおよび関連属性は無視されます。
デフォルト、または実行プロパティManagedTask.TRANSACTIONの値をManagedTask.SUSPENDに設定する場合:
スレッドに対して現在アクティブなトランザクションは中断されます。
ローカルJNDIネームスペースでjava:comp/UserTransactionとしてアクセス可能なjavax.transaction.UserTransactionが利用できるため、コンテキスト・プロキシ・オブジェクトにより、トランザクションの開始、コミット、ロールバックが行われます。
コンテキスト・プロキシ・オブジェクトで開始されたトランザクションがメソッドの終了前に完了しない場合、WARNINGログが出力され、トランザクションはロールバックされます。
元のトランザクションは、いずれかがスレッドに対してアクティブだった場合、タスクまたはコンテキスト・プロキシ・オブジェクトのメソッドが戻ると再開します。
実行プロパティManagedTask.TRANSACTIONの値をManagedTask.USE_TRANSACTION_OF_EXECUTION_THREADに設定する場合:
トランザクションは、実行スレッドとタスク自体で管理されるため、コンテキスト・プロキシ・オブジェクトのメソッドの開始時に、スレッドに対して現在アクティブなトランザクションが中断されず、コンテキスト・プロキシ・オブジェクトのメソッドが戻ってもトランザクションは再開されません。
スレッドに対して現在アクティブなトランザクションがある場合、コンテキスト・プロキシ・オブジェクトで使用されるリソースは、該当トランザクションに確保されます。
コンテキスト・プロキシ・オブジェクトで開始されたトランザクションがメソッドの終了前に完了しない場合、トランザクションがコンテキスト・プロキシ・オブジェクトの別のメソッドで完了する可能性があるため、WebLogic Serverでは何も行われません。
JSR236のデフォルトCMOの他に、WebLogic Server管理コンソールおよび構成MBeanを使用して、ドメインの構成でグローバルCMOをテンプレートとして定義することもできます。config.xmlで指定したCMOは、ドメイン内の任意のアプリケーションまたはアプリケーション・コンポーネントに割り当てることができます。
|
注意: 通常は、管理コンソールを使用して、WebLogic Serverの管理可能オブジェクトおよびサービスを構成し、WebLogic Serverでのconfig.xmlファイルの管理を許可する必要があります。 |
ドメインでは3つのタイプのCMOテンプレートを定義できます。
管理対象エグゼキュータ・サービス・テンプレート
管理対象スケジュール済エグゼキュータ・サービス・テンプレート
管理対象スレッド・ファクトリ・テンプレート
たとえば、managed-executor-service-templateを定義する場合、ドメインにデプロイされているアプリケーションごとに一意のMESインスタンスが作成されます。
CMOテンプレートは、 WebLogic Server管理コンソールを使用して、ドメインの構成でグローバルに構成できます。
「ドメイン構造」ツリーで、「環境」を展開し、「同時テンプレート」をクリックします。
「新規」をクリックし、次のいずれかのテンプレート・オプションを選択します。
管理対象エグゼキュータ・サービス・テンプレート
管理対象スケジュール済エグゼキュータ・サービス・テンプレート
管理対象スレッド・ファクトリ・テンプレート
新規テンプレートの作成ページで、必要に応じてテンプレートのプロパティを入力します。プロパティは、作成する同時テンプレートのタイプによって異なります。
「次」をクリックします。
同時テンプレートを、特定のWebLogic ServerインスタンスとWebLogic Serverクラスタのどちらにターゲット指定するかを選択します。
選択したサーバーまたはクラスタにデプロイされているアプリケーションのみがこの同時テンプレートを使用できます。
「終了」をクリックします。同時テンプレートのサマリーページが表示され、新しい同時テンプレートがリストされます。
必要に応じてその他の同時テンプレートを作成するには、これらの手順を繰り返します。
WebLogic Server管理コンソールを使用してWebLogic Serverドメインを管理する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。
CMOテンプレートは、DomainMBeanで次の構成MBeanを使用して構成できます。
詳細は、Oracle WebLogic Server MBeanリファレンスのドメイン構成MBeanに関する項を参照してください。
制約は、WebLogic Server管理コンソールおよび構成MBeanを使用して、ドメインの構成でグローバルに定義することもできます。config.xmlで指定した同時制約は、ドメイン内の任意のアプリケーションまたはアプリケーション・コンポーネントに割り当てることができます。
同時制約は、管理コンソールを使用して、ドメイン構成、指定のサーバー・インスタンス、および動的クラスタのサーバー・テンプレートで構成できます。
ドメインの同時制約の構成手順:
「ドメイン構造」ツリーで、ツリー最上部のドメイン名を選択します。
「構成」→「同時実行性」タブを選択します。
「同時実行性」ページで、選択可能なオプションのいずれかまたは全部の値を指定します。
最大同時長時間実行リクエスト - 管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行される同時長時間実行リクエストの制限。「最大同時長時間実行リクエストの制限の設定」を参照してください。
最大同時新規スレッド - 自己チューニング・スレッド・プールの外部で管理対象スレッド・ファクトリが作成する同時新規スレッドの最大数。「最大同時新規スレッドの制限の設定」を参照してください。
「Save」をクリックします。
ドメインの特定サーバー・インスタンスに対する同時制約の構成手順:
「ドメイン構造」ツリーで、「環境」を開き、「サーバー」をクリックします。
「サーバーのサマリー」表で、サーバー・インスタンスを選択します。
「同時実行性」ページで、選択可能なオプションのいずれかまたは全部の値を指定します。
最大同時長時間実行リクエスト - 管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行される同時長時間実行リクエストの制限。「最大同時長時間実行リクエストの制限の設定」を参照してください。
最大同時新規スレッド - 自己チューニング・スレッド・プールの外部で管理対象スレッド・ファクトリが作成する同時新規スレッドの最大数。「最大同時新規スレッドの制限の設定」を参照してください。
「Save」をクリックします。
動的クラスタのサーバー・テンプレートに対する同時制約の構成手順:
「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「サーバー・テンプレート」をクリックします。
「サーバー・テンプレートのサマリー」表で、サーバー・テンプレート・インスタンスを選択します。
「構成」→「同時実行性」タブを選択します。
「同時実行性」ページで、選択可能なオプションのいずれかまたは全部の値を指定します。
最大同時長時間リクエスト - 管理対象エグゼキュータ・サービスまたは管理対象スケジュール済エグゼキュータ・サービスに発行される同時長時間実行リクエストの制限。「最大同時長時間実行リクエストの制限の設定」を参照してください。
最大同時新規スレッド - 自己チューニング・スレッド・プールの外部で管理対象スレッド・ファクトリが作成する同時新規スレッドの最大数。「最大同時新規スレッドの制限の設定」を参照してください。
「Save」をクリックします。
同時制約は、ドメインの構成、指定のサーバー・インスタンス、および動的クラスタのサーバー・テンプレートで、メソッドDomainMBean、ServerMBean、ServerTemplateMBeanを使用してグローバルに構成できます。
maxConcurrentLongRunningRequests() – 「最大同時長時間実行リクエストの制限の設定」を参照してください。
maxConcurrentNewThreads() – 「最大同時新規スレッドの制限の設定」を参照してください。
WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。
グローバルCMOには、次の管理ツールを使用して問い合せることができます。
CMOは、DomainMBeanで次の実行時MBeanを使用して監視できます。
ManagedExecutorServiceRuntimeMBean
ManagedExecutorServiceRuntimeMBeanには、次のMBean属性からアクセスできます。
ApplicationRuntimeMBean.ManagedExecutorServiceRuntimes – 該当アプリケーションのすべての管理対象エグゼキュータ・サービスの統計を提供します。
ComponentRuntimeMBean.ManagedExecutorServiceRuntimes – 該当モジュールのすべての管理対象エグゼキュータ・サービスの統計を提供します。
Oracle WebLogic Server MBeanリファレンスのManagedExecutorServiceTemplateMBeanに関する項を参照してください
ManagedScheduledExecutorServiceRuntimeMBean
ManagedScheduledExecutorServiceRuntimeMBeanには、次のMBean属性からアクセスできます。
ApplicationRuntimeMBean.ManagedScheduledExecutorServiceRuntimes – 該当アプリケーションのすべての管理対象スケジュール済エグゼキュータ・サービスの統計を提供します。
ComponentRuntimeMBean.ManagedScheduledExecutorServiceRuntimes – 該当モジュールのすべての管理対象スケジュール済エグゼキュータ・サービスの統計を提供します。
Oracle WebLogic Server MBeanリファレンスのManagedScheduledExecutorServiceRuntimeMBeanに関する項を参照してください
ManagedThreadFactoryRuntimeMBean
ManagedThreadFactoryRuntimeMBeanには、次のMBean属性からアクセスできます。
ApplicationRuntimeMBean.ManagedThreadFactoryRuntimes – 該当アプリケーションのすべての管理対象スレッド・ファクトリの統計を提供します。
ComponentRuntimeMBean.ManagedThreadFactoryRuntimes – 該当モジュールのすべての管理対象スレッド・ファクトリの統計を提供します。
Oracle WebLogic Server MBeanリファレンスのManagedThreadFactoryRuntimeMBeanに関する項を参照してください
WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。
サーバーの同時制約は、次のMBean属性からアクセスできるConcurrentManagedObjectsRuntimeMBeanを使用して監視できます。
ServerRuntimeMBean.ConcurrentManagedObjectsRuntime – グローバル・ランタイムの同時管理対象オブジェクトで作成されるスレッドの統計を提供します。
『Oracle WebLogic Server MBeanリファレンス』のConcurrentManagedObjectsRuntimeMBeanに関する項を参照してください
WebLogic Server MBeanの使用の詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のJMXを使用したWebLogic Server MBeanへのアクセスに関する項を参照してください。
