Servidor Sql Service Broker Grupos de conversación

Question

¿Alguien puede explicar grupos de conversación en el agente de servicios?

Actualmente, estoy usando service broker para enviar mensajes de un servidor SQL a otro. En el servidor de envío, intento correlacionar los mensajes para que se procesen en serie en el lado de recepción. Según la documentación, los grupos de conversación parecen ser los más adecuados para esto, pero en el servidor receptor, los mensajes se asignan a un grupo de conversación diferente al especificado al enviar el mensaje.

Tengo buscar en la web y vi que este comportamiento parece estar previsto (http://social.msdn.microsoft.com/forums/en-US/sqlservicebroker/thread/baf48074-6804-43ab-844a-cb28a6dce02b/), pero entonces estoy confundido acerca de la utilidad de la sintaxis de (http://msdn.microsoft.com/en-us/library/ms178624.aspx)

WAITFOR( 
    GET CONVERSATION GROUP @conversation_group_id FROM [dbo].[ReceiveQueue] 
) 

Si la conversación el grupo no se encuentra con el mensaje del remitente y los mensajes enviados con el mismo ID de grupo de conversación no tienen la misma identificación de grupo de conversación en el lado de recepción, ¿cuál es el punto del código anterior?

Answer 1

Los grupos de conversación son primitivos locales utilizados para el bloqueo. Los mensajes dentro de un grupo de conversación no tienen garantías de pedido, y los grupos de conversación no fluyen a través del cable.

La orden de los mensajes está garantizada por Service Broker dentro de una conversación. Por lo tanto, para conservar el orden de los mensajes corrleated en el proceso, envíelos en la misma conversación.

Los grupos de conversación son necesarios para agrupar un conjunto de conversaciones que están relacionadas entre sí. Los verbos GET CONVERSATION GROUP y RECEIVE garantizan que bloquearán un grupo completo de conversores, impidiendo que cualquier otro hilo procese mensajes relacionados. Por ejemplo, considere un sitio de viaje. Recibe un mensaje con una solicitud para reservar un paquete de vacaciones. Como resultado, inicia una conversación con un servicio de reserva de hotel y envía una solicitud para reservar una habitación, inicia una conversación con un servicio de reserva de avión y solicita una reserva de viaje, inicia una conversación con un servicio de agencia de alquiler de automóviles y solicita un reserva de coche Estas tres nuevas conversaciones que creó están todas en el mismo grupo con la conversación inicial en la que se recibió la solicitud (la aplicación ha utilizado la cláusula WITH RELATED_CONVERSATION de BEGIN DIALOG en las 3). A continuación, confirma y procesa los mensajes en la cola. Las respuestas posteriores de estas 3 solicitudes correlacionadas comienzan a aparecer, en momentos prácticamente aleatorios. Digamos que la respuesta del hotel es lo primero. El mensaje es recogido por la aplicación y continúa para actualizar el estado de la solicitud con la respuesta del hotel. Al mismo tiempo, la respuesta de la línea aérea entra. Si se permite que otro subproceso lo recoja, intentaría actualizar el estado de la misma solicitud , lo que da como resultado bloqueo o incluso interbloqueo contra el subproceso que está procesando el respuesta del hotel Cuando se procesa la respuesta del hotel, el hilo se compromete y, por lo tanto, desbloquea todo el grupo de conversación, lo que permite que cualquier hilo (incluido él mismo) recoja la respuesta de la línea aérea y la procese.