WebLogic Server 9.0におけるワークロード（作業負荷）管理
Pages: 1, 2, 3, 4, 5

WebLogicワークマネージャのコンフィグレーション

自分のアプリケーション用にワークマネージャを設定する方法について説明する前に、デフォルトのコンフィグレーションが十分良くできていることを 知っておいてください。先に述べたように、各アプリケーションは、デフォルトのフェアシェアを持つ固有のワークマネージャを持ちます。これは、すべてのア プリケーションが同じ重要度で扱われるので、アプリケーションがスレッドを占有することはできないことを意味します。以下のような理由がある場合は、ワー クマネージャを設定して、デフォルト値をオーバーライドする要求に関連付けることができます。

  1. デフォルトのフェアシェアが十分でない。
  2. 応答時間目標を指定する必要がある。
  3. サーバ間にデッドロックが生じる可能性があるため、最小スレッド制約を指定する必要がある。
  4. 要求が共通のJDBC接続プールによって制限されるため、最大スレッド制約を指定する必要がある。

ワークマネージャを設定する際のガイドラインを以下に示します。

  1. ワークマネージャを weblogic-application.xmlで定義することにより、ワークマネージャにアプリケーションスコープを持たせることができます。ワークマネージャのコンフィグレーションをアプリケーションのそばに置いておくと、移植の際に役立ちます。
  2. 要求クラスや制約などのワークマネージャ内のコンポーネントを、他のワークマネージャと共有すべきかどうかを決定します。共有する場合は、共有す るコンポーネントを、ワークマネージャの外部で独立に宣言する必要があります。それ以外の場合は、コンポーネントを、排他的なアクセスを提供するワークマ ネージャの内部で宣言できます。
  3. WebLogic Serverの管理コンソールには、ワークマネージャとその他の関連コンポーネントを設定するための画面があります。管理コンソールを使って作成されたワークマネージャは、サーバ全体で利用できます。

先に述べたように、ワークマネージャは、アプリケーションスコープを持たせるか、またはグローバルに定義できます。ワークマネージャからは、要求クラスや制約など独立に定義されたコンポーネントを名前で参照できます。名前解決は、以下のように処理されます。

  1. アプリケーション内に要求クラスや制約が見つかった場合は、それがピックアップされます。
  2. 1.に失敗した場合は、サーバレベルのコンポーネントを検索します。
  3. 2.に失敗した場合、要求クラスが決まっていれば、排他的なデフォルトのフェアシェア要求クラスが作成されます。制約や容量に対しては、null 値が戻ります。つまり、このワークマネージャには、同時実行スレッド数や、キューに入れることができる要求の数に上限がありません。

ワークマネージャコンポーネントを参照する際に使われる名前は、デプロイメント記述子で定義されている名前です。JNDIの名前ではない点に注意してください。アプリケーション内に定義されるワークマネージャのコンフィグレーション例を以下に示します。

<weblogic-application>
  ...  
  <max-threads-constraint>
    <name>MyConstraint</name>
    <pool-name>MyDataSource</pool-name>
  </max-threads-constraint>
  ...
  <work-manager>
    <name>MyAppScopedWorkManager-1</name>
    <fair-share-request-class>
      <name>high_fairshare</name>
      <fair-share>80</fair-share>
    </fair-share-request-class>
    <max-threads-constraint-name>MyConstraint
                            </max-threads-constraint-name>
  </work-manager>
    <work-manager>
    <name>MyAppScopedWorkManager-2</name>
    <fair-share-request-class>
    <name>high_fairshare</name>
    <fair-share>20</fair-share>
    </fair-share-request-class>
    <max-threads-constraint-name>MyConstraint
                           </max-threads-constraint-name>
  </work-manager>
  ...
</weblogic-application>

2つのワークマネージャが、どのようにして同じ最大スレッド制約を共有しているかに注目してください。最大スレッド制約は名前で参照されています。

ディスパッチポリシーの設定

ワークマネージャの設定について見てきましたので、ここからは、ワークマネージャを要求とリンクする方法について見ていきましょう。それには、ディ スパッチポリシーを定義します。サーブレットの場合は、dispatch-policy初期化パラメータを設定することによって、ディスパッチポリシーを 定義できます。EJBの場合は、以前のリリースでも存在していた dispatch-policy要素を使わなければなりません。以前のリリースでは、ディスパッチポリシーは実行キューの名前を参照していました。WebLogic Server 9.0では、同じ dispatch-policy要素を、ワークマネージャを参照するために使います。ディスパッチポリシーの解決は以下のように行われます。

  1. dispatch-policy名を持つワークマネージャが、同じアプリケーション内に見つかった場合は、それが使われます。
  2. 1.に失敗した場合は、サーバレベルで一致するワークマネージャが検索されます。
  3. 2.に失敗した場合は、サーバログに警告メッセージが出力され、そのアプリケーションのデフォルトのワークマネージャが使われます。

web.xmlのサーブレット内でディスパッチポリシーを設定する方法を以下に示します。 

<web-app>
  <servlet>
    <servlet-name>WorkServlet</servlet-name>
    <servlet-class>workservlet.WorkServlet</servlet-class>
    <init-param>
  
                          
     <param-name>wl-dispatch-policy</param-name>
      <param-value>MyAppScopedWorkManager-1</param-value>
    </init-param>
  </servlet>
</web-app>

このコンフィグレーションは、 WorkServlet呼び出しすべてにおいて、 MyAppScopedWorkManager-1ワークマネージャを使用しなければならないことを意味しています。

weblogic-ejb-jar.xmlでの dispatch-policy要素の使用例を以下に示します。 

<weblogic-ejb-jar>
  <weblogic-enterprise-bean>
    <ejb-name>WorkEJB</ejb-name>
    <jndi-name>WorkEJB</jndi-name>
     
                          
<dispatch-policy>MyAppScopedWorkManager-2</dispatch-policy>
  </weblogic-enterprise-bean>
  ...
</weblogic-ejb-jar>

上の2つの例では、 MyAppScopedWorkManager-1と MyAppScopedWorkManager-2を使用しています。これらは、「WebLogicワークマネージャのコンフィグレーション」で説明したアプリケーションレベルで定義したワークマネージャです。

Pages: 1, 2, 3, 4, 5

Next Page »