I gruppi di conversazione sono un locale solo concetto, utilizzato esclusivamente per il blocco:le conversazioni correlate appartengono a un gruppo in modo che mentre elabori un messaggio su una conversazione, un altro thread non possa elaborare un messaggio correlato. Non ci sono informazioni sui gruppi di conversazione scambiati dai due endpoint, quindi nel tuo esempio tutti gli endpoint dell'iniziatore finiscono per appartenere a un gruppo di conversazioni, ma gli endpoint di destinazione sono ciascuno un gruppo di conversazioni distinto (ogni gruppo ha una sola conversazione). Il motivo per cui il sistema si comporta in questo modo è perché i gruppi di conversazione sono progettati per affrontare un problema come, ad esempio, un servizio di prenotazione di un viaggio:quando riceve un messaggio per "prenotare un viaggio", deve prenotare un volo, un hotel e un'auto noleggio. Deve inviare tre messaggi, uno a ciascuno di questi servizi ("voli", "hotel", "auto") e quindi le risposte torneranno, in modo asincrono. Quando tornano, l'elaborazione deve garantire che non vengano elaborati contemporaneamente da thread separati, che cercherebbero ciascuno di aggiornare lo stato del record "viaggio". Nella messaggistica, questo problema è noto come "problema di correlazione dei messaggi".
Tuttavia, spesso i gruppi di conversazione vengono distribuiti in SSB esclusivamente per motivi di prestazioni:consentono risultati RECEIVE più grandi. Gli endpoint di destinazione possono essere spostati insieme in un gruppo utilizzando MOVE CONVERSATION
ma in pratica c'è un trucco molto più semplice:invertire la direzione della conversazione. Avere la tua destinazione avviare le conversazioni (raggruppate) e la fonte invia i suoi "aggiornamenti" sulle conversazioni avviate dalla destinazione.
Alcune note:
- Non utilizzare il modello di fuoco e dimentica di BEGIN/SEND/END. Stai rendendo impossibile diagnosticare qualsiasi problema in futuro, vedi Fuoco e dimentica:buono per i militari, ma non per le conversazioni con i mediatori di servizio .
- Non utilizzare mai WITH CLEANUP nel codice di produzione. È destinato ad azioni amministrative di ultima istanza come il ripristino di emergenza. Se ne abusi, neghi a SSB qualsiasi possibilità di tracciare correttamente il messaggio per la corretta consegna dei nuovi tentativi (se il messaggio rimbalza sul bersaglio, per qualsiasi motivo, sarà perso per sempre).
- SSB non garantisce l'ordine tra le conversazioni, solo all'interno di una conversazione. L'avvio di una nuova conversazione per ogni evento INSERT non garantisce di preservare, sulla destinazione, l'ordine delle operazioni di inserimento.
