| Oracle Containers for J2EEリソース・アダプタ管理者ガイド 10g（10.1.3.5.0） B56028-01 |
|
 戻る |
 次へ |
この章は次の構成になっており、J2CAのワーク管理規約の概説し、OC4Jのワーク管理スレッド・プール実装の使用方法を重点的に説明します。
この項では次の項目を含むJ2CAのワーク管理規約の基本的な要点を説明します。
一部のリソース・アダプタは比較的単純であり、受動的にシングル・アプリケーション・スレッドのコンテキストで実行しますが、標準的なリソース・アダプタはマルチタスキングであり、すべての務めを実行するために複数のスレッドを必要とします。これらの務めには、内部作業の実行やアプリケーション・コンポーネントのコールに加えて、ネットワークのエンドポイントをリスニングしたり、ネットワーク・ピアと通信したりすることが含まれます。
リソース・アダプタがそれ自身のスレッドを作成することは可能ですが、アプリケーション・サーバーはすべてのシステム・リソースを管理するように設計されており、ランタイム環境の全体の状態を認識しているので、アプリケーション・サーバーがかわりにスレッドを作成し、管理できるのは利点です。これはシステムの最適な効率性、管理性および安全性を保証する最善の方法です。（たとえば、アプリケーション・サーバーはすべてのデプロイされたリソース・アダプタによって共有されるスレッドのプールを維持する場合があります。）実際に、アプリケーション・サーバーはリソース・マネージャをスレッドの管理から開放する場合があります。
アプリケーション・サーバーとリソース・アダプタとの間にあるJ2CAのワーク管理規約の目的は、リソース・アダプタがアプリケーション・サーバーによって作成および管理されるスレッドを使用するメカニズムを提供することです。規約のもとで、リソース・アダプタはアプリケーション・サーバーによって実行されるために作業ユニットを発行し、アプリケーション・サーバーのワーク・マネージャはその管理のもとでスレッドを使用し作業を実行します。
J2CAワーク管理モデルを実装するインタフェースおよびクラスはjavax.resource.spi.workパッケージの中にあります。
リソース・アダプタはWorkインタフェースを実装し、そのインスタンスはリソース・アダプタがアプリケーション・サーバーによる処理のために発行する作業ユニットを表します。Workインタフェースはrun()メソッドを継承し、それによって作業を実行し、またrelease()メソッドを指定し、アプリケーション・サーバーはそれを使用して作業が即座に完了する必要があることを指定します。
OC4Jのようなアプリケーション・サーバーは、作業ユニットを管理するためにWorkManagerインタフェースを実装します。このインタフェースはメソッドを指定して作業を行い（作業が完了するまでブロックする）、作業を開始し（作業が開始されるまではブロックする）、作業をスケジュールします（作業ユニットの処理が受け入れられたら即座に戻る）。それぞれのメソッドはWorkインスタンスをインプットとします。doWork()メソッドは同期型の作業用であり、一方scheduleWork()メソッドは非同期型の作業用です。startWork()メソッドはファーストイン・ファーストアウト型の実行を保証しており、ワーク・マネージャは任意で作業ユニットの実行の受入れと開始の間の経過時間を把握することができます。
リソース・アダプタはアプリケーション・サーバーからWorkManagerインスタンスを取得し、達成のための作業ユニット用にWorkインスタンスを作成し、WorkManagerインスタンスが作業を行うためにいずれかのメソッドをコールするときにWorkインスタンスをWorkManagerインスタンスに渡します。オプションで、リソース・アダプタは次のものもまたWorkManagerメソッドのいずれかに渡します。
ExecutionContextインスタンスは、その中においてトランザクションおよびセキュリティ機能用といった作業ユニットを実行するコンテキストをモデルします。
WorkListenerインスタンスは、作業処理イベントが発生したときに通知されるコールバック・イベント・リスナーを提供します。通知メカニズムはアプリケーション・サーバーによってコールされるメソッドを含んでおり、作業が許容、拒否、開始または完了されたことを表します。
ワーク・マネージャは次の2つのタイプのワーク管理の例外をスローします。すなわち、発行されたWorkインスタンスは完了したが例外が発生したことを示すWorkCompletedExceptionまたは、発行されたWorkインスタンスが拒否されたことを示すWorkRejectedExceptionです。これらの例外は、非同期型の作業発行においては特に便利なWorkListenerメカニズムを通してワーク・マネージャからリソース・アダプタに渡されることも可能です。WorkListenerのメソッドであるworkAccepted()、workRejected()、workStarted()およびworkCompleted()はWorkEventインスタンスをインプットとして受け取ります。WorkEventインスタンスが作成されると、それはWorkインスタンスおよび適用可能な作業の例外インスタンスをインプットとして受け取ります。（WorkCompletedExceptionおよびWorkRejectedExceptionは、javax.resource.ResourceExceptionのサブクラスであるWorkExceptionのサブクラスです。）
アプリケーション・サーバーはワーク管理に使用されるスレッドのプールを維持します。Workインスタンスが発行されると、それは実行されるために空きスレッドによってピック・アップされます。スレッドは適切な実行コンテキストを設定し、作業を実行するためにrun()メソッドをコールします。作業が完了すると、アプリケーション・サーバーは自由にスレッドを再利用できます。あるいはロードの状況によっては、アプリケーション・サーバーは別のスレッドからスレッドの再要求を試みるためにいつでもWorkインスタンスのrelease()メソッドをコールします。このことはリソース・アダプタによるいかなるアクションも義務付けるものではありませんが、リソース・アダプタは作業を実行しているアクティブなスレッドを開放する必要があることの手がかりとなります。リソース・アダプタはスレッドを注意深く使用し、このような手がかりを監視してあらゆる適切なクリーンアップを実行する必要があります。
作業ユニットの実行に使用されるすべてのスレッドは同じ優先レベルである必要がありますが、それぞれのアプリケーション・サーバーは、独自のスレッド・プールの実装を提供します。
OC4Jは、デプロイされたリソース・アダプタによって特別に使用される構成可能なグローバル・スレッド・プールを提供します。続く項ではOC4Jの構成およびメトリック機能を説明します。
OC4Jは様々なタイプのスレッド・プールをサポートしますが、それらの1つは特別にワーク管理用のリソース・アダプタによって使用されます。ワーク管理スレッド・プールは他と独立して動作しますが、それぞれのプールは同じ基本的な機能のセットをサポートしており、次のものに対して構成可能です。
プールに存在する必要のあるスレッドの最小数
プールで同時に実行することのできるスレッドの最大数
スレッド待ちのキューの中に存在しうるリクエストの最大数
破棄されるまで、スレッドがリクエストに対してサービスが提供されるのを待機する存続時間（ミリ秒）
プール内のスレッドの数が最小数を下回る場合、OC4Jはキューにリクエストを入れずに新しいスレッドを追加します。そうでない場合は、OC4Jは新しいスレッドを追加しないでリクエストをキューに入れます。キューが一杯でないかぎり、一般的にOC4Jはスレッドの数を最小数か最小数近くに保とうとします。
OC4Jのスレッド・プールの詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
リソース・アダプタ・ワーク管理用のスレッド・プールを含むOC4Jスレッド・プールは、OC4Jのserver.xmlファイル内において、そのトップレベルの<application-server>要素のサブ要素を通して構成されます。ワーク管理スレッド・プールは、<work-manager-thread-pool>サブ要素またはApplication Server Controlを通して構成されます。
Application Server Controlコンソールで、次のようにシステムMBeanブラウザからアクセスしてワーク管理MBeanの属性を更新することができます。
OC4Jのホームページから「管理」タブを選択します。
「管理」タブの「JMX」の下から、「システムMBeanブラウザ」タスクに移動します。
システムMBeanブラウザでは、左にシステムMBeanのリストが示され、右に選択したMBeanの情報が示されます。
左のフレームのThreadPoolの下のWorkManager MBeanを選択します。たとえばWorkManager_0を選択します。
「属性」タブでは、ワーク管理スレッド・プールの属性が説明および値とともに一覧表示されます。RW（読取り/書込み）アクセスを持つ属性の値は編集できます。
変更を適用します。
|
注意:
|
あるいは、<application-server>のサブ要素である<work-manager-thread-pool>を使用してワーク管理スレッド・プールを構成することもできます。（他のOC4Jスレッド・プールは<global-thread-pool>要素を通して構成されます。）<work-manager-thread-pool>の属性は表5-1に示されています。
表5-1 ワーク管理スレッド・プール用の構成属性
| パラメータ | 説明 | デフォルト値 |
|---|---|---|
|
min |
プールに存在するスレッドの最小数です。 |
1 |
|
max |
プールで同時に実行するスレッドの最大数です。 |
|
|
queue |
スレッド待ちのキューの中のリクエスト（ |
0 |
|
keepAlive |
スレッドがリクエストに対してサービスが提供されるのを待機する存続時間（ミリ秒）。 |
600,000（10分） |
|
スレッド・プールの診断情報の出力フラグです。 |
false |
|
注意: WorkManagerスレッド・プールは、内部用に3つのワーク・マネージャ・スレッドを使用します。たとえば、max="16"を指定した場合、サービス・リクエストで使用できるのは13のワーク・インスタンス・スレッドのみです。同様に、maxの値が20である場合、17のインスタンスのみを使用できます。このように、必要な最大サイズに3を加えた値をmaxに設定する必要があります。 |
次の例は、デバッグ用フラグを有効にし、最低10のスレッド、最大100の実行中のスレッド、200リクエストのキュー・サイズ、60秒のキープ・アライブ・タイムのスレッド・プールを宣言しています。
<application-server ... >
...
<work-manager-thread-pool min="10" max="100" queue="200"
keepAlive="60000" debug="true" />
...
</application-server>
server.xmlファイルの中のOC4Jスレッド・プールの構成の詳細情報は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
リソース・アダプタ・ワーク管理スレッド・プール用のダイナミック・モニタリング・サービス（DMS）メトリックはDMS階層の/oc4j/WorkManagementPoolの下にあります。スレッド・プール用のメトリックには2つのカテゴリがあります。1つは表5-2に示すようなスレッド・プールの構成値を表しており、もう1つは表5-3に示すようなスレッド・プールの実行状態を表しています。
|
注意: DMSはOC4Jを含む多くのOracle Application Serverコンポーネントにパフォーマンス監視機能を追加しました。DMSの目的は、ユーザーがどのようなパフォーマンスに関する問題でも診断、分析およびデバッグできるように、組込みパフォーマンス測定を通して実行時の動作の情報を提供することです。DMSはこの情報を、ライブ・デプロイ中を含むどんなときでも使用できるパッケージの中に提供しています。データはHTTPを通して発行されブラウザによって表示されます。DMSの使用方法、利用できる組込みDMSメトリック、および他のOC4Jのパフォーマンスの検討事項の概要は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。 |
表5-2 ワーク管理スレッド・プール構成用のDMSメトリック
| メトリック | 説明 |
|---|---|
|
minPoolSize |
プールに存在するスレッドの最小数です。 |
|
maxPoolSize |
プールで同時に実行するスレッドの最大数です。 |
|
maxQueueSize |
スレッドのサービスを待つキューの中のリクエスト（ |
|
keepAlive |
スレッドがリクエストに対してサービスが提供されるのを待機する存続時間（ミリ秒）を示します。 |
表5-3 ワーク管理スレッド・プール状態用のDMSメトリック
| メトリック | 説明 |
|---|---|
|
totalThreadCount |
プールの中のスレッドの合計数です。 |
|
idleThreadCount |
リクエストのサービスを待っているプールの中のスレッドの数です。 |
|
queueSize |
キューの中でスレッドが利用可能になるのを待っているリクエスト（ |
|
queueFullEvent |
キューが一杯であるためリクエストが拒否された回数です。 |
|
workStartDuration |
リクエストが受け入れられたときと、作業を完了するためにスレッドが割り当てられたときとの間の経過時間を測定します。（スレッドがすぐに利用できる場合、これは利用可能なスレッドの検索と作業処理用の適切な実行コンテキストの設定における、スレッド・プールの処理のオーバーヘッドを測定します。利用可能なすべてのスレッドが他のリクエストの処理でビジーである場合、この時間はキューイングの時間も含みます。）最短期間、最長期間および平均期間の、3つの別々の値がこのメトリックに表されます。 |
次の例は、ワーク管理スレッド・プール用のサンプルのDMS出力です。
<statistics>
/oc4j [type=n/a]
/oc4j/Work_Management_Pool [type=oc4j_workManagementPool]
idleThreadCount.level: NOTIFICATION
idleThreadCount.value: 4 threads
keepAlive.level: NOTIFICATION
keepAlive.value: 600000 milliseconds
maxPoolSize.level: NOTIFICATION
maxPoolSize.value: 20 threads
maxQueueSize.level: NOTIFICATION
maxQueueSize.value: 50 work_requests
minPoolSize.level: NOTIFICATION
minPoolSize.value: 5 threads
queueFullEvent.count: 0 ops
queueFullEvent.level: NOTIFICATION
queueSize.level: NOTIFICATION
queueSize.value: 0 work_requests
totalThreadCount.level: NOTIFICATION
totalThreadCount.value: 5 threads
workStartDuration.avg: 6.900943396226415 msecs
workStartDuration.completed: 424 ops
workStartDuration.level: NOTIFICATION
workStartDuration.maxTime: 34 msecs
workStartDuration.minTime: 0 msecs
workStartDuration.time: 2926 msecs
</statistics>
