Аннотация:
Как правило, приложение, в ходе своей работы, последовательно выполняет набор команд, и даже если необходимо обратиться к другому приложению, то оно покорно ожидает ответа. Однако множество самых различных приложений могут выполнять несколько кусочков своей работы одновременно или же отдавать на выполнение часть своей работы другим приложениям, забирая результаты обратно по мере готовности, это в том случае, если есть необходимость забирать результат, а то можно и вовсе отдать и забыть. Такой стиль работы, в дальнейшем будем называть его асинхронным, может сделать приложение более масштабируемым, производительным и доступным, словом сплошная польза и почти никакого вреда, и чем больше приложение, тем больше пользы от такого подхода. Причиной же засилия синхронных приложений, при всех очевидных премуществах асинхронных, является очень высокая трудоемкость написания последних.
В процессе разработки следующей версии SQL Server-а, ожидаемую с большим нетерпением, Microsoft решил немного исправить эту ситуацию и реализовать некий набор механизмов, позволяющий не писать каждый раз фреймворк по асинхронной работе, а заниматься непосредственно разработкой асинхронных приложений решающих насущные задачи.
Как наверное уже известно, основная функциональность, обеспечивающая асинхронность и работу с очередями в новой версии SQL Server, реализована с помощью некоего сервиса для работы с сообщениями под названием Service Broker. Но в данной статье речь пойдет не совсем о нем (он сам по себе может являться темой не одной статьи), а скорее о способах его (и не только его) использования для асинхронной обработки данных вообще и обработки очередей в частности. Иными словами, о том, какими способами можно сделать работу с данными чуть более асинхронной, и как в этом может помочь SQL Server 2005 совместно с ADO.Net 2.0.
Мы уже победили, просто это еще не так заметно...
Re: MSSQL 2005 (Yukon) – работа с очередями и асинхронная об
Небольшой вопрос про создание SqlDependency.
Вот фрагмент кода из статьи, описывающий пррмер работы с данным классом:
using (SqlConnection connection = new SqlConnection(
"Data Source=localhost\\ctpapril;Initial Catalog=cavy;"
+ "Integrated Security=SSPI;"))
{
SqlCommand cmd = new SqlCommand("SELECT ID, [Time], Data FROM dbo.AsyncTest", connection);
// создаем объект SqlDependency, и регистрируем его в SqlCommand
//
SqlDependency depend = new SqlDependency(cmd);
// подписываем обработчик события на оповещение об изменениях в
// результатах запроса, выполненного через SqlCommand
depend.OnChange += new OnChangeEventHandler(OnDataChange);
connection.Open();
SqlDataReader rdr = cmd.ExecuteReader();
while (rdr.Read())
Console.WriteLine(rdr[0] + "\t" + rdr[2] + "\t" + rdr[1]);
}
Вопрос в том, необходимо ли создавать объект SqlDependency _перед_ открытием соединения? Перед выполнением команды? Или можно в любой момент, пока есть ссылка на SqlCommand?
Здравствуйте, _FRED_, Вы писали:
_FR>Вопрос в том, необходимо ли создавать объект SqlDependency _перед_ открытием соединения? Перед выполнением команды? Или можно в любой момент, пока есть ссылка на SqlCommand?
Необходимо его создать и присвоить объекту SqlCommand перед выполнением команды, то есть перед посылкой запроса на сервер. Механизм отслеживания изменений включается именно в момент выполнения запроса, после этого, если механизм не включился, сервер уже не знает кто и что у него запрашивал...
... << RSDN@Home 1.1.4 beta 7 rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[3]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
Здравствуйте, Merle, Вы писали:
M>Необходимо его создать и присвоить объекту SqlCommand перед выполнением команды, то есть перед посылкой запроса на сервер. Механизм отслеживания изменений включается именно в момент выполнения запроса, после этого, если механизм не включился, сервер уже не знает кто и что у него запрашивал...
Спасибо. А без Notification Services данный механизм работать будет?
Здравствуйте, _FRED_, Вы писали:
_FR>Спасибо. А без Notification Services данный механизм работать будет?
Конечно будет, на Notification Services он не завязан никак.
Он не будет работать без Service Broker-а и без включенной поддержки .Net процедур на сервере...
Мы уже победили, просто это еще не так заметно...
Re[5]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
Здравствуйте, Merle, Вы писали:
_FR>>Спасибо. А без Notification Services данный механизм работать будет? M>Конечно будет, на Notification Services он не завязан никак.
Ещё раз спасибо Слегка смутили названия классов SqlNotification*.
M>Он не будет работать без Service Broker-а и без включенной поддержки .Net процедур на сервере...
Здравствуйте!
Попробовал один из ваших примеров ( там где через SqlDependency сервер сам извещает клиентское приложение о том, что произошли некие изменения... ) и вот на какой момент обратил внимание.
Если мы меняем запись в БД в первый раз, то всё работает.
А на все последующие изменения — ноль реакции.
Почему так и что делать, чтобы сервер всегда извещал клиентское приложение о любых изменениях?
Re[2]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
Здравствуйте, <Аноним>, Вы писали:
А>Почему так и что делать, чтобы сервер всегда извещал клиентское приложение о любых изменениях?
By design. Оповещение при изменении производится только один раз, потом надо перезапрашивать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[3]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
От:
Аноним
Дата:
09.02.06 11:17
Оценка:
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>Почему так и что делать, чтобы сервер всегда извещал клиентское приложение о любых изменениях? M>By design. Оповещение при изменении производится только один раз, потом надо перезапрашивать.
Уже разобрался. Перезапрашивать не нужно. Проблема была очень смешной, но пришлось полдня убить, чтобы разобраться
ReadLine! ))
Re: MSSQL 2005 (Yukon) – работа с очередями и асинхронная об
Статья очень интересная, спасибо.
У меня вопрос в связи с прочитанным. Необходимо выполнить процедуру на нескольких базах (процедура хранимая, индентичная в каждой из баз), находящихся на разных серверах, которая возвращает набор данных. Далее на основе полученных данных собрать сводную таблицу, по которой сдеалать отчет с требуемыми группировками.
Т.е. есть центральная база (офис) и ряд идентичных баз (филиалы). Офис желает иметь сводный отчет по всем филиалам. Размеры баз разные,процедура работает разное кол-во времени в зависимости от объемов конкретной базы.Если последовательно запускасть процедуру по всем серверам, время получения отчета лишает его всякой оперативности (серверов min 10, исполнение от 1-5 минут). Поэтому хочется иметь параллельную обработку.
Можно ли для решения такой задачки воспользоваться новыйми возможностями ms sql 2005 в частности SSB.И возможен ли такой вариант решения, чтобы логика параллельной обработки была сосредоточена на сервере офиса, а клиент только инициировал команду получения сводного отчета?
Судя по статье, видимо да. А просветить можете детальнее этот вопрос, и, конечно бы скелетик программки увидеть, если это возможно и не сильно нагло.
Re[2]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
Здравствуйте, <Аноним>, Вы писали:
А>Можно ли для решения такой задачки воспользоваться новыйми возможностями ms sql 2005 в частности SSB.
В принципе можно... На всех клиентах запускается асинхронное выполнение процедуры, сервер ждет результатов, получает и обрабатывает.
А> А просветить можете детальнее этот вопрос, и, конечно бы скелетик программки увидеть, если это возможно и не сильно нагло.
Ну, это уж как-нибудь сам, в статье все для этого есть...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[5]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
Здравствуйте, Ash-2, Вы писали:
A2>В Express Service Broker включен?
ограничено.
A2>Здесь говорится, что только для "избранных". A2>Может кто знает, как попасть в число "избранных" ?
Не для избраных, а только в качестве подписчика. Иными словами, два express-а между собой SB использовать не смогут, а express и нормальный сервер — смогут.
Мы уже победили, просто это еще не так заметно...
Re[7]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
Здравствуйте, IB, Вы писали:
IB>Не для избраных, а только в качестве подписчика. Иными словами, два express-а между собой SB использовать не смогут, а express и нормальный сервер — смогут.
да-а-а-а-а-а что-то меня заглючило.
Спасибо.
Re[8]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
От:
Аноним
Дата:
12.07.07 15:08
Оценка:
Здравствуйте.
Статья очень хорошо написана, спасибо...
однако вопрос по приведенному примеру....
очередь [TargetQueue] всегда пустая....
Выполняю
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
однако как ожидалось "...Если после отправки сообщения вернуться в окошко, где ожидали его получения, можно увидеть, что сообщение успешно получено."
ничего не происходит... и очередь пуста, при этом
select * FROM sys.conversation_endpoints
возвращает conversation со статусом DO Disconnected outbound
Подскажите, что не так?
Re[9]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
От:
Аноним
Дата:
13.07.07 13:39
Оценка:
..нашёл...
если контракт объявить как SENT BY INITIATOR , то всё получается
Re: MSSQL 2005 (Yukon) – работа с очередями и асинхронная об
IB>Авторы: IB> Ivan Bodyagin
IB>Аннотация: IB>Как правило, приложение, в ходе своей работы, последовательно выполняет набор команд, и даже если необходимо обратиться к другому приложению, то оно покорно ожидает ответа. Однако множество самых различных приложений могут выполнять несколько кусочков своей работы одновременно или же отдавать на выполнение часть своей работы другим приложениям, забирая результаты обратно по мере готовности, это в том случае, если есть необходимость забирать результат, а то можно и вовсе отдать и забыть. Такой стиль работы, в дальнейшем будем называть его асинхронным, может сделать приложение более масштабируемым, производительным и доступным, словом сплошная польза и почти никакого вреда, и чем больше приложение, тем больше пользы от такого подхода. Причиной же засилия синхронных приложений, при всех очевидных премуществах асинхронных, является очень высокая трудоемкость написания последних. IB>В процессе разработки следующей версии SQL Server-а, ожидаемую с большим нетерпением, Microsoft решил немного исправить эту ситуацию и реализовать некий набор механизмов, позволяющий не писать каждый раз фреймворк по асинхронной работе, а заниматься непосредственно разработкой асинхронных приложений решающих насущные задачи. IB>Как наверное уже известно, основная функциональность, обеспечивающая асинхронность и работу с очередями в новой версии SQL Server, реализована с помощью некоего сервиса для работы с сообщениями под названием Service Broker. Но в данной статье речь пойдет не совсем о нем (он сам по себе может являться темой не одной статьи), а скорее о способах его (и не только его) использования для асинхронной обработки данных вообще и обработки очередей в частности. Иными словами, о том, какими способами можно сделать работу с данными чуть более асинхронной, и как в этом может помочь SQL Server 2005 совместно с ADO.Net 2.0.
Еще одно замечание, если в BEGIN DIALOG указать параметр WITH ENCRYPTION = OFF, то пример с Service Broker работает нормально, иначе очередь не получает сообщения.
Пример:
BEGIN DIALOG @convHandler
FROM SERVICE [ScoutWeekReportourceService]
TO SERVICE 'ScoutWeekReportTargetService'
ON CONTRACT [ReportRequestContract]
WITH ENCRYPTION = OFF;
Re[2]: MSSQL 2005 (Yukon) – работа с очередями и асинхронная
Здравствуйте, selagin, Вы писали:
S>Еще одно замечание, если в BEGIN DIALOG указать параметр WITH ENCRYPTION = OFF, то пример с Service Broker работает нормально, иначе очередь не получает сообщения.
Чтобы работало и без ENCRYPTION = OFF, надо создать master key на сервере. Статья писаласть еще по beta версии, там все работало и без этого, потребность создавать ключь или отключать encription появилясь только в релизе.
Мы уже победили, просто это еще не так заметно...
Слегка смутили названия классов SqlNotification*.
