Sql Server Service Broker Группы бесед - PullRequest
Новая
       10

Sql Server Service Broker Группы бесед

7 голосов
/ 22 августа 2009

Может кто-нибудь объяснить группы разговоров в сервис-брокере?

В настоящее время я использую сервисный брокер для отправки сообщений с одного SQL-сервера на другой. На отправляющем сервере я пытаюсь сопоставить сообщения, чтобы они обрабатывались последовательно на принимающей стороне. Основываясь на документации, кажется, что группы разговоров идеально подходят для этого, но на принимающем сервере сообщения назначаются другой группе разговоров, отличной от той, которую я указал при отправке сообщения.

Я провел поиск по сети и обнаружил, что это поведение, по-видимому, предназначено (http://social.msdn.microsoft.com/forums/en-US/sqlservicebroker/thread/baf48074-6804-43ab-844a-cb28a6dce02b/),, но затем я запутался в полезности синтаксиса из (http://msdn.microsoft.com/en-us/library/ms178624.aspx)

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

Если группа разговоров не сталкивается с сообщением отправителя и сообщения, отправленные с одним и тем же идентификатором группы разговоров, не имеют одинаковый идентификатор группы разговоров на принимающей стороне, какой смысл в приведенном выше коде?

1 Ответ

21 голосов
/ 22 августа 2009

Группы разговоров - это локальные примитивы, используемые для блокировки. Сообщения в группе разговоров не имеют гарантий порядка, а группы бесед не передаются по проводам.

Порядок сообщений гарантируется Service Broker в ходе разговора. Таким образом, чтобы сохранить порядок коррелированных сообщений при обработке, отправьте их в одном разговоре.

Группы разговоров необходимы для группирования бесед, связанных друг с другом. Глаголы GET CONVERSATION GROUP и RECEIVE гарантируют, что они будут блокировать всю группу разговоров, тем самым предотвращая обработку сообщений другими потоками. Например, рассмотрим туристический сайт. Он получает сообщение с просьбой забронировать праздничный пакет. В результате он начинает разговор со службой бронирования отелей и отправляет запрос на бронирование номера, он инициирует разговор со службой бронирования авиабилетов и запрашивает бронирование поездки, он инициирует разговор со службой агентства по прокату автомобилей и просит бронирование автомобиля. Все эти три новых диалога, которые он создал, находятся в одной группе с первоначальным диалогом, в который был получен запрос (приложение использовало условие WITH RELATED_CONVERSATION из BEGIN DIALOG для всех 3 из них). Затем он фиксирует и приступает к обработке сообщений в очереди. Более поздние ответы на эти 3 взаимосвязанных запроса начинают поступать в довольно случайное время. Скажем, в отеле на первом месте. Сообщение принимается приложением, и оно обновляет статус запроса с ответом из отеля. В то же время приходит ответ авиакомпании. Если другой поток сможет его забрать, он попытается обновить статус того же запроса , что и , что приведет к блокировке или даже взаимной блокировке потока. это обрабатывает ответ отеля. Когда ответ отеля обрабатывается, поток фиксирует и, таким образом, разблокирует всю группу разговоров, позволяя любому потоку (включая себя) получить ответ авиакомпании и обработать его.

...