会話グループはローカルです 概念のみ。ロック専用に使用されます。相関会話はグループに属しているため、ある会話でメッセージを処理している間、別のスレッドは相関メッセージを処理できません。 2つのエンドポイントによって交換される会話グループに関する情報がないため、この例では、すべてのイニシエーターエンドポイントが1つの会話グループに属しますが、ターゲットエンドポイントはそれぞれ別個の会話グループです（各グループには1つの会話しかありません）。システムがこのように動作する理由は、会話グループが、たとえば旅行予約サービスなどの問題に対処するように設計されているためです。「旅行を予約する」というメッセージを受信すると、飛行機、ホテル、車を予約する必要があります。レンタル。これらのサービス（「フライト」、「ホテル」、「車」）のそれぞれに1つずつ、合計3つのメッセージを送信する必要があります。そうすると、応答は非同期で返されます。それらが戻ってきたとき、処理は、それらが別々のスレッドによって同時に処理されないようにする必要があります。スレッドはそれぞれ、「トリップ」レコードのステータスを更新しようとします。メッセージングでは、この問題は「メッセージ相関問題」として知られています。
ただし、多くの場合、会話グループはパフォーマンス上の理由だけでSSBに展開されます。つまり、会話グループはより大きなRECEIVE結果を可能にします。 MOVE CONVERSATION <を使用して、ターゲットエンドポイントをグループにまとめて移動できます。 / code>
しかし実際には、もっと簡単なトリックがあります。会話の方向を逆にすることです。 目的地 会話を開始し（グループ化）、ソース 宛先によって開始された会話で「更新」を送信します。
いくつかのメモ：
- BEGIN / SEND/ENDのファイアアンドフォーゲットパターンを使用しないでください。今後、問題を診断できなくなります。 Fire and Forget：軍隊には適していますが、ServiceBrokerの会話には適していません 。
- 本番コードでWITHCLEANUPを使用しないでください。これは、災害復旧などの管理上の最後の手段としてのアクションを目的としています。これを悪用すると、SSBがメッセージを適切に追跡して正しい再試行配信を行う機会を拒否します（メッセージが何らかの理由でターゲット上でバウンスした場合、メッセージは永久に失われます）。
- SSBは、1つの会話内でのみ、会話間の順序を保証しません。 INSERTイベントごとに新しい会話を開始しても、ターゲット上で挿入操作の順序が維持されるとは限りません。