メッセージ駆動型 Bean は、 他のメッセージ駆動型 Bean と MDB 以外の作業項目などの、異種ワークロードをホストするアプリケーション・サーバー上で実行できます。 z/OS で異種ワークロードを管理するには、WLM 分類を使用して、 同じサーバーで実行する優先順位の異なる作業に 固有のサービス・クラスを定義する必要があります。
z/OS での MDB 設定の概念および考慮事項の下の一連のトピックでは、 分かりやすくするために、説明において、サーバーが単一のメッセージ駆動型 Bean をホストしていることと、 すべてのサーバントのワーカー・スレッドで複数の MDB インスタンスを同時に実行できることを前提としています。 当然、現実には、メッセージ駆動型 Bean は、 異種ワークロードをホストするアプリケーション・サーバー上で実行されることがあります。 このようなワークロードには、他のメッセージ駆動型 Bean、IIOP を介してアクセスされるエンタープライズ Bean、 HTTP を介してアクセスされるサーブレットや JSP などの作業、およびその他の作業項目が含まれます。
さまざまな MDB 関連のチューニング制御では、所定のサーバー内で 所定のメッセージ駆動型 Bean やメッセージ駆動型 Bean のセットについて実行される MDB 作業の量に対して、 詳細な制御を実行する方法が提供されますが、 特定の MDB 作業をサーバー内の他の作業の上下に優先順位付けするためにこれらの設定を使用することはお勧めしません。 別の方法として、同じサーバー内で実行されている優先順位の異なる作業に対して、WLM の分類を使用し、 固有のサービス・クラスを定義することをお勧めします。 固有のサービス・クラスごとに、少なくとも 1 つのサーバントを考慮するようにしてください。
これにより、単一のリスナー・ポートを移動する作業においては、 さまざまなセレクターがさまざまなサービス・クラスにマッピングされるような構成を行うことが困難になります。 ワークロードの分類について詳しくは、z/OS ワークロードの分類を参照してください。
リスナー・ポートにはスロットルが 1 つしかありません。 このスロットルは、WLM キューに、作業レコードとして優先順位の異なるメッセージをキューに入れる 速度を制御します。 優先順位付けは、作業レコードをキューに入れる際に、ワークロード管理の支援を得た場合にのみ発生します。 メッセージがキュー・エージェント・スレッドによって参照され、 作業レコードがキューに入れられる段階では適用されません。
このような場合に実行できる 1 つの方針は、上限しきい値 (リスナー・ポートの「最大セッション数」プ ロパティーの値) を、ベースラインの推奨より高い、「すべてのサーバーのサーバント内のワーカー・スレッドを合計した数値の 2 倍」に設定することです。 その根拠は、ワークロード管理によって、作業要求のキューイングを中止するのではなく、 どの作業を次に処理するかを決定できるように、WLM キューが十分ロードされていることを確実にすることです。 (作業要求のキューイングを中止すると、優先順位の高いメッセージが参照されるのを待機しているときに、 優先順位の低い作業レコードが WLM キュー上にあふれる可能性があります。)
ここで説明する内容以外の、他の方針を立てることも可能です。
リスナー・ポートの最大セッション数を設定するベースラインの公式を、 すべてのサーバー内で使用可能な実際のワーカー・スレッド数の 2 倍ではなく、 スケーラブル・サーバー内のサーバントの最大数 に使用可能なワーカー・スレッド数の 2 倍になるように調整する必要があるでしょうか? 一般に推奨することは難しいですが、公式を変更する価値はないかもしれません。 設定を下げると、アイドル状態のワーカー・スレッドが発生する可能性があり、 厳密に必要な値より高く設定すると、WLM キューに余分なメッセージが溜まります。 キュー上に存在する余分なメッセージの数は、これまでどおり少なくして、サーバー障害の原因となる WLM キューの過負 荷と いう深刻な問題を防ぐ必要があります。