|
|
WebLogic Server では、アプリケーションがどのような優先順位で作業を実行するかをコンフィグレーションできます。ユーザが定義したルールと実際の実行時パフォーマンスのモニタ結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス レベル アグリーメントが維持されます。アプリケーションに適用するルールや制約を定義するには、ワーク マネージャを定義し、これを WebLogic Server ドメインにグローバルに適用するか、特定のアプリケーション コンポーネントに適用します。
以前のバージョンの WebLogic Server では、複数の実行キューで処理を実行していました。クラスの異なる作業を優先順位や順序の要件に基づいて別々のキューで実行することで、デッドロックを回避していました。デフォルトの実行キュー (weblogic.kernel.default) に加え、内部管理トラフィック専用にあらかじめコンフィグレーションされたキュー (weblogic.admin.HTTP、weblogic.admin.RMI など) がありました。
ユーザは、デフォルト キューのスレッドの数を変更することでスレッドの使用状況を制御したり、特定のアプリケーションが全体のシステム負荷に関係なく一定数のスレッドにアクセスできるようカスタム実行キューをコンフィグレーションしたりできました。
WebLogic Server では、1 つのスレッド プールですべてのタイプの作業を実行します。作業の優先順位は、ユーザが定義するルールと実行時のメトリックに基づいて決定されます。メトリックとしては、実際に要求を実行するのにかかった時間、要求をプールに出し入れする割合、などがあります。
共通スレッド プールのサイズは、スループットが最大になるように自動的に変更されます。キューは、スループットを長期間にわたってモニタし、その履歴に基づいてスレッド数を調整するかどうかを決定します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、スレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、スレッド数が自動的に減らされます。この新しい方式により、管理者は、カスタムの実行キューをコンフィグレーション、モニタ、チューニングする際の手間や複雑さを避けて、より簡単に処理リソースを割り当てたり、パフォーマンスを管理したりできるようになりました。
WebLogic Server では、管理者が定義したパラメータと実行時の実際のパフォーマンスおよびスループットを考慮にいれた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。
管理者は、一連のスケジューリング ガイドラインをコンフィグレーションし、それらを 1 つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション コンポーネントに関連付けたりできます。たとえば、スケジューリング ガイドラインのセットを 1 つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、これらのガイドラインに基づいて、保留中の作業やキューに入っている要求が実行スレッドに割り当てられます。
アプリケーション内の作業を管理するには、以下のうち 1 つまたは複数のワーク マネージャ コンポーネントを定義します。
これらのコンポーネントの詳細については、「要求クラス」または「制約」を参照してください。
これらのコンポーネントを使用してアプリケーションのパフォーマンスを制御するには、アプリケーションのデプロイメント記述子でコンポーネントの名前を参照します。また、これらすべてのコンポーネント (コンテキスト要求クラスを除く。「コンテキスト要求クラス」を参照) をカプセル化したワーク マネージャを定義し、このワーク マネージャの名前をアプリケーションのデプロイメント記述子で参照することもできます。複数のワーク マネージャを定義することも可能です。ワーク マネージャの適正数は、WebLogic Server でホストするアプリケーション全体でいくつの個別要求プロファイルが存在するかによって異なります。
ワーク マネージャは、次のいずれかのコンフィグレーション ファイルを使用して、ドメイン レベル、アプリケーション レベル、およびモジュール レベルでコンフィグレーションできます。
config.xml - config.xml で指定したワーク マネージャは、ドメイン内のアプリケーションまたはアプリケーション コンポーネントに関連付けることができます。ワーク マネージャは、Administration Console を使用して定義できます。weblogic-application.xml - アプリケーション レベルで指定したワーク マネージャは、そのアプリケーション、またはそのアプリケーションのコンポーネントに関連付けることができます。weblogic-ejb-jar.xml または weblogic.xml - コンポーネント レベルで指定したワーク マネージャは、そのコンポーネントに関連付けることができます。 weblogic.xml - Web アプリケーション用のワーク マネージャを指定できます。
コード リスト 2-1 に、ワーク マネージャの定義の例を示します。
<work-manager>
<name>highpriority_workmanager</name>
<fair-share-request-class>
<name>high_priority</name>
<fair-share>100</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>MinThreadsCountFive</name>
<count>5</count>
</work-manager>
コード リスト 2-1 の例で使用されているワーク マネージャを Web アプリケーションのディスパッチ ポリシーで参照するには、コード リスト 2-2 のコードを Web アプリケーションの web.xml ファイルに追加します。
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>highpriority_workmanager</param-value>
</init-param>
ワーク マネージャで定義および使用できるコンポーネントについては、以降の節で説明します。
要求クラスは、要求へのスレッドの割り当てに使用するスケジューリング ガイドラインを表現します。要求クラスを使用すると、優先順位の高い作業が優先順位の低い作業より後に送信された場合でも、優先順位の高い作業を優先順位の低い作業より前にスケジューリングすることができます。WebLogic Server では、各モジュールが要求を完了するのにかかる時間が考慮されます。
要求クラスにはいくつかのタイプがあり、それぞれ条件の異なったスケジューリング ガイドラインを表現します。1 つのワーク マネージャに、要求クラスを 1 つだけ指定することもできます。
fair-share-request-class - 要求の処理に必要な平均スレッド使用時間を指定します。
たとえば、WebLogic Server で 2 つのモジュールを実行しているとします。ModuleA のワーク マネージャでは fair-share-request-class が 80 に設定されており、ModuleB のワーク マネージャでは fair-share-request-class が 20 に設定されています。
各モジュールで切れ目なく要求を処理している状態 (つまり、要求数がスレッドの数を超えている状態) が続く間は、スレッド使用時間の 80% が ModuleA に、20% が ModuleB に割り当てられます。
| 注意 : | フェアシェア要求クラスの値は、割合ではなく相対値で指定します。したがって、上の例で要求クラスを 400 と 100 に設定しても相対値としては同じです。 |
たとえば、前の例のように ModuleA と ModuleB があり、応答時間の目標値がそれぞれ 2000 ミリ秒と 5000 ミリ秒に設定されており、個々の要求の実際のスレッド使用時間が応答時間の目標値よりも短いとします。応答と要求の間に「思考時間」による遅延がないとすると、各モジュールで切れ目なく要求を処理している状態 (つまり、要求数がスレッドの数を超えている状態) が続く間は、ModuleA と ModuleB に対する要求は平均応答時間が 2 対 5 の割合になるようにスケジューリングされます。ModuleA と ModuleB の実際の平均応答時間は応答時間の目標値より長くなったり短くなったりしますが、設定されている目標値の常分数または倍数になります。たとえば、ModuleA の要求の平均応答時間が 1,000 ミリ秒である場合、ModuleB の要求の平均応答時間は 2,500 ミリ秒になります。
context-request-class - このタイプの要求クラスは、コンテキスト情報 (現在のユーザ、現在のユーザのグループなど) に基づいて要求クラスを要求に割り当てます。
たとえば、「コンテキスト要求クラス」の context-request-class では、要求の subject および role プロパティの値に基づいて要求クラスが要求に割り当てられます。
コンテキスト要求クラスを使用すると、アプリケーションのデプロイメント記述子で、ユーザのコンテキストに基づいて要求クラスを定義できます。次に例を示します。
<work-manager>
<name>responsetime_workmanager</name>
<response-time-request-class>
<name>my_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
</work-manager>
<work-manager>
<name>context_workmanager</name>
<context-request-class>
<name>test_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>
この例では、同じ要求クラスを使用して別の作業にスケジューリングを関連付けることで、フェア シェアと応答時間に基づいた要求クラスを説明しています。フェア シェア要求クラスと応答時間要求クラスを併用すると、応答時間スケジューリングに著しく偏ったスケジューリングになります。
制約を使用すると、要求を実行するために割り当てられるスレッドの最小数と最大数、および WebLogic Server が要求を拒否し始めるまでにキューに入れたり実行したりできる要求の総数を定義できます。
max-threads-constraint - この制約は、制約対象の作業セットからの要求を実行する同時スレッドの数を制限します。デフォルトは無制限です。たとえば、最大スレッド数が 10 に定義された制約を 3 つのエントリ ポイントで共有するとします。このスケジューリング ロジックでは、3 つのエントリ ポイントからの要求を 10 個以下のスレッドで実行します。
max-threads-constraint は、要求が依存するリソース (たとえば接続プール) の可用性の観点から定義できます。
max-threads-constraint は、要求クラスによるスレッドのフェア シェアの実現や応答時間の目標値の達成を妨げることがあります。いったん制約条件が満たされると、同時実行の数が制限値を下回るまで、このタイプの要求はスケジューリングされません。制限値を下回ると、フェア シェアまたは応答時間の目標値に基づいて作業がスケジューリングされます。
min-threads-constraint - この制約は、制約対象の要求に割り当てられるスレッドの数を保証することでデッドロックを回避します。デフォルトはゼロです。min-threads-constraint の値を 1 に設定すると、ピアから同期的に呼び出されるレプリケーション更新要求などの場合に便利です。
min-threads-constraint によってフェア シェアが向上するとは限りません。このタイプの制約は、主にサーバ インスタンスがデッドロック状態に近づいたときに効果を発揮します。しかし、このような場合は、最近サービス クラス内の要求がフェア シェアを超えていた場合でも、この制約によって要求がスケジューリングされます。
capacity - この制約を設定すると、サーバは容量に達したときにのみ要求を拒否します。デフォルトは 1。容量には、制約対象の作業セットからの全リクエスト (キューにあるリクエストと実行中のリクエスト) が含まれる。個々の容量しきい値を超えた場合、またはグローバル容量を超えた場合に作業が拒否されます。
スタック スレッドに応じて、スタック スレッド ワーク マネージャ コンポーネントを定義できます。このコンポーネントを使用すると、ワーク マネージャを停止したり、アプリケーションを管理モードにしたり、サーバ インスタンスを障害が発生したものとしてマークしたりできます。
たとえば、コード リスト 2-4 で定義するワーク マネージャは、2 つのスレッドが 30 秒を超えてスタックすると停止します。
<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
基本的に、ワーク マネージャには 3 つのタイプがあります。各タイプは、スコープおよび定義と使用のされ方によって特徴付けられます。この 3 つのタイプは、以下のとおりです。
これら 3 タイプのワーク マネージャについて、以下の節で説明します。
スレッド管理を処理し、自動チューニングを実行するため、WebLogic Server ではデフォルトのワーク マネージャが実装されています。このワーク マネージャは、アプリケーションのデプロイメント記述子で他のワーク マネージャが指定されていない場合に、アプリケーションによって使用されます。
多くの状況下において、デフォルトのワーク マネージャはほとんどのアプリケーション要件を十分に満たしていると考えられます。WebLogic Server のスレッド処理アルゴリズムは、デフォルトで各アプリケーションに、そのアプリケーション自身のフェア シェアを割り当てます。各アプリケーションは、スレッドに対して同等の優先順位を与えられており、スレッドを独占することはできないようになっています。
デフォルトのワーク マネージャの動作をオーバーライドするには、default というグローバル ワーク マネージャを作成およびコンフィグレーションします。これにより、WebLogic Server のデフォルトのスレッド処理動作を制御できます。
以下は、ワーク マネージャを使用してスレッド管理のカスタマイズをする必要がある場合を判断するためのガイドラインです。
サーバにデプロイされているすべてのアプリケーションおよびモジュールで使用できるワーク マネージャを作成できます。グローバル ワーク マネージャは、WebLogic Server Administration Console で作成され、config.xml に定義されます。
アプリケーションは、グローバルに定義されたワーク マネージャをテンプレートとして使用します。各アプリケーションは、そのアプリケーションと関連付けられた作業を処理する、自身のインスタンスを作成し、その作業を他のアプリケーションから分離します。そうすることで、同じディスパッチ ポリシーを使用している 2 つのアプリケーションに向かうトラフィックを処理できます。各アプリケーションの作業を別個に処理することで、別のアプリケーションのスレッド管理に影響を及ぼすことなく、アプリケーションを停止できます。各アプリケーションには、専用のワーク マネージャ インスタンスが実装されていますが、基底となるコンポーネントは共有されます。
グローバル スコープのワーク マネージャに加えて、特定のアプリケーションまたはモジュールのみで使用できるワーク マネージャを作成することもできます。ワーク マネージャは、以下の記述子で指定できます。
ワーク マネージャが明示的に割り当てられていないアプリケーションでは、デフォルトのワーク マネージャが使用されます。
ワーク マネージャにメソッドを割り当てるには、デプロイメント記述子で <dispatch-policy> 要素を使用します。下位互換性を維持するため、<dispatch-policy> でカスタム実行キューも指定できるようになっています。例については、コード リスト 2-2 を参照してください。
ワーク マネージャ、要求クラス、および制約では、以下が必要になります。
weblogic-ejb-jar.xml - weblogic-enterprise-bean の既存の dispatch-policy タグの値は、名前付きの dispatch-policy であってもかまいません。下位互換性のため、ExecuteQueue を指定することもできます。また、現在の isolation-level タグのように、dispatch-policy、max-threads、または min-threads を使用して、メソッドのリストに名前付きの (または制約が数値で名前がない) ポリシーおよび制約を指定することも可能です。
weblogic.xml - web.xml の filter-mapping と同様のマッピングもサポートされています。名前付きの dispatch-policy、max-threads、または min-threads が、url-pattern またはサーブレット名にマッピングされます。
この節では、さまざまなデプロイメント記述子を使用したワーク マネージャの定義例を示します。
必要に応じて、各デプロイメント記述子のスキーマも参照してください。
<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>WorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name>
<dispatch-policy>weblogic.kernel.System</dispatch-policy>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>NonSystemWorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_NonSystemWorkEJB</jndi-name>
<dispatch-policy>workbean_workmanager</dispatch-policy>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>MinThreadsWorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_MinThreadsWorkEJB</jndi-name>
<dispatch-policy>MinThreadsCountFive</dispatch-policy>
</weblogic-enterprise-bean>
<work-manager>
<name>workbean_workmanager</name>
</work-manager>
<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
<work-manager>
<name>minthreads_workmanager</name>
<min-threads-constraint>
<name>MinThreadsCountFive</name>
<count>5</count>
</min-threads-constraint>
</work-manager>
<work-manager>
<name>lowpriority_workmanager</name>
<fair-share-request-class>
<name>low_priority</name>
<fair-share>10</fair-share>
</fair-share-request-class>
</work-manager>
<work-manager>
<name>highpriority_workmanager</name>
<fair-share-request-class>
<name>high_priority</name>
<fair-share>100</fair-share>
</fair-share-request-class>
</work-manager>
<work-manager>
<name>veryhighpriority_workmanager</name>
<fair-share-request-class>
<name>veryhigh_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
</work-manager>
これらの EJB は、依存するリソース (接続プールおよびアプリケーション スコープの接続プール) のインスタンスが存在する限り、なるべく多くのスレッドを取得するようにコンフィグレーションされています。
</weblogic-ejb-jar>
<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>ResourceConstraintEJB</ejb-name>
<jndi-name>core_work_ejb_resource_ResourceConstraintEJB</jndi-name>
<dispatch-policy>test_resource</dispatch-policy>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>AppScopedResourceConstraintEJB</ejb-name>
<jndi-name>core_work_ejb_resource_AppScopedResourceConstraintEJB
</jndi-name>
<dispatch-policy>test_appscoped_resource</dispatch-policy>
</weblogic-enterprise-bean>
<work-manager>
<name>test_resource</name>
<max-threads-constraint>
<name>pool_constraint</name>
<pool-name>testPool</pool-name>
</max-threads-constraint>
</work-manager>
<work-manager>
<name>test_appscoped_resource</name>
<max-threads-constraint>
<name>appscoped_pool_constraint</name>
<pool-name>AppScopedDataSource</pool-name>
</max-threads-constraint>
</work-manager>
</weblogic-ejb-jar>
CommonJ の使い方については、「WebLogic Server での CommonJ の使い方」および CommonJ の Javadoc を参照してください。
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-application.xsd">
<max-threads-constraint>
<name>j2ee_maxthreads</name>
<count>1</count>
</max-threads-constraint>
<min-threads-constraint>
<name>j2ee_minthreads</name>
count>1</count>
</min-threads-constraint>
<work-manager>
<name>J2EEScopedWorkManager</name>
</work-manager>
</weblogic-application>
この Web アプリケーションは、コード リスト 2-8 で定義したエンタープライズ アプリケーションの一部としてデプロイされます。この Web アプリケーションの記述子では、2 つのワーク マネージャを定義しています。どちらのワーク マネージャも、アプリケーションの weblogic-application.xml ファイルで定義した同じ最大スレッド数制約 (j2ee_maxthreads) を参照しています。応答時間要求クラスは、ワーク マネージャごとに異なっています。
<weblogic xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic.xsd">
<work-manager>
<name>fast_response_time</name>
<response-time-request-class>
<name>fast_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
<max-threads-constraint-name>j2ee_maxthreads
</max-threads-constraint-name>
</work-manager>
<work-manager>
<name>slow_response_time</name>
<max-threads-constraint-name>j2ee_maxthreads
</max-threads-constraint-name
<response-time-request-class>
<name>slow_response_time</name>
<goal-ms>5000</goal-ms>
</response-time-request-class>
</work-manager>
</weblogic>
この記述子では、context-request-class を使用してワーク マネージャを定義しています。
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
<work-manager>
<name>foo-servlet-1</name>
<request-class-name>test-fairshare2</request-class-name>
<max-threads-constraint>
<name>foo-mtc</name>
<pool-name>oraclePool</pool-name>
</max-threads-constraint>
</work-manager>
<work-manager>
<name>foo-servlet</name>
<context-request-class>
<name>test-context</name>
<context-case>
<user-name>anonymous</user-name>
<request-class-name>test-fairshare1</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>test-fairshare2</request-class-name>
</context-case>
</context-request-class>
</work-manager>
</weblogic-web-app>
この節では、実行キューとの下位互換性を有効にし、実行キューの代わりにワーク マネージャを使用するようアプリケーションを移行する方法について、説明します。
WebLogic Server バージョン 8.1 では、スレッド管理の処理のために実行キューを実装していました。実行キューを使用すると、スレッド プールを作成して、作業負荷の処理方法を決定できました。WebLogic Server は、引き続き下位互換性のために実行キューを提供しています。これは主に、アプリケーションの移行を支援するためです。ただし、新しいアプリケーションを開発する際には、ワーク マネージャを利用して、より効率的にスレッド管理を行うことが必要です。
実行キューを有効化すると、すべてのワーク マネージャのコンフィグレーションとスレッドの自動チューニングが無効化されます。実行キューは、WebLogic Server 8.1 で動作したときとまったく同じように動作します。詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「ユーザ定義の実行キューの使用」を参照してください。
有効化されたワーク マネージャは、以下のルールに基づき、実行キューに変換されます。
アプリケーションが WebLogic Server 8.1 から移行される場合、移行より前にサーバ コンフィグレーションで定義された実行キューはすべて、そのまま存続します。実行キューのワーク マネージャへの変換は自動的に行われるわけではありません。
WebLogic Server 9.x に、実行キューを実装した 8.1 アプリケーションがデプロイされると、実行キューが作成され、要求に応じてスレッド管理の処理に使用されます。しかし、この機能が活用されるのは、ディスパッチ ポリシーが実行キューにマップされる要求においてのみです。
ワーク マネージャには、WorkManagerMBean コンフィグレーション MBean を使用してアクセスすることができます。詳細については、「WorkManagerMBean」を参照してください。
WorkManagerMBean へは、アプリケーションのワーク マネージャへのアクセス方法に応じて、実行時ツリーまたはコンフィグレーション ツリーでアクセスします。
WebLogic Server ワーク マネージャでは、管理者がサーブレットおよび EJB に対してディスパッチ ポリシーを設定できるよう、サーバ レベルのコンフィグレーションを提供しています。
WebLogic Server はまた、アプリケーション内からプログラム的に作業を処理するための方法も用意しています。これは、CommonJ API を通じて提供されます。Weblogic Server は、CommonJ 仕様の commonj.work パッケージおよび commonj.timers パッケージを実装しています。
CommonJ 仕様の全般的な情報については、http://www.beasys.co.jp/dev2dev/technologies/commonj/index.html を参照してください。WebLogic Server における CommonJ の実装に関する特定的な情報については、CommonJ の Javadoc を参照してください。
CommonJ の WebLogic Server 実装を使用すると、アプリケーションは、WebLogic Server でコンフィグレーション済みの複数のワーク マネージャを使用して、1 つの要求のタスクを複数の作業項目に分割し、その作業項目を割り当てて、同時に実行することができます。作業項目を同時に実行する必要のないアプリケーションでも、コンフィグレーション済みのワーク マネージャを使用することができます。それには、デプロイメント記述子でワーク マネージャを参照または作成するか、J2EE コネクタの場合は JCA API を使用します。
WebLogic Server 実装と CommonJ 仕様の相違点をいくつか、以下に示します。
java.util.Timer とは異なる。WebLogic CommonJ タイマーは、実行が所定期間の 2 倍を超えると、それ以上の遅延を防止するため、いくらかの期間をスキップします。java.util.Timer は、このような処理を行いません。
WebLogic Server ワーク マネージャにアプリケーションからアクセスするにはディスパッチ ポリシーを使用する必要がありますが、CommonJ ワーク マネージャはアプリケーションから直接アクセスできます。次のコード例に、JNDI を使用して CommonJ ワーク マネージャをルックアップする方法を示します。
InitialContext ic = new InitialContext();
commonj.work.WorkManager wm = (WorkManager);
ic.lookup(`java:comp/env/wm/myWM');
CommonJ ワーク マネージャの使い方の詳細については、CommonJ の Javadoc を参照してください。
外部定義した CommonJ ワーク マネージャは、WebLogic Server ワーク マネージャにマッピングできます。たとえば、次の例のように、記述子 ejb-jar.xml で定義した CommonJ ワーク マネージャがあるとします。
<resource-ref>
<res-ref-name>minthreads_workmanager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
これを WebLogic Server ワーク マネージャにリンクさせるには、WebLogic Server の記述子 (たとえば weblogic-ejb-jar.xml) の name 要素を完全に一致させます。
<work-manager>
<name>minthreads_workmanager</name>
<min-threads-constraint>
<count>5</count>
</min-threads-constraint>
</work-manager>
この手順は、web.xml に定義した resource-ref と同様です。WebLogic Server ワーク マネージャは、モジュール記述子 (たとえば weblogic-ejb-jar.xml や weblogic.xml) またはアプリケーション記述子 (weblogic-application.xml) で定義できます。
  
|
