Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Клиентские подсистемы, которые запрашивают у сервера новости об изменениях состояния базы данных, не являются редкостью в мире реляционных подсистем баз данных. Однако модель сообщения о событиях в Firebird не расходует ресурсов сети или процессора при опросе. Это является подсистемой сервера, которая поддерживается сервером и на сервере. Клиент "регистрирует интерес" в событии и сигнализирует, что он ждет этого события.

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

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

Эти возможности безграничны в терминах масштаба и приложения. Некоторыми примерами являются:

* сервисы фоновой репликации данных запрашивают новый элемент;

* приложение продажи билетов использует эту схему в качестве сигнала для обновления открытых наборов данных в других офисах, когда происходит изменение выделенных мест или расписания;

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

* розничные магазины информируются о загрузке нового прайс-листа;

* устройство слежения за механическим процессом сигнализирует о низком уровне запасов сырья.

Инициаторами событий являются операции изменения состояния базы данных - успешно выполненные операции INSERT, UPDATE и DELETE. Сигнализация о событии выполняется в триггерах или хранимых процедурах с помощью оператора PSQL

POST_EVENT.

Однако POST EVENT является только одним элементом этого механизма- изолированно он ничего не делает. Это просто посылка сигнала слушающим приложениям. Он не несет никакой информации, о каком событии базы данных он сигнализирует; задачей приложения является обеспечение собственного контекста для каждого события.

Сам механизм событий состоит из нескольких взаимодействий между серверной стороной и приложением.

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

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

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 будет удалено из этой таблицы.