WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

z/OS でのメッセージ駆動型 Bean の接続ファクトリー設定

さまざまな接続ファクトリー設定を調整して、 MDB 作業のための接続とセッションの作成を制御することができます。

このトピックでは、使用する接続ファクトリー設定の選択に影響する、以下の概念と考慮事項について説明します。

接続ファクトリー設定

認証パラメーターを使用してアプリケーションとサーバーを特定のキュー・マネージャーに接続するには、 アプリケーションとメッセージ・リスナー・ポートをともに接続ファクトリーにバインドします。 サーバーは、アプリケーションが JMS を活用するために使用するものと同じ管理モデルを使用して、 メッセージ駆動型 Bean に配信するために到着するメッセージを listen します。 そのメッセージ内で、 リスナー・ポートがキュー接続ファクトリーまたはトピック接続ファクトリー、および対応するキューまたはトピックにバインドされます。

接続ファクトリーのメッセージング・プロバイダー設定 (例えば、キュー・マネージャー設定) を指定するほかに、 接続およびセッション・プールのプロパティーも指定します。 特に、接続ファクトリーの場合、接続プール・プロパティーの「最大接続数」とセッション・プール・プロパティーの 「最大接続数」の値は、リスナー・ポート、アプリケーション、またはその両方に接続ファクトリーを使用するかによって異なる考慮事項に留意した上で、 選択する必要があります。

接続プールの最大接続数設定

まず、WebSphere Application Server で定義された制限に達したことによる JMS 接続待ちを回避するために、 接続プールの最大接続数を少なくとも以下の値の合計に設定する必要があります。
  1. この接続ファクトリー上にマップされたリスナー・ポートにマップされるメッセージ駆動型 Bean ごとに 1 つ。
  2. 1 つのディスパッチに対する接続の最大数に、サーバント内のワーカー・スレッドの数を掛けたもの。

    この最大接続数を決定するには、 まず単一のアプリケーション・ディスパッチ (通常は「1」) で 取得した最大数を調べてから、 この接続ファクトリーを使用する すべての接続をチェックする必要があります。 この接続の最大数に、サーバント内のワーカー・スレッドの数を掛けます。 (この値について詳しくは、次の注意事項を参照してください。)

ここでカウントされるのは、単一サーバントのワーカー・スレッドのみであることに注意してください。 これは、管理者がプロパティー値のセットを 1 つしか定義していなくても、 各サーバントが、接続とセッション・プールが設定された独自の接続ファクトリーを取得するためです。

前述の 2 番目の最大接続数についての説明
注:

メッセージ駆動型 Bean は、onMessage() でアプリケーション・ロジックを実行する際に、 JMS 接続を取得することもあれば、取得しないこともあります。 例えば、メッセージを別の宛先に転送したり、応答を送信したりするために接続を取得することがあります。 または、一部のログを更新するだけで、独自の JMS 関連の呼び出しを実行しない場合もあります。

いずれの場合も、これがリスナー・ポートが使用する接続であるため、 前述の 1 番目の最大接続数では、 このメッセージ駆動型 Bean に対して「1 つ」とカウントする必要があります。 メッセージ駆動型 Bean の onMessage() ロジックが 1 つの JMS 接続を取得する場合は、 サーバントのワーカー・スレッドの数を最大接続数に追加します。 そうでない場合、この (MDB) アプリケーション・コンポーネントの代わりに最大接続数に追加する必要はありません。

当然、この接続ファクトリーを使用して JMS 呼び出しを実行する他の MDB 以外のアプリケーション・コンポ ーネントが原因で、管理者が 2 番目の最大接続数全体を追加しなければならなくなることがあります。 しかし、この接続ファクトリーを使用する MDB または MDB 以外のアプリケーション・コンポーネントの数にかかわりなく、 それらがディスパッチごとにそれぞれ 1 つの JMS 接続のみを使用する場合は、 2 番目のカウントは、サーバントのワーカー・スレッドの数 (アプリケーションにサーバントのワーカー・スレッド の数を掛けたものではない) に等しくなるだけです。

セッション・プールの最大接続数設定

この計算は、当初の予想と比べて容易です。 すべての標準的な場合の MDB リスナー・ポート処理については、 セッション・プールの「最大接続数」プロパティーは、単一サーバントのワーカー・スレッドの数に設定する必要があります。

その理由は、同じ接続ファクトリーのクライアントの場合であっても、 JMS セッションがアプリケーション・ディスパッチ間でも、 リスナー・ポート・インフラストラクチャーによっても共用されないという事実にあります。 さらに、(接続ファクトリー・レベルでプールのプロパティー設定が一度しか指定されていなくても)、 接続ファクトリーから取得した JMS 接続ごとに固有のセッション・プールがあるという事実もあります。

リスナー・ポートとアプリケーションの両方によって同じ接続ファクトリーが使用され、 アプリケーションのセッション・プール設定の最大接続数の要件の方が高くなる場合が考えられますが、 ここでは、それについては説明しません。

重要: このセッション・プールの最大接続数をサーバントのワーカー・スレッドの数より少なく設定することによって、 サーバーでの並行 MDB 作業を制限することができます。 これはお勧めしません。 このような場合、MDB 作業要求は、メッセージを処理するために使用可能なセッションがなくても、サーバントにディ スパッチされる可能性があります。 ワーカー・スレッドは、その時点で、貴重なワーカー・スレッド・リソースを結合して、セッションが使用可能になるまで待機します。

使用する接続ファクトリーの数を多くすべきか少なくすべきか ?

この計算が単純である方が望ましいと考えるユーザーもいます。 例えば、メッセージ駆動型 Bean ごとに別々の接続ファクトリーを作成する方法です (この場合、接続プールの「最大接続数」プロパティーの値は、単純に 1 に設定します)。 また、管理する接続ファクトリーの管理オブジェクトの数を少なくする方を選ぶユーザーもいます。

MDB 処理に使用する接続とセッションを共用することはできません (つまり、 複数のフローがこれらを同時に使用することはできません) つまり、使用する接続ファクトリーの数を少なくするために、 プールを利用するのではないということです。 言い換えれば、別の接続ファクトリーを追加しても、接続のプールは防ぐことはできません。追加しなくても、 MDB リスナー・ポート処理が接続のプールを活用する可能性があります。

接続ファクトリー - 例

例 1
注:
以下に、シナリオを示します。
  • 各サーバントには、12 のワーカー・スレッドがあります。 (各サーバントには独自のプールがあるので、サーバー内のサーバントの数は、重要ではありません)。
  • リスナー・ポート LP1 は、接続ファクトリー CF1 にマップされます。 メッセージ駆動型 Bean MDB1 は、LP1 にマップされます。 MDB1 の onMessage() アプリケーション・コードは、 新規メッセージを転送キューに入れます。 したがって、MDB1 にはリソース参照があり、これも CF1 に解決されます。
  • さらに、同じサーバー内でリスナー・ポート LP2 が定義され、接続ファクトリー CF2 にマップされます。 メッセージ駆動型 Bean MDB2A と MDB2B が同じ ejb-jar ファイルに定義され、 両方とも補足的な JMS セレクターとともに LP2 にマップされます。 MDB2A と MDB2B の onMessage() アプリケーション・コードは、それぞれ何らかのロギングを行いますが、 いずれのメッセージ駆動型 Bean も独自の JMS API 呼び出しを行いません。
以下に、解決策を示します。
  • 接続ファクトリー CF1 の場合は、MDB1 に対して 1 つとカウントします。 MDB1 アプリケーション (接続ファクトリー CF1 を使用して、 その転送メッセージの送信も行います) は、1 つの JMS 接続を使用します。 この場合、ワーカー・スレッドの数 (12) に 1 を掛けてカウントします。 接続ファクトリー CF1 の接続プールの最大接続数の合計は、13 = 12 + 1 です。
  • 接続ファクトリー CF2 の場合は、MDB2A と MDB2B に対してそれぞれ 1 つとカウントします。 CF2 を使用するアプリケーションはありません (リスナー・ポート・インフラストラクチャーだけです)。 したがって、接続ファクトリー CF2 の接続プールの「最大接続数」は 2 と設定します。
  • 2 つの接続ファクトリーのそれぞれに対して、セッション・プールの「最大接続数」の値は 12 に設定されます。
例 2
注:
以下に、シナリオを示します。
  • この場合も、各サーバントには 12 のワーカー・スレッドがあります。 この例では、単一の接続ファクトリー CF1 のみを使用します。
  • 2 つのリスナー・ポート LP1 と LP2 は、それぞれ接続ファクトリー CF1 にマップされます。 メッセージ駆動型 Bean MDB1、MDB2、および MDB3 は、3 つの固有のアプリケーション EAR ファイルの一部です。 MDB1 は LP1 にマップされますが、MDB2 と MDB3 はそれぞれ LP2 にマップされます。
以下に、解決策を示します。
  • この時点までは、接続ファクトリー CF1 に対して 3 つの接続が必要であるとカウントします。 メッセージをキューに入れるサーブレット・コンポーネントもあり、 同じ接続ファクトリー CF1 を使用します。 したがって、接続ファクトリー CF1 の場合、接続プールの「最大接続数」の設定値は 15 = 3 + 12 です。



関連情報
z/OS での MDB 設定の概念および考慮事項
「コントローラー内で listen する」基本メッセージング・フロー
z/OS でのメッセージ駆動型 Bean の MDB スロットル設定
z/OS でのメッセージ駆動型 Bean、異種ワークロード、およびワークロード管理
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/cprf_tunezmdb_cf.html