|
以下の節では、メッセージ順序単位を使用して、WebLogic JMS の使用時に厳格なメッセージ順序を提供する方法について説明します。
メッセージ順序単位は WebLogic Server の付加価値機能です。スタンドアロンのメッセージ プロデューサや、単体として動作するプロデューサのグループは、この機能を使用して複数のメッセージを処理順序に応じた 1 つの単位にグループ化できます。この単位を順序単位と呼び、この単位からのすべてのメッセージはその作成順に従って処理されます。
以下の節では、JMS 仕様に記述されているメッセージ処理と、WebLogic Server のメッセージ順序単位機能を使用して拡張したメッセージ処理を比較します。
Java Message Service 仕様ではメッセージ配信の順序付けが規定されていますが、この順序付けは非常に厳格に適用されます。プロデューサの単一のインスタンスとコンシューマの単一のインスタンスの間の順序が定義されますが、以下のような一般的な状況は考慮されていません。
メッセージ順序単位機能を使用すると、メッセージ プロデューサや単体として動作するプロデューサのグループが、複数のメッセージを 1 つの単位にグループ化してメッセージを作成順に処理することが可能になります。単一のメッセージのメッセージ処理は、メッセージが確認応答、コミット、回復、またはロールバックされたときに完了します。メッセージのメッセージ処理が完了するまでは、その順序単位の残りの未処理メッセージがブロックされます。
この節では、順序単位を使用した場合の JMS 確認応答モードの規則について説明します。
CLIENT_ACKNOWLEDGE
、AUTO_ACKNOWLEDGE
、または DUPS_OK_ACKNOWLEDGE
である場合、順序単位のメッセージは並行処理されません。CLIENT_ACKNOWLEDGE
- アプリケーションが Message.acknowledge
および Session.recover
を呼び出すと、順序単位内でどのメッセージの処理が完了したかが示されます。AUTO_ACKNOWLEDGE
- receive
の呼び出しからセッションが正常に返されたとき、または呼び出された MessageListener
からセッションが正常に返されたときに、セッションが自動的にクライアントによるメッセージの受信を確認応答します。DUPS_OK_ACKNOWLEDGE
- receive
の呼び出しからセッションが正常に返されたとき、または呼び出された MessageListener
からセッションが正常に返されたときに、セッションが自動的にクライアントによるメッセージの受信を確認応答します。NO_ACKNOWLEDGE
- セッションは、処理の順序を保証しません。メッセージは、使用可能な別のコンシューマで並行処理できます。
メッセージ順序単位では、以下の規則に従ってメッセージが配信されます。
Redelivery Delay
または期限切れになっていない TimetoDeliver
タイマーが設定されている場合は、それ以降のメッセージが遅延します。JMSSession
) に存在しなければなりません。順序単位内の 1 つのメッセージが未コミットまたは未応答である場合、他のメッセージは同じトランザクションまたは JMSSession
にのみ配信されます。これにより、同じ順序単位からのすべての未応答メッセージが 1 つの回復可能な処理内に保持され、ロールバックや回復に関係なく順序を維持できます。
この節では、オンライン書店への本の注文に基づいて、メッセージ順序単位の単純なケース スタディを行います。
XYZ オンライン書店は、JMS を使用して顧客の注文を処理する単純な処理設計を実装しています。JMS 処理システムは、以下から構成されます。
Joe は、XYZ オンライン書店の自分のアカウントにログインして欲しい本を検索します。本を選び、会計に進んで、販売トランザクションを完了します。ここで Joe は、以前に同じ本を買っていたことに気付き、注文をキャンセルします。ところが 1 週間後、その本が Joe のもとに届いてしまいます。
Joe の注文シナリオでは、注文キャンセル メッセージが、注文メッセージよりも前に処理されました。その結果、買いたくなかった本が届けられてしまいました。ここでは、Joe の注文が処理された手順について説明します。
次の図とそれに対応する各アクションは、Joe の注文がどのように処理されたかを示します。
Java Message Service 仕様にはメッセージ配信の順序付けが規定されていますが、プロデューサの単一のインスタンスとコンシューマの単一のインスタンスの間でのメッセージ配信の順序付けしか規定されていません。Joe のケースでは、Queue1 のメッセージを複数のメッセージ駆動型 Bean (MDB) が消費できるため、メッセージの処理順序はまったく保証されなくなっていました。
Joe の注文に関わるすべてのメッセージが常に正しく処理されるようにするには、XYZ 書店のシステム管理者がユーザ セッションに基づいてメッセージ順序単位をコンフィグレーションして、ユーザ セッションからのすべてのメッセージに順序単位名属性を持たせ、値としてセッション ID を設定します。「順序単位の作成方法」を参照してください。WebLogic Server では順序単位内のメッセージが並行処理されることはないため、Joe のユーザ セッションの間に作成されたすべてのメッセージは作成された順番どおりに処理されます。
次の図とそれに対応する各アクションは、メッセージ順序単位を使用した場合に Joe の注文がどのように処理されるかを示します。
以下の節では、メッセージ順序単位を作成する方法について説明します。「順序単位によるメッセージ配信」および「メッセージ順序単位の高度なトピック」も参照してください。
WLMessageProducer インタフェースの setUnitOfOrder() メソッドを使用して、プロデューサを順序単位名に関連付けます。
getProducer().setUnitOfOrder("myUOOname");
プロデューサを順序単位名に関連付けると、プロデューサをクローズするか、プロデューサと順序単位の関連付けが解消されるまで、このプロデューサが送信するすべてのメッセージは順序単位として処理されます。
次のコードでは、プロデューサと順序単位の関連付けの例を示します。
.
.
.
queue = (Queue)(ctx.lookup(destName));
qsender = (WLMessageProducer) qs.createProducer(queue);
qsender.setUnitOfOrder();
uooname = qsender.getUnitOfOrder();
System.out.println("Using UnitOfOrder :" + uooname);
.
.
.
ここでは、JMS 接続ファクトリや JMS 送り先をコンフィグレーションして、メッセージ順序単位を有効にする方法について説明します。
以下のいずれかの方法で、JMS 接続ファクトリと送り先をコンフィグレーションしてメッセージ順序単位を有効にします。
WLProducer.setUnitOfOrder(name)
を呼び出して、プロデューサの接続ファクトリの初期設定を変更する。
従来の JMS アプリケーションと相互運用する場合には、接続ファクトリまたは送り先に管理的に順序単位をコンフィグレーションする必要があります。この方法は、コードを変更することなく、メッセージが作成順に処理されるようにするための単純なメカニズムを提供します。
順序単位は、名前属性によって特定されます。送り先内では、順序単位名属性に同じ値が設定されているメッセージが、同じ順序単位に属します。名前は、システムからでもアプリケーションからでも指定できます。同じ順序単位内のすべてのメッセージは、同じ名前を共有します。「順序単位の作成方法」を参照してください。
順序単位の名前属性は、以下の規約に準拠させる必要があります。
msg.getStringProperty("JMS_BEA_UnitOfOrder");
したがって、システム生成の順序単位名は、複数のプロデューサで使用できます。このパラダイムは、アプリケーションによって割り当てられた順序単位名にもそのまま適用できます。情報が一元的にシリアライズされているのが最も効率的です。したがって、順序単位名としては会話 ID のようなプロパティのみを格納するようにしてください。このパラダイムは、メッセージが順序単位非対応の JMS プロバイダ (WebLogic 9.0 より前のリリースや WebLogic 以外の JMS プロバイダ) で送信された場合には適用されません。
以下の節では、より高度で複雑な状況での順序単位によるメッセージ処理方法について説明します。
メッセージ処理の間には、通常であればメッセージの処理順序が変更されるような状況が数多く発生します。以下に、メッセージの配信準備を整えることができない典型的なメッセージ処理状態を示します。
たとえば、メッセージ A とメッセージ B が同じ順序単位に届き、上に挙げたような状況でメッセージ A を配信できないとします。この場合、メッセージ B の配信を遅延させる要因がなくても、順序単位内のメッセージ A が配信されるまではメッセージ B を配信することはできません。
フィルタと順序単位を使用すると、予期しない動作が発生することがあります。たとえば、メッセージ A から Z が、同じキューの同じ順序単位にあるとします。Consumer1 にはフィルタが設定されており、メッセージ A、B、および C がそのフィルタ条件を満たすため、これらのメッセージが Consumer1 に配信されます。
詳細については、「メッセージのフィルタ処理」を参照してください。
送り先ソート キーは、メッセージが順序単位の一部でない場合や、同じ順序単位の一部でない場合に、コンシューマにメッセージを配信する順序を制御します。
たとえば、届いたメッセージ A および B がキュー上の同じ順序単位に含まれており、優先度の降順でソートされていて優先度はメッセージ A よりメッセージ B のほうが高いとします。
メッセージ B のほうがメッセージ A よりも優先度が高くても、これらのメッセージは同じ順序単位に含まれているため、メッセージ A が処理されるまではメッセージ B を配信できません。次に届いたメッセージ C は、順序単位が設定されていないか、メッセージ A と同じ順序単位には含まれていないとします。この場合、メッセージ C の優先度設定とメッセージ A の優先度設定によって配信順序が決まります。『WebLogic JMS のコンフィグレーションと管理』の「基本 JMS システム リソースのコンフィグレーション」を参照してください。
すでに「JMS 仕様に準拠したメッセージ処理」で説明したように、アプリケーションで分散キューを使用している場合、Java Message Service 仕様のメッセージ配信の順序付けは保証されません。WebLogic JMS では、分散送り先が対象指定されている複数のメッセージに同じ順序単位が設定されている場合は、それらのメッセージを同じ分散送り先メンバーに転送します。メンバーは、送り先の順序単位コンフィグレーションに基づいて選択されます。
WebLogic パス サービスをコンフィグレーションすると、順序単位に含まれるメッセージをその送り先リソース (共通分散送り先のメンバー) にルーティングするために必要な情報を格納する永続マップを提供できます。共通分散送り先の WebLogic パス サービスがコンフィグレーションされていない場合、メンバー送り先へのルーティング パスは、分散キューの実行時のロード バランシング ヒューリスティックに基づいて決定されます。『WebLogic JMS のコンフィグレーションと管理』の「WebLogic パス サービスの使用」を参照してください。
WebLogic パス サービスがコンフィグレーションされていない場合、メンバー キューへのデフォルトのルーティング パスは、メッセージ順序単位名と共通分散キュー メンバーのハッシュ コードに基づいて選択されます。このルーティング メカニズムの利点は、分散キュー メンバーへのルートがすばやく計算され、クラスタ内の永続ストレージを必要としない点です。
メッセージ順序単位とハッシュ ベースのルーティングを実装する際には、以下のことに留意してください。
JMSOrderException
を送出し、メッセージは別の分散キュー メンバーにはルーティングされません。この例外が送出されるのは、JMS メッセージ システムが必要なサービス品質を満たすことができないからです。特定の順序単位に対しては、1 つの分散送り先メンバーだけがメッセージを消費できます。
メッセージ順序単位を使用して、共通分散送り先でのパス サービスまたはハッシュ ベースのルーティング メカニズムをコンフィグレーションする場合は、以下のトピックのいずれかを参照してください。
順序単位を割り当てても、同じトピック上の 2 つのサブスクライバによるメッセージの並行処理は可能です。トピックの個々のサブスクライバには独自の送り先とメッセージ リストがあるため、コンシューマが 1 つのキューと同様に、メッセージはプロダクション時に割り当てられた順序単位に従ってすべてのサブスクライバによって処理されます。
メッセージが分散トピックに送信された場合、特定の物理メンバーでのメッセージの処理順序は、メッセージがメンバーに届いた順序によって定義されます。「パブリッシュ/サブスクライブ メッセージング」を参照してください。
JMS メッセージ管理を使用すると、JMS の管理者は実行中の JMS サーバ内のほとんどのメッセージを移動したり削除したりできます。つまり、管理者は「順序単位によるメッセージ配信」に示した配信規則を侵害することができます。
たとえば、順序単位 foo に属すメッセージ A、B、C、および D が生成されて送り先 D1 に送信された場合、以下の点に留意してください。
メッセージ順序の維持に依存するアプリケーションでは、1 つの順序単位内のすべてのメッセージを単一のグループとして移動するのがベスト プラクティスです。
順序単位の配信規則が維持されるようにするには、次の手順に従ってください。
詳細については、『WebLogic JMS のコンフィグレーションと管理』の「WebLogic JMS のトラブルシューティング」を参照してください。
WebLogic ストア アンド フォワードでは、メッセージ順序単位がサポートされます。たとえば、Foo という順序単位のメッセージを送信するストア アンド フォワード プロデューサがあるとします。このプロデューサは、切断して別の接続で再接続すると、Foo という順序単位を作成してメッセージの送信を継続します。再接続の前と後に送信されたすべてのメッセージは、同じストア アンド フォワード エージェントを介して転送されます。詳細については、『WebLogic ストア アンド フォワードのコンフィグレーションと管理』を参照してください。
ソース送り先と対象送り先の両方が WebLogic Server 9.0 以降のメッセージング ブリッジ インスタンスである場合は、メッセージング ブリッジの PreserveMsgProperty
を有効にすると、順序単位名を維持してプロデューサの順序単位を設定できます。『WebLogic メッセージング ブリッジのコンフィグレーションと管理』を参照してください。
この節では、順序単位を使用する際に考慮すべきその他の一般情報を示します。