![[z/OS]](../images/ngzos.gif)
z/OS で WebSphere MQ をメッセージング・プロバイダーとして使用する ASF メッセージ駆動型 Bean の接続ファクトリー設定
さまざまな接続ファクトリー設定を調整して、メッセージ駆動型 Bean (MDB) 作業のための接続とセッションの作成を制御することができます。
接続ファクトリー設定
認証パラメーターを使用してアプリケーションとサーバーを特定のキュー・マネージャーに接続するには、アプリケーションとメッセージ・リスナー・ポートの両方を接続ファクトリーにバインドします。サーバーは、アプリケーションが JMS を活用するために使用するものと同じ管理モデルを使用して、メッセージ駆動型 Bean に配信するために到着するメッセージを listen します。そのメッセージ内で、リスナー・ポートがキュー接続ファクトリー (またはトピック接続ファクトリー) および対応するキュー (またはトピック) にバインドされます。
接続ファクトリーごとに、メッセージング・プロバイダー設定 (例えば、キュー・マネージャー設定)、接続プール・プロパティー、およびセッション・プール・プロパティーを指定する必要があります。接続ファクトリーの「接続プールの最大接続数」プロパティーおよび「セッション・プールの最大接続数」プロパティーの設定は、使用する接続ファクトリーがリスナー・ポートに対するものか、アプリケーションに対するものか、その両方に対するものかによって異なります。
接続プールの最大接続数設定
- この接続ファクトリー上にマップされたリスナー・ポートにマップされるメッセージ駆動型 Bean の数
- メッセージ駆動型 Bean は、onMessage() でそのアプリケーション・ロジックの実行中に JMS 接続を取得する場合があります。以下はその例です。
- メッセージを別の宛先に転送するか、応答を送信します
- ログを更新するが、独自のログの JMS 関連呼び出しを実行しません
いずれの場合も、これがリスナー・ポートで使用される接続であるため、このメッセージ駆動型 Bean に対して「1 つ」とカウントします。
メッセージ駆動型 Bean の onMessage() ロジックで 1 つの JMS 接続を取得する場合は、「サーバントのワーカー・スレッドの数」を「最大接続数」に加算します。取得しない場合は、この (MDB) アプリケーション・コンポーネントの「最大接続数」を加算しないでください。
- 最大接続数
- まずこの接続ファクトリーを使用するすべてのアプリケーションを調べて、「単一のアプリケーション・ディスパッチで取得した接続の最大数」 (通常は「1」) を確認します。次にこの数に「サーバント内のワーカー・スレッドの数」を掛けて、「最大接続数」を計算します。注:
- ワーカー・スレッドは 1 つのサーバントに対してのみカウントします。それぞれのサーバントには、接続プールとセッション・プールを持つ独自の接続ファクトリーがあるためです。
- この接続ファクトリーを使用して JMS 呼び出しを実行するその他の MDB 以外のアプリケーション・コンポーネントも含めます。ただし、この接続ファクトリーを使用する MDB または MDB 以外のアプリケーション・コンポーネントの数に関係なく、これらのコンポーネントがそれぞれディスパッチ用に 1 つの JMS 接続しか使用しない場合は、「最大接続数」はサーバントのワーカー・スレッドの数となります (アプリケーションの数にサーバントのワーカー・スレッドの数を掛けたものではありません)。
セッション・プールの最大接続数設定
すべての標準的なケースでの MDB リスナー・ポート処理の場合、「セッション・プールの最大接続数」プロパティーを単一サーバント内のワーカー・スレッドの数に設定します。
これは、同じ接続ファクトリーのクライアントの場合であっても、JMS セッションは、アプリケーション・ディスパッチ間でも、リスナー・ポート・インフラストラクチャーによっても共有されないという理由と、(プールのプロパティー設定が接続ファクトリー・レベルで一度しか指定されていなくても) 接続ファクトリーから取得した JMS 接続ごとに固有のセッション・プールがあるという理由によるものです。
リスナー・ポートとアプリケーションの両方によって同じ接続ファクトリーが使用され、アプリケーションのセッション・プール設定の最大接続数の要件の方が高くなる場合が考えられますが、これについては、ここでは説明しません。
使用する接続ファクトリーの数を多くすべきか少なくすべきか ?
この計算は単純である方が望ましいと考えることもできます。例えば、メッセージ駆動型 Bean ごとに別々の接続ファクトリーを作成する方法があります (この場合、接続プールの「最大接続数」プロパティーの値は、1 に設定できます)。 あるいは、管理する接続ファクトリーの管理オブジェクトの数を少なくしておくこともできるでしょう。
MDB 処理に使用する接続とセッションを共有することはできません (すなわち、複数のフローで一度に使用することはできません)。そのため、プーリングをより少ない接続ファクトリーを使用する方法として扱わないでください。言い換えれば、別の接続ファクトリーを追加しても、接続のプールは防ぐことはできません。追加しなくても、 MDB リスナー・ポート処理が接続のプールを活用する可能性があります。
接続ファクトリー - 例
- 各サーバントには、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 に設定します。
- この場合も、各サーバントには 12 のワーカー・スレッドがあります。 この例では、単一の接続ファクトリー CF1 のみを使用します。
- 2 つのリスナー・ポート LP1 と LP2 は、それぞれ接続ファクトリー CF1 にマップされます。 メッセージ駆動型 Bean MDB1、MDB2、および MDB3 は、3 つの固有のアプリケーション EAR ファイルの一部です。 MDB1 は LP1 にマップされますが、MDB2 と MDB3 はそれぞれ LP2 にマップされます。
- この時点までは、接続ファクトリー CF1 に対して 3 つの接続が必要であるとカウントしました。ただし、メッセージをキューに入れるサーブレット・コンポーネントもあり、このコンポーネントは同じ接続ファクトリー CF1 を使用します。 したがって、接続ファクトリー CF1 の場合、接続プールの「最大接続数」の設定値は 15 = 3 + 12 です。