(MDB)のチューニングとベスト・プラクティスについて説明します。10.0以前のバージョン方式のポーリングに対する互換性トランザクション・バッチの使用MDBトランザクションのバッチ処理を使用すると、複数のJMSメッセージを1つのコンテナ管理トランザクションに管理できます。バッチ処理を使用すると、複数のメッセージのトランザクション・コストが償却されます。適切に使用すると、2PC処理と1PC処理の間のスループットの差も削減、または排除できます。ServerメッセージドリブンBeanのプログラミング』のMDBのトランザクションのバッチ処理に関する項を参照してください。バッチ処理を使用する場合、同時に扱うMDBインスタンス数を減らす必要があることもあります。使用できるMDBインスタンスが多すぎる場合、メッセージはバッチ処理ではなく並行処理される可能性があります。「MDBスレッド管理」を参照してください。通常、バッチ処理ではスループットが向上しますが、待機時間(個々のメッセージのMDB処理が完了するまでの時間)も増大する場合があります。MDBスレッド管理MDBのスレッド管理については、同時実行性、すなわち同時にアクティブになれるMDBインスタンス数の観点から説明します。次の項では、MDBの同時実行性について説明します。表11-1では、サーバー・インスタンスに対して同時実行しているMDBインスタンス数の確定方法に関する情報を提供します。8.1でのデフォルト・スレッド・プールの同時実行性方式でもあります。WebLogicキューをリスニングしていて、トランザクション・バッチ処理が有効になっている場合、同期的なポーリング・メカニズムを使用してJMS宛先からメッセージを取得します。「キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング」を参照してください。次の項では、アプリケーションに対して同時実行性戦略を選択するための全般的な情報を示します。注意:アプリケーションはそれぞれに特性があり、使用するアプリケーションがその環境でどのように動作するのかに基づいて同時実行性戦略を選択します。ほとんどの状況において、メッセージ・ストリームにメッセージの急増が見られる場合には、制約のないワーク・マネージャを高いフェア・シェアで使用するのが適切です。急増したメッセージ群が処理されると、スレッドは自動チューニング・プールに返されます。ほとんどの状況において、メッセージの到着率を高いレベルで一定させるか、待機時間を小さくすることが求められる場合、MDBに対してスレッドを予約すると有効です。スレッドを予約するには、ワーク・マネージャにmin-threads-constraintを指定するか、カスタム実行キューを使用します。8.1のアプリケーションを移行する場合、以下の設定が可能です。カスタムMDB実行キューを引き続き使用します。8.1スレッド・プール・モデルの使用」を参照してください。MDB実行キューを、max-threads-constraintパラメータおよび高いフェア・シェア設定が構成されたカスタム・ワーク・マネージャに変換します。注意:デフォルトの同時実行性数(16)をオーバーライドするためには、max-threads-constraintパラメータを構成する必要があります。8.1では、デフォルトのプールを拡張すると同時実行性MDBの最大数も大きくなることから、デフォルトの実行キューのサイズを増加できました。9.0でアップグレードされたデフォルト・スレッド・プールのMDBは、最大数が16に固定されています。MDB同時実行の数を16よりも大きくするには、カスタム・ワーク・マネージャまたはカスタム実行キューを作成する必要があります。表11-1を参照してください。ServerとWebLogic宛先が相互運用する場合のスレッドの割当て方法について説明します。MDBでは、処理すべき新しいメッセージがある場合、必要に応じて、dispatch-policyで指定されているスレッド・プールからスレッドを割り当てます。MDBが正常にソース宛先に接続したものの処理するメッセージがない場合、MDBはスレッドを使用しません。MDBには、「互換性」(デフォルト)のトピック・メッセージ分散モードを使用するトピックMDBを除く非トランザクションMDBと同一の機能があります。いずれの場合でも、MDBは常にスレッド・プール・サイズを1に制限します。トランザクション対応のMDBでトランザクション・バッチ処理が有効になっている場合は、MDBがトピックとキューのどちらでリスニングしているかによって動作が異なります。各デプロイ済みMDBは、プールされないスレッドのグループで作成される、専用のデーモン・ポーリング・スレッドを使用します。デプロイされた各MDBは、プールされていないスレッドのスレッド・グループで作成される専用のデーモン・ポーリング・スレッドを使用します。各デプロイ済みMDBは、専用のスレッドを使用する代わりに、トークン・ベースの同期ポーリング・メカニズムを使用します。このメカニズムでは常にdispatch-policyから少なくとも1つのスレッドを使用します。「キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング」を参照してください。Serverを外部宛先から消費されたMDBと相互運用するときのスレッドの割当て方法の詳細は、「外部宛先からのメッセージを処理するMDBのスレッドの使用」を参照してください。マルチスレッド・トピックMDBの制限topicMessagesDistributionModeが「互換性」であるとき、非トランザクション・トピックMDBのデフォルト動作は、メッセージ処理のマルチスレッド化です。JMSトピックでないとき、MDBコンテナは再現可能な動作を提供できません。アプリケーションがonmessageからRuntimeExceptionをスローする場合、コンテナはメッセージを確認する可能性があります。JMSトピックでないとき)、トピックMDBにおけるマルチスレッド化を防ぐために、デプロイメント記述子でmax-beans-in-free-poolの値を1に設定することをお薦めします。外部(WebLogic以外の)トピックと共に機能する非トランザクションMDBには、明示的にmax-beans-in-free-poolを1に設定することをお薦めします。この設定に失敗すると、MDBアプリケーションがRuntimeまたはErrorの例外をスローするなど、特定のエラーがある場合にメッセージの損失につながる可能性があります。JMSの「順序単位」値を持つメッセージを処理する非トランザクション「互換性」モードのMDBには、明示的にmax-beans-in-free-poolを1に設定することをお薦めします。この使用事例のような「順序単位」メッセージは、max-beans-in-free-poolを1に設定しない場合、順序通りに処理されない可能性があります。トランザクションMDBは、max-beans-in-free-poolの設定に関係なく、強制的に自動で同時実行性を1に設定します。分散トピックを使用したMDBの構成およびデプロイのベスト・プラクティスメッセージドリブンBeanは、分散トピックの使用時にスケーラビリティと高可用性を付与する多数のアプリケーション設計およびデプロイメント・オプションを提供します。ServerメッセージドリブンBeanのプログラミング』の分散トピックを使用したMDBの構成およびデプロイに関する項を参照してください。注意:ここでの「外部宛先」とは、WebLogic以外のJMSプロバイダによってホストされる宛先を示します。リモートWebLogic宛先のことではありません。Serverの動作について説明します。JMS宛先に使用するアルゴリズムと同じアルゴリズムを使用して決定されます。Serverが外部宛先からのメッセージを処理するMDBと相互運用するときのスレッドの割当て方法について説明します。Serverのスレッドは使用しません。この場合、dispatch-policyは同時実行性方式の決定以外では無視されます。Serverスレッドで動作します。各デプロイ済みMDBは、プールされないスレッドのグループで作成される、専用のデーモン・ポーリング・スレッドを使用します。各デプロイ済みMDBは、専用のスレッドを使用する代わりに、トークン・ベースの同期ポーリング・メカニズムを使用します。このメカニズムでは常にdispatch-policyから少なくとも1つのスレッドを使用します。「キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング」を参照してください。MDBは、同期ポーリング・メカニズムを使用して、次の場合にJMS宛先からメッセージを取得します。次の場合のWebLogicトピックのリスニング。One-Copy-Per-Serverおよびトランザクションのバッチ処理が有効化されている場合。同期ポーリングを使用すると、1つ以上のWebLogicポーリング・スレッドはMDBのソース宛先から同期的にメッセージを受信し、MDBアプリケーションのonMessageコールバックを呼び出します。10.3では、メッセージの負荷が変動する状況で同時ポーラー・スレッド数を制御しやすくなるように、ポーリング・メカニズムがトークン・ベースの手法に変更されました。以前のリリースでは、特定の状況において、スレッド数の増加が緩やかすぎる場合がありました。特定の外部JMSプロバイダでは、子ポーラーを一度起動すると、数を減らしてプールに戻すことができない場合もありました。トークン・ベースのポーリングでは、スレッドがスレッド・プールに戻されるとき、スレッドの内部JMSコンシューマはキャッシュされるのではなく、閉じられます。そのため、コンシューマに対応するポーリング・スレッドはなくなり、メッセージが特定の外部JMSプロバイダによって暗黙的にプリフェッチされることがなくなります。各MDBは、特定のポーラー・スレッドに別スレッドの作成を許可する単一のトークンを保持します。トークンを持っているポーラー・スレッド、または、他に所有されていなかったのでトークンを獲得できたポーラー・スレッドが、追加のポーラー・スレッドを起動します。同時実行性スレッドの最大数に達していない場合は、そのトークンを新しいポーラーに与えます。同時実行性スレッドの最大数に達している場合は、(他のポーラーで使用できるように)単にトークンを解放します。ポーラーはトークンの獲得を試み、獲得できた場合は、そのキューの定期的なポーリングを試みます。トークンを獲得できない場合、ポーラーは自身をプールに返します。したがって、空のキューに対しても、少なくとも1つのポーラーがメッセージをチェックしていることになります。10.0以前のバージョン方式のポーリングに対する互換性WLSバージョン10.0以前では、バッチ処理が有効になっているトランザクション対応MDBは、デプロイ済みの各MDBごとに専用のポーリング・スレッドを作成していました。このポーリング・スレッドはdispatch-policyで指定されたプールから割り当てられるものではなく、システムで動作している他のすべてのスレッドに追加される、完全に新しいスレッドでした。「トランザクション・バッチの使用」を参照してください。10.0以前の動作を実装するには、以下のいずれかを行います。システム・プロパティをTrueに設定して、トークン・ベース・ポーリングの動作をオーバーライドします。MDBレベルでは、message-driven-descriptorの下のuse81-style-polling要素を設定して、トークン・ベース・ポーリングの動作をオーバーライドします。8.1方式のポーリング・フラグで外部のトランザクション対応MDBを使用する場合、外部ベンダーの中には同時実行するMDBインスタンスごとに恒久的にスレッドを割り当てる必要があるものもあります。このようなスレッドはdispatch-policyで指定されたプールから取得され、MDBがアンデプロイされるまでプールに返されません。したスレッドは共有されないため、MDBが同じプール内の他のリソースの処理を妨げることがあります。このような場合、必要に応じてプールのスレッド数を増加します。このような外部ベンダーの場合にトークン・ベースのポーリング方式を使用した場合、スレッドの内部的なJMSメッセージ・コンシューマはキャッシュされるのではなく閉じられるため、メッセージが特定のコンシューマの宛先によって予約されることはありません。reserved.法律上の注意点ライブラリ。