Understanding the Event Mechanism

From InterBase
Jump to: navigation, search

Go Up to Working with Events

The InterBase event mechanism consists of four parts:

  • The InterBase engine that maintains an event queue and notifies applications when an event occurs.
  • Event parameter buffers set up by an application where it can receive notification of events.
  • An application that registers interest in one or more specified, named events and either waits for notification to occur (synchronous event), or passes a pointer to an AST function that handles notifications so that application processing can continue in the meantime (asynchronous event).
  • A trigger or stored procedure that notifies the engine that a specific, named event has occurred. Notification is called posting.

The InterBase event mechanism enables applications to respond to actions and database changes made by other, concurrently running applications without the need for those applications to communicate directly with one another, and without incurring the expense of CPU time required for periodic polling to determine if an event has occurred.

For information about creating triggers and stored procedures that post events, see the Data Definition Guide.


Event Parameter Buffers

If an application is to receive notification about events, it must set up two ­identically-sized event parameter buffers (EPBs) using isc_event_block(). The first buffer, event_buffer, is used to hold the count of event occurrences before the application registers an interest in the event. The second buffer, result_buffer, is subsequently filled in with an updated count of event occurrences when an event of interest to the application occurs. A second API function, ­isc_event_counts(), determines the differences between item counts in these buffers to determine which event or events occurred.

For more information about setting up and using EPBs, see Creating EPBs with isc_event_block( ).


Synchronous Event Notification

When an application depends on the occurrence of a specific event for processing, it should use synchronous event notification to suspend its own execution until the event occurs. For example, an automated stock trading application that buys or sells stock when specific price changes occur might start execution, set up EPBs, register interest in a set of stocks, then suspend its own execution until those price changes occur.

The isc_wait_for_event() function provides synchronous event handling for an application. For more information about synchronous event handling, see Waiting on Events with isc_wait_for_event().


Asynchronous Event Notification

When an application needs to react to possible database events, but also needs
to continue processing whether or not those events occur, it should set up an asynchronous trap (AST) function, and use asynchronous event notification to register interest in events while continuing its own processing. For example, a stock brokering application requires constant access to a database of stocks to allow a broker to buy and sell stock, but, at the same time, may want to use events to alert the broker to particularly significant or volatile stock price changes.

The isc_que_events() function and the AST function provide asynchronous event handling for an application. For more information about asynchronous event handling, see Continuous Processing with isc_que_events().


Transaction Control of Events

Events occur under transaction control, and can therefore be committed or rolled back. Interested applications do not receive notification of an event until the transaction from which the event is posted is committed. If a posted event is rolled back, notification does not occur.

A transaction can post the same event more than once before committing, but regardless of how many times an event is posted, it is regarded as a single event occurrence for purposes of event notification.

Advance To: