• Статья

Основные сведения об условиях возникновения активации

Процесс активации компонента Service Broker состоит из двух этапов. Сначала компонент Service Broker определяет, является ли активация необходимой. Затем компонент Service Broker определяет тип выполняемой активации. Для внутренней и внешней активации применяются различные процессы, но для обеих стратегий действуют общие принципы.

Определение необходимости активации

Активация является необходимой, если для нового агента чтения очереди может появиться полезная работа. Наблюдение за очередями определяют, является ли активация необходимой. Компонент Service Broker создает наблюдение для каждой очереди, в которой активация имеет параметр STATUS = ON или для которой было зарегистрировано уведомление о событии QUEUE_ACTIVATION. Динамическое административное управление sys.dm_broker_queue_monitors (Transact-SQL) содержит список мониторов очередей, активных в экземпляре. Каждый монитор очереди отслеживает следующие факты.

Содержит ли очередь сообщения, готовые к получению

Сколько времени прошло с тех пор, когда инструкция RECEIVE возвратила пустой результирующий набор

Сколько хранимых процедур активации в настоящий момент запущено для очереди.

Монитор очереди проверяет необходимость активации каждые несколько секунд, а также если происходит одно или несколько из следующих событий:

  • в очередь прибывает новое сообщение;

  • SQL Server выполняет для очереди инструкцию RECEIVE;

  • выполняется откат транзакции, содержащей инструкцию RECEIVE;

  • завершают работу все хранимые процедуры, запущенные монитором очереди;

  • SQL Server выполняет для очереди инструкцию ALTER.

Активация является необходимой, если верно одно из следующих условий.

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

  • Очередь содержит непрочитанные сообщения, отсутствует ожидающий сеанс в инструкции GET CONVERSATION GROUP или инструкции RECEIVE без предложения WHERE, а инструкция GET CONVERSATION GROUP или инструкция RECEIVE без предложения WHERE в течение нескольких секунд возвращала пустой результирующий набор. Иными словами, сообщения накапливаются в очереди, поскольку активируемые процедуры не успевают их считывать.

Эта процедура фактически позволяет монитору очереди определить, достаточно ли число агентов чтения очереди, обрабатывающих очередь, для обработки входящих сообщений. Обратите внимание, что в этом методе учитывается блокировка группы сообщений. Поскольку сообщения для диалога в каждый момент времени может обрабатывать только один агент чтения очереди, запуск агентов чтения очереди в ответ на более простые признаки, например количество непрочитанных сообщений в очереди, может привести к напрасной трате ресурсов. Вместо этого в активации компонента Service Broker определяется, будет ли агент чтения очереди иметь некоторый объем полезной работы.

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

Определение типа активации

После того как компонент Service Broker определил, что активация необходима, он должен решить, какая активация будет применяться.

Для внутренней активации монитор очереди активирует новый экземпляр хранимой процедуры активации, когда число выполняющихся программ меньше, чем значение MAX_QUEUE_READERS, заданного для очереди. Если число выполняющихся программ равно значению MAX_QUEUE_READERS или превышает его, то монитор очереди не запускает новый экземпляр хранимой процедуры. Административное представление sys.dm_broker_activated_tasks (Transact-SQL) содержит сведения о хранимых процедурах, запущенных компонентом Service Broker.

Для внешних приложений компонент Service Broker не обладает данными о количестве различных агентов чтения очереди, которые могут работать с очередью. Более того, между временем создания события активации и временем, когда агент чтения приступает к чтению очереди, может пройти некоторое время, необходимое для запуска агента. Поэтому компонент Service Broker в течение некоторого времени ожидает ответа внешнего приложения. Во время ожидания компонент Service Broker не будет создавать дополнительные уведомления. После того как приложение вызывает для очереди инструкцию RECEIVE или истекает время ожидания, компонент Service Broker создает еще одно уведомление о событии, если необходима активация. Внешнее приложение отслеживает уведомления о событиях во время работы программы, чтобы определить, требуются ли для чтения событий дополнительные агенты чтения очереди.