Реферат: MSSQL 2005 (Yukon) – работа с очередями и асинхронная обработка данных
--
CREATE QUEUE [SourceQueue]
CREATE SERVICE [SourceService] ON QUEUE [SourceQueue]
-- Для принимающей стороны так же нужно создать принимающую очередь
-- и принимающий сервис, причем принимающий сервис обязательно
-- должен иметь контракт, хотя для отправляющего это не обязательно
--
CREATE QUEUE [TargetQueue]
CREATE SERVICE [TargetService] ON QUEUE [TargetQueue] ([TestContract])
Все, объекты готовы. Теперь можно приступать собственно к передаче сообщения. В данном примере рассматривается самый простой вариант: из отправляющего сервиса сообщение попадает в очередь получателя и забирается оттуда.
Сначала займемся получателем. Для получения сообщения служит команда RECEIVE, которая сильно напоминает обычный SELECT, только вместо имени таблицы указывается имя очереди. К слову, и команда SELECT для очереди работает (поскольку с точки зрения базы данных очередь – это обычная таблица), показывая ее содержимое, но ничего из нее не удаляя. Команда же RECEIVE выбирает данные из очереди, удаляя выбранные сообщения. Однако если очередь пуста, RECEIVE отработает вхолостую и вернет пустой набор данных, а хотелось бы, чтобы кто-то караулил очередь, и RECEIVE бы срабатывала, как только в очереди что-то появится. К счастью, в этом нет ничего сложного, достаточно обернуть RECEIVE в WAITFOR. Итак, в отдельном окне выполняем следующую команду для своевременного получения сообщения:
| WAITFOR(RECEIVE cast(message_body as nvarchar(MAX)) FROM [TargetQueue]) |
После выполнения этой команды подключение замрет в ожидании сообщения из очереди. Теперь самое время заняться отправителем. У него задачка посложнее, надо начать диалог и передать сообщение с идентификатором открытого диалога.
|
DECLARE @convHandler uniqueidentifier -- началодиалога -- BEGIN DIALOG @convHandler FROM SERVICE [SourceService] TO SERVICE 'TargetService' ON CONTRACT [TestContract]; -- посылкасообщения -- SEND ON CONVERSATION @convHandler MESSAGE TYPE [TestType] (N'Message!!!') -- завершениедиалога -- END CONVERSATION @convHandler |
Если после отправки сообщения вернуться в окошко, где ожидали его получения, можно увидеть, что сообщение успешно получено.
Стоит заметить, что TargetService при создании диалога взят в кавычки, а SourceService – нет. Дело в том, что TargetService может быть создан на совершенно другом сервере, и просто отсутствовать на сервере, где начинается диалог такого сервиса.
Как можно видеть из примера, в каком именно диалоге отправлять сообщение, определяется некой меткой (handler), которая возвращается при создании диалога, и представляет собой GUID. Если ее в какой-то момент потерять, то завершить диалог можно будет только административными методами, узнав этот GUID из служебных представлений (catalog view). Эта же метка приезжает к получателю вместе с сообщением, и выбрав эту метку из очереди, можно отправить сообщение обратно в том же диалоге.