Здесь ‘current database’ – это константа, которая
говорит о том, что в качестве механизма доставки будет использоваться экземпляр
Service Broker-а, установленный в текущей базе. Указание этого экземпляра является
необходимым параметром при создании уведомления.
Вот, в общем-то, и все. Теперь осталось только
получить красивый XML из очереди после очередного входа/выхода из системы и
придумать, что с ним делать. Получить его можно все тем же, уже знакомым способом:
|
RECEIVE
cast(message_body as xml) FROM [LoginQueue]
|
Сам XML представляет собой результат вызова той же
самой функции Eventdata(), что используется и в DDL-триггерах.
Комбинируя рассмотренную функциональность, можно
добиться довольно причудливого поведения, например, активируя очередь, по
таймеру проверять загрузку процессора и занимаемую сервером память. И если
нагрузка на сервер достаточно низка, то отсылать другое сообщение, которое
приведет к запуску долгой расчетной процедуры...
Асинхронные возможности клиентских приложений
Теперь самое время рассмотреть подробнее, какие
возможности для работы с базой данных в асинхронном режиме есть у клиентского
приложения.
Как можно было убедиться из предыдущих примеров, отправить задание на выполнение кому-то другому – это полдела, надо еще вовремя
получить извещение о том, что асинхронная операция закончена. При разработке
механизмов взаимодействия клиента с сервером этому вопросу было уделено должное
внимание.
Асинхронное выполнение запросов
Помимо выполнения асинхронных операций на сервере и
работы с очередями, в ADO.Net 2.0 добавлена специальная функциональность по
асинхронной работе с БД со стороны клиента. Эта функциональность поддерживается
только провайдером SqlClient (OleDB и остальные его не поддерживают). Зато
(приятная новость) со стороны сервера жестких ограничений нет, и асинхронные
запросы будут работать с SQL Server от Microsoft, начиная с седьмой версии, при
условии, что режим работы с ними – не Shared Memory, а операционная система –
Windows 2000/XP/2003.
Строго говоря, и в предыдущей версии Framework-а
организация асинхронной обработки данных не была такой уж большой проблемой.
Однако при этом приходилось выделять дополнительный поток и блокировать его в
ожидании выполнения запроса. Для клиентских приложений это не представляет
большой проблемы, но для серверных решений, вынужденных обслуживать множество
клиентов одновременно, это может послужить источником неприятностей. Вся же
прелесть данной реализации заключается в том, что дополнительный поток не
создается. Вместо этого для достижения должного эффекта используются
возможности асинхронного сетевого ввода/вывода. Вместо того, чтобы создавать
новый поток и заставлять его ждать синхронной операции ввода/вывода для
отправки запроса в БД и получения ответа, используются асинхронные возможности
сетевого протокола Windows 2000/XP/2003 (с этим и связаны ограничения на
использование ОС и режима Shared Memory для версий сервера ниже SQL 2005), позволяющие одному потоку отослать запрос и идти дальше по своим делам.
Для выполнения запросов в асинхронном режиме
разработчики добавили несколько методов, однако придерживались минималистской
политики, и добавили лишь самые необходимые методы. Поэтому далеко не все
синхронные варианты Execute* обзавелись асинхронными аналогами, точнее, только
три из них. Это ExecuteReader, получивший BeginExecuteReader и
EndEsecuteReader, ExecuteNonQuery, получивший BeginExecuteNonQuery и
EndExecuteNonQuery, и ExecuteXmlReader, получивший, как не сложно догадаться
BeginExecuteXmlReader и EndExecuteXmlReader. Предполагается следующая схема
применения этого богатства: метод Begin* получает все входные параметры и
передает их для исполнения серверу, оставляя после себя потоку на память лишь
некий объект, реализующий специальный интерфейс по имени IAsyncResult. Этот
интерфейс может быть использован для отслеживания состояния выполнения
операции. Из метода же End* с помощью этого оставленного объекта можно получить
обратно результат выполнения запроса, когда тот будет готов.
|
СОВЕТ
Интерфейс IAsyncResult далеко не нов, как и сопутствующие методы синхронизации. Вся эта механика должна быть хорошо
знакома тем, кто сталкивался с асинхронными делегатами, асинхронной работой с
файлами и другими многопоточными задачами в .Net.
|
Одним из ключевых моментов при выполнении асинхронных
операций является способ, с помощью которого инициатор операции может узнать о
ее завершении. Для столь ответственного мероприятия ADO.Net предоставляет целых
три способа:
Рекомендуем скачать другие рефераты по теме: рефераты на казахском языке, реферат на тему время.
Предыдущая страница реферата |
4
5
6
7
8
9
10
11
12
13
14 |
Следующая страница реферата
Главная