|
|
以下の節では、メッセージ駆動型 Bean (MDB) のチューニングとベスト プラクティスについて説明します。
MDB のトランザクション バッチ処理では、複数の JMS メッセージを 1 つのコンテナ管理によるトランザクションで処理できます。バッチ処理を行うと複数のメッセージを扱うトランザクションのコストが償却され、適切に使用した場合には 2PC 処理と 1PC 処理のスループットの差が軽減したり、解消されたりすることもあります。『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「MDB のトランザクション バッチ処理」を参照してください。
| 注意 : |
MDB のスレッド管理については、同時実行性、すなわち同時にアクティブになれる MDB インスタンス数の観点から説明します。以下の節では、MDB の同時実行性について説明します。
表 10-1 は、1 つのサーバ インスタンスに対して同時に実行する MDB インスタンスを決定する方法を示しています。
トランザクション対応の WebLogic MDB は、A) WebLogic 以外のキューをリスンしている場合、または B) WebLogic キューをリスンしていて、トランザクション バッチ処理が有効になっている場合、同期的なポーリング メカニズムを使用して JMS 送り先からメッセージを取得します。「キューでリスンするトランザクション対応 MDB でのトークンベースのメッセージ ポーリング」を参照してください。
以下の節では、アプリケーションに対して同時方式を選択するための全般的な情報を示します。
| 注意 : | アプリケーションにはそれぞれにユニークな特性があります。同時方式はアプリケーションがその環境でどのように動作するのかに基づいて選択します。 |
min-threads-constraint を指定するか、カスタム実行キューを使用します。 max-threads-constraint パラメータおよび高いフェア シェア設定がコンフィグレーションされたカスタム ワーク マネージャに変換する。 | 注意 : | デフォルトの同時実行数 (16) をオーバーライドするためには、max-threads-constraint パラメータをコンフィグレーションする必要があります。 |
以下の節では、WebLogic Server と WebLogic 送り先が相互運用する場合のスレッドの割り当て方法について説明します。
dispatch-policy で指定されているスレッド プールからスレッドを割り当てる。MDB が正常にソース送り先に接続したものの処理するメッセージがない場合、MDB はスレッドを使用しません。dispatch-policy から少なくとも 1 つのスレッドを使用します。「キューでリスンするトランザクション対応 MDB でのトークンベースのメッセージ ポーリング」を参照してください。
WebLogic Server が外部ベンダの MDB と相互運用する場合のスレッドの割り当て方法については、「外部 MDB 使用時のスレッドの利用」を参照してください。
以下の節では、外部ベンダ MDB 使用時の WebLogic Server の動作について説明します。
外部 MDB の使用時には、WebLogic Server により 表 10-2 のように同時方式が決定されます。
以下の節では、WebLogic Server を外部ベンダ MDB と相互運用する場合のスレッドの割り当て方法について説明します。
dispatch-policy は同時方式の決定以外では無視されます。dispatch-policy から少なくとも 1 つのスレッドを使用します。「キューでリスンするトランザクション対応 MDB でのトークンベースのメッセージ ポーリング」を参照してください。
トランザクション対応の WebLogic MDB は、A) WebLogic 以外のキューをリスンしている場合、または B) WebLogic キューをリスンしていて、トランザクション バッチ処理が有効になっている場合、同期的なポーリング メカニズムを使用して JMS 送り先からメッセージを取得します。同期的なポーリングでは、1 つまたは複数の WebLogic ポーリング スレッドが MDB のソース送り先からメッセージを同期的に受信し、MDB アプリケーションの onMessage コールバックを呼び出します。
WebLogic 10.3 では、メッセージの負荷が変動する状況で同時ポーラー スレッド数を制御しやすくなるように、ポーリング メカニズムがトークンベースの手法に変更されました。以前のリリースでは、特定の状況において、スレッド数の増加が緩やかすぎる場合がありました。また、特定の外部 JMS プロバイダでは、子ポーラーを一度起動すると、数を減らしてプールに戻すことができない場合もありました。
トークンベースのポーリングでは、スレッドがスレッド プールに戻されるとき、スレッドの内部 JMS コンシューマはキャッシュされるのではなく、閉じられます。そのため、コンシューマに対応するポーリング スレッドはなくなり、メッセージが特定の外部 JMS プロバイダによって暗黙的にプリフェッチされることがなくなります。
また、各 MDB は、特定のポーラー スレッドに別スレッドの作成を許可する単一のトークンを保持します。
WLS バージョン 10.0 以前では、バッチ処理が有効になっているトランザクション対応 MDB は、デプロイ済みの各 MDB ごとに専用のポーリング スレッドを作成していました。このポーリング スレッドは dispatch-policy で指定されたプールから割り当てられるものではなく、システムで動作している他のすべてのスレッドに追加される、完全に新しいスレッドでした。「トランザクション バッチの使用」を参照してください。
トークンベースのポーリングの動作をオーバーライドして WLS 10.0 以前の動作を実装するには、以下のいずれかを行います。
| 注意 : | WLS 8.1 方式のポーリング フラグで外部のトランザクション対応 MDB を使用する場合、外部ベンダの中には同時実行する MDB インスタンスごとに恒久的にスレッドを割り当てる必要があるものもあります。このようなスレッドは dispatch-policy で指定されたプールから取得され、MDB がアンデプロイされるまでプールに返されません。こうしたスレッドは共有されないため、MDB が同じプール内の他のリソースの処理を妨げることがあります。このような場合、必要に応じてプールのスレッド数を増加します。 |
| 注意 : | このような外部ベンダの場合にトークンベースのポーリング方式を使用した場合、スレッドの内部的な JMS メッセージ コンシューマはキャッシュされるのではなく閉じられるため、メッセージが特定のコンシューマの送り先によって予約されることはありません。 |
|