Les groupes de conversation sont locaux concept uniquement, utilisé exclusivement pour le verrouillage :les conversations corrélées appartiennent à un groupe de sorte que pendant que vous traitez un message sur une conversation, un autre thread ne peut pas traiter un message corrélé. Il n'y a aucune information sur les groupes de conversation échangés par les deux points de terminaison, donc dans votre exemple, tous les points de terminaison initiateurs finissent par appartenir à un groupe de conversation, mais les points de terminaison cibles sont chacun un groupe de conversation distinct (chaque groupe n'ayant qu'une seule conversation). La raison pour laquelle le système se comporte ainsi est que les groupes de conversation sont conçus pour résoudre un problème comme, par exemple, un service de réservation de voyage :lorsqu'il reçoit un message pour "réserver un voyage", il doit réserver un vol, un hôtel et une voiture de location. Il doit envoyer trois messages, un à chacun de ces services ('vols', 'hôtels', 'voitures') puis les réponses reviendront, de manière asynchrone. Lorsqu'ils reviennent, le traitement doit s'assurer qu'ils ne sont pas traités simultanément par des threads séparés, qui essaieraient chacun de mettre à jour l'état de l'enregistrement "voyage". Dans la messagerie, ce problème est connu sous le nom de "problème de corrélation de messages".
Cependant, les groupes de conversation sont souvent déployés en SSB uniquement pour des raisons de performances :ils permettent des résultats RECEIVE plus importants. Les points de terminaison cibles peuvent être déplacés ensemble dans un groupe à l'aide de MOVE CONVERSATION
mais en pratique il existe une astuce bien plus simple :inverser le sens de la conversation. Ayez votre destination démarrer les conversations (groupées), et la source envoie ses 'mises à jour' sur la ou les conversations entamées par la destination.
Quelques remarques :
- N'utilisez pas le modèle de feu et d'oubli de BEGIN/SEND/END. Vous rendez impossible le diagnostic de tout problème à l'avenir, consultez Fire and Forget :Bon pour l'armée, mais pas pour les conversations avec Service Broker .
- Ne jamais utiliser WITH CLEANUP dans le code de production. Il est destiné aux actions administratives de dernier recours telles que la reprise après sinistre. Si vous en abusez, vous privez SSB de toute chance de suivre correctement le message pour une nouvelle tentative de livraison correcte (si le message rebondit sur la cible, pour une raison quelconque, il sera perdu à jamais).
- SSB ne garantit pas l'ordre dans les conversations, uniquement au sein d'une conversation. Commencer une nouvelle conversation pour chaque événement INSERT ne garantit pas de préserver, sur cible, l'ordre des opérations d'insertion.
