Los grupos de conversación son locales solo concepto, utilizado exclusivamente para el bloqueo:las conversaciones correlacionadas pertenecen a un grupo, de modo que mientras procesa un mensaje en una conversación, otro hilo no puede procesar un mensaje correlacionado. No hay información sobre los grupos de conversación intercambiados por los dos puntos finales, por lo que en su ejemplo, todos los puntos finales del iniciador terminan perteneciendo a un grupo de conversación, pero los puntos finales de destino son cada uno un grupo de conversación distinto (cada grupo tiene solo una conversación). La razón por la que el sistema se comporta así es porque los grupos de conversación están diseñados para abordar un problema como, por ejemplo, un servicio de reserva de viajes:cuando recibe un mensaje para "reservar un viaje", tiene que reservar un vuelo, un hotel y un automóvil. alquiler. Debe enviar tres mensajes, uno a cada uno de estos servicios ('vuelos', 'hoteles', 'coches') y luego volverán las respuestas, de forma asíncrona. Cuando regresan, el procesamiento debe garantizar que no sean procesados simultáneamente por subprocesos separados, cada uno de los cuales intentaría actualizar el estado del registro de 'viaje'. En mensajería, este problema se conoce como "problema de correlación de mensajes".
Sin embargo, a menudo los grupos de conversación se implementan en SSB únicamente por razones de rendimiento:permiten obtener resultados RECIBIR más grandes. Los puntos finales de destino se pueden mover juntos a un grupo usando MOVE CONVERSATION
pero en la práctica existe un truco mucho más sencillo:invertir el sentido de la conversación. Tenga su destino iniciar las conversaciones (agrupadas), y la fuente envía sus 'actualizaciones' sobre las conversaciones iniciadas por el destino.
Algunas notas:
- No utilice el patrón de disparar y olvidar de BEGIN/SEND/END. Está haciendo imposible diagnosticar cualquier problema en el futuro, consulte Despedir y olvidar:bueno para el ejército, pero no para las conversaciones de Service Broker .
- Nunca utilices WITH CLEANUP en el código de producción. Está destinado a la acción administrativa de último recurso, como la recuperación ante desastres. Si abusa, le niega a SSB cualquier posibilidad de rastrear correctamente el mensaje para volver a intentar la entrega correcta (si el mensaje rebota en el objetivo, por cualquier motivo, se perderá para siempre).
- SSB no garantiza el orden entre conversaciones, solo dentro de una conversación. Iniciar una nueva conversación para cada evento INSERT no garantiza conservar, en el destino, el orden de las operaciones de inserción.
