ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 9.1 ドキュメント > WebLogic Server 環境のコンフィグレーション > ワーク マネージャを使用したスケジューリング済み作業の最適化

WebLogic Server 環境のコンフィグレーション

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

ワーク マネージャを使用したスケジューリング済み作業の最適化

WebLogic Server では、アプリケーションがどのような優先順位で作業を実行するかをコンフィグレーションできます。ユーザが定義したルールと実際の実行時パフォーマンスのモニタ結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス レベル アグリーメントが維持されます。アプリケーションに適用するルールや制約を定義するには、ワーク マネージャを定義し、これを 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 でホストするアプリケーション全体でいくつの個別要求プロファイルが存在するかによって異なります。

ワーク マネージャは、次のいずれかのコンフィグレーション ファイルを使用して、ドメイン レベル、アプリケーション レベル、およびモジュール レベルでコンフィグレーションできます。

コード リスト 2-1 に、ワーク マネージャの定義の例を示します。

コード リスト 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 ファイルに追加します。

コード リスト 2-2 Web アプリケーションでのワーク マネージャの参照

<init-param>
   <param-name>wl-dispatch-policy</param-name>
   <param-value>highpriority_workmanager</param-value>
</init-param>

ワーク マネージャで定義および使用できるコンポーネントについては、以降の節で説明します。

要求クラス

要求クラスは、要求へのスレッドの割り当てに使用するスケジューリング ガイドラインを表現します。要求クラスを使用すると、優先順位の高い作業が優先順位の低い作業より後に送信された場合でも、優先順位の高い作業を優先順位の低い作業より前にスケジューリングすることができます。WebLogic Server では、各モジュールが要求を完了するのにかかる時間が考慮されます。

要求クラスにはいくつかのタイプがあり、それぞれ条件の異なったスケジューリング ガイドラインを表現します。1 つのワーク マネージャに、要求クラスを 1 つだけ指定することもできます。

コンテキスト要求クラス

コンテキスト要求クラスを使用すると、アプリケーションのデプロイメント記述子で、ユーザのコンテキストに基づいて要求クラスを定義できます。次に例を示します。

コード リスト 2-3 コンテキスト要求クラス

<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 が要求を拒否し始めるまでにキューに入れたり実行したりできる要求の総数を定義できます。

以下のタイプの制約を定義できます。

スタック スレッドの処理

スタック スレッドに応じて、スタック スレッド ワーク マネージャ コンポーネントを定義できます。このコンポーネントを使用すると、ワーク マネージャを停止したり、アプリケーションを管理モードにしたり、サーバ インスタンスを障害が発生したものとしてマークしたりできます。

たとえば、コード リスト 2-4 で定義するワーク マネージャは、2 つのスレッドが 30 秒を超えてスタックすると停止します。

コード リスト 2-4 スタック スレッド ワーク マネージャ

<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 で作成されます。

アプリケーションは、グローバルに定義されたワーク マネージャをテンプレートとして使用します。各アプリケーションは、そのアプリケーションと関連付けられた作業を処理する、自身のインスタンスを作成し、その作業を他のアプリケーションから分離します。そうすることで、同じディスパッチ ポリシーを使用している 2 つのアプリケーションに向かうトラフィックを処理できます。各アプリケーションの作業を別個に処理することで、別のアプリケーションのスレッド管理に影響を及ぼすことなく、アプリケーションを停止できます。各アプリケーションには、専用のワーク マネージャ インスタンスが実装されていますが、基底となるコンポーネントは共有されます。

アプリケーション スコープのワーク マネージャ

グローバル スコープのワーク マネージャに加えて、特定のアプリケーションまたはモジュールのみで使用できるワーク マネージャを作成することもできます。ワーク マネージャは、以下の記述子で指定できます。

ワーク マネージャが明示的に割り当てられていないアプリケーションでは、デフォルトのワーク マネージャが使用されます。

ワーク マネージャにメソッドを割り当てるには、デプロイメント記述子で <dispatch-policy> 要素を使用します。下位互換性を維持するため、<dispatch-policy> でカスタム実行キューも指定できるようになっています。例については、コード リスト 2-2 を参照してください。

 

ワーク マネージャ、要求クラス、および制約の使い方

ワーク マネージャ、要求クラス、および制約では、以下が必要になります。

EJB のディスパッチ ポリシー

weblogic-ejb-jar.xml—weblogic-enterprise-bean の既存の dispatch-policy タグの値は、名前付きの dispatch-policy にできます。下位互換性のため、ExecuteQueue を指定することもできます。また、現在の isolation-level タグのように、dispatch-policy、max-threads、または min-threads を使用して、メソッドのリストに名前付きの (または制約が数値で名前がない) ポリシーおよび制約を指定することも可能です。

Web アプリケーションのディスパッチ ポリシー

weblogic.xml—web.xml の filter-mapping と同様のマッピングもサポートされています。名前付きの dispatch-policy、max-threads、または min-threads が、url-pattern またはサーブレット名にマッピングされます。

 

デプロイメント記述子の例

この節では、さまざまなデプロイメント記述子を使用したワーク マネージャの定義例を示します。

必要に応じて、各デプロイメント記述子のスキーマも参照してください。

コード リスト 2-5 ワーク マネージャのエントリを含む weblogic-ejb-jar.xml

<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>

コード リスト 2-6 接続プール ベースの最大スレッド数制約を含む weblogic-ejb-jar.xml

これらの 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>

コード リスト 2-7 CommonJ ワーク マネージャを含む weblogic-ejb-jar.xml

CommonJ の使い方については、「WebLogic Server での CommonJ の使い方」および CommonJ の Javadoc を参照してください。

コード リスト 2-8 weblogic-application.xml

<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>

コード リスト 2-9 Web アプリケーション記述子

この 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>

コード リスト 2-10 Web アプリケーション記述子

この記述子では、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 アプリケーションがデプロイされると、実行キューが作成され、要求に応じてスレッド管理の処理に使用されます。しかし、この機能が活用されるのは、ディスパッチ ポリシーが実行キューにマップされる要求においてのみです。

 

MBean を使用してのワーク マネージャへのアクセス

ワーク マネージャには、WorkManagerMBean コンフィグレーション MBean を使用してアクセスすることができます。詳細については、WorkManagerMBean を参照してください。

WorkManagerMBean へは、アプリケーションのワーク マネージャへのアクセス方法に応じて、実行時ツリーまたはコンフィグレーション ツリーでアクセスします。

 

WebLogic Server での CommonJ の使い方

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 仕様の相違点をいくつか、以下に示します。

CommonJ ワーク マネージャへのアクセス

WebLogic Server ワーク マネージャにアプリケーションからアクセスするにはディスパッチ ポリシーを使用する必要がありますが、CommonJ ワーク マネージャはアプリケーションから直接アクセスできます。次のコード例に、JNDI を使用して CommonJ ワーク マネージャをルックアップする方法を示します。

InitialContext ic = new InitialContext();
commonj.work.WorkManager wm = (WorkManager);
ic.lookup(`java:comp/env/wm/myWM');

CommonJ ワーク マネージャの使い方の詳細については、CommonJ の Javadoc を参照してください。

WebLogic Server ワーク マネージャへの CommonJ のマッピング

外部定義した 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) で定義できます。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次