Читать онлайн «Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ». Страница 150

Элементами на стороне сервера являются:

* один или более триггеров или хранимых процедур, которые выдают оператор

POST_EVENT;

* внутренняя таблица событий - адресат вызовов POST_EVENT - содержит список направленных ей событий процедурами и триггерами во время работы транзакций, при которых возникли события;

* подсистема управления внутренними событиями, которая поддерживает список прослушивающих и ожидающих приложений и работает как "полицейский- регулировщик" для направления соответствующих событий прослушивающим приложениям.

На стороне приложения этому механизму нужно:

* приложение, которое способно зарегистрировать свой интерес в событиях;

* другие приложения, которые выполняют те операции DML, которые прослушивает заинтересованное приложение.

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

При пересылке событий от сервера клиенту используется пара портов, отличная от порта, используемого в главном канале клиент-сервер (обычно порт 3050). Сервер и клиентская библиотека находят произвольную пару портов для использования в качестве трафика событий.

Элементом программного обеспечения является клиентская подпрограмма, называемая функцией обратного вызова события. Это код на клиенте, который вызывается сервером для информирования клиента о событиях, как только подтвердится транзакция, в рамках которой было отправлено ожидаемое событие. Для встроенных приложений предкомпилятор gpre генерирует код для таких функций обратного вызова. Для динамических приложений, которые хотят выполнять прослушивание синхронно (см. следующий раздел), как это делают приложения ESQL, функция обратного вызова содержится в клиентской библиотеке. Динамические приложения могут - и обычно так и делают - прослушивать асинхронно (см. разд. "Асинхронная сигнализация" и "Асинхронное прослушивание"). Для этого они должны предоставить пользовательскую функцию обратного вызова, называемую асинхронным перехватчиком (Asynchronous Trap, AST).

! ! !

СОВЕТ. Если ваша стратегия межсетевой защиты не позволяет приложениям выбирать произвольный порт, Firebird версии 1.5 и выше позволяет специально сконфигурировать такой вспомогательный порт - используйте параметр RemoteAuxPort В firebird.conf.

. ! .

На рис. 32.3 показана модель событий, которая реализована в языке ESQL для встроенных приложений с помощью операторов EVENT INIT и EVENT WAIT. Динамический SQL не имеет эквивалентных операторов SQL. Для приложений динамического SQL та же синхронная модель событий реализована в API с помощью функции isc_wait _for_event().

Приложение ESQL использует EVENT INIT для сообщения, что оно прослушивает событие, и EVENT WAIT, что оно ожидает оповещения. Оно прослушивает оповещение через вспомогательный канал между портами сети, используя главный дескриптор канала соединения с базой данных. Когда вызывается EVENT WAIT, выполнение клиентского приложения приостанавливается, пока не придет сообщение о событии.

Рис. 32.3. Синхронная сигнализация

Клиент в сети посылает изменение строки таблицы MYTABLE. Его принимает и обрабатывает сервер. В процессе фазы AFTER UPDATE триггер посылает сообщение с именем big_event для оповещения менеджера событий, что изменение завершено.

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

При выполнении COMMIT менеджер событий посылает процессу x и всем другим процессам, ожидающим событие big_event, оповещение, что big_event произошло. Даже если транзакция много раз отправляла big event, ожидающие клиенты получат одно оповещение.

Если ни один процесс не зарегистрировал интерес в big_event, менеджер событий просто игнорирует POST_EVENT. Все процессы, к настоящему моменту выдавшие EVENT_WAIT для big_event, получат оповещение немедленно. Если какой-нибудь процесс зарегистрировал свой интерес в big_event, но не ожидает этого события, менеджер событий оставляет это событие, пока процесс либо не просигнализирует об ожидании, либо не отменит свой интерес. Если заинтересованные приложения потеряют интерес, событие big_event будет удалено из этой таблицы.

Приложение может ожидать не более 15 событий в одном запросе EVENT INIT. Оно может распределить события между несколькими запросами EVENT INIT, однако в случае синхронизированных событий оно может ожидать обработки только одного запроса EVENT INIT В каждый момент времени.

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

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

Приложение для биржи, например, требует постоянного доступа к базе данных STOCKS для обеспечения брокеров в реальном времени информацией об изменении цен, однако оно также должно постоянно просматривать отдельные акции и переключать соответствующую процедуру Buy (купить) или sell (продать) при появлении некоторых событий.

Приложения DSQL используют вызовы API для прослушивания событий как синхронных, так и асинхронных. В DSQL не существует для них эквивалентов, а установка для интерфейсов приложений сырых составных частей является довольно сложной.

Приложение регистрирует интерес в событиях с помощью буфера параметров событий (Events Parameter Buffer, EPB), который заполняется при вызове функции isc_event_block(). Один EPB может регистрировать не более 15 событий, задавая различные EPB и список событий для каждого вызова. Именованные события должны соответствовать (с учетом регистра) событиям, которые будут отправлены. Приложения, которым нужно отвечать более чем на 15 событий, могут выполнить несколько вызовов isc_event_block().

Установка синхронного прослушивания через API похожа на то, что вы должны сделать для асинхронной сигнализации за исключением того, что при этом вызывается

функция isc_wait_for_event() вместо isc_que_event(). Как и в случае с эквивалентом в ESQL, EVENT WAIT, выполнение программы приостанавливается на время ожидания. Функция isc_wait_for_event() прослушивает оповещение, которое появится, когда сервер выполнит функцию обратного вызова.

Прежде чем вы сможете использовать функцию сигнализации API isc_que_evento, вам нужно выполнить функцию обратного вызова на клиенте, которую вызывал бы сервер при посылке события. Названием для такого типа функции является асинхронный перехват, или AST.

Функция AST предоставляет некоторую форму глобальных флагов для оповещения приложения, когда к нему обращается сервер. Она обрабатывает список событий сервера в буферах, к которым приложение может иметь доступ при управлении собственной очередью событий. Функция должна получать три аргумента:

* копию списка отправленных событий;

* длину буфера events_list;

* указатель на буфер events_iist.

Документ InterBase API Guide[128] содержит рекомендации по написанию функций AST.

Функция isc_event_biock() принимает в своем параметре isc caiiback указатель на функцию AST и в своем параметре event_function_arg- указатель на первый аргумент AST. Этот аргумент обычно получает значение счетчика событий, когда они изменяются.

Когда приложение вызывает функцию isc_que_events о для сообщения о событиях, которые оно будет ожидать, оно передает вместе со списком указатель на функцию обратного вызова AST. Один вызов isc_que_events() может содержать до 15 событий. Приложение вызывает функцию isc_event_counts() для определения того, какое событие произошло.

Множество вызовов isc que eventso может выполняться одновременно в одном процессе клиент-сервер. Приложения отключают режим ожидания при вызове функции isc_cancel_events().

! ! !

ПРИМЕЧАНИЕ. Подробности установки блока событий для синхронного прослушивания через isc_event_wait() такие же. События не являются постоянными, как при асинхронной технике isc_que_events(). Синхронная сигнализация не требует внешней функции AST.

. ! .

К счастью, почти для всех из нас фрагменты кодов для реализации событий в клиентских приложениях инкапсулированы в классах и компонентах в большинстве инструментов разработки приложений, которые поддерживают Firebird. Такие компоненты, включающие в себя AST, инкапсулирующие вызовы функций API isc_event* вместе с блоками параметров событий и управление буферами событий на клиентской стороне, обычно называются обработчиками сообщений (event alerter). Иногда этот термин в форумах и литературе вызывает путаницу, потому что триггеры и хранимые процедуры, вызывающие POST_EVENT, также часто называют обработчиками сообщений.