SQL/MX Queuing and Publish/Subscribe Services

HP NonStop SQL/MX Queuing and Publish/Subscribe Services—523734-002
1-1
1 Introduction
This section introduces Publish/Subscribe concepts, features, and terms.
What Is Publish/Subscribe?
Traditionally, relational database systems are passive data stores. Applications can
only retrieve and update data. Applications cannot request notification when new data
becomes available or when existing data is updated. However, immediate notification
of additions and updates to the database is essential for many applications.
Publish/subscribe is an event-driven mechanism in which a process known as a
subscriber receives notification of a published event from a process known as a
publisher. Queuing differs from publish/subscribe in that one, and only one, subscriber
consumes the published event or message. Queuing and publish/subscribe is often
used in applications in which a process needs to know of the existence of a timely
event, such the availability of a stock at a certain price or the arrival of a parcel at a
particular location.
Queuing and publish/subscribe services allow applications to receive notification of
changes to a database as soon as they occur. Applications might update and retrieve
data, but might need to be notified when data is updated or new data is added.
Publish/subscribe makes it possible to be notified in real time, and at less cost to the
system.
Why Use Publish/Subscribe?
Suppose that you have a system to process new invoices. The invoices are stored in a
table, and a column called PROCESSED indicates unprocessed invoices. An
application processes these new invoices and updates the PROCESSED column to
show they have been processed. After all the invoices have been processed, the
application tries to fetch another unprocessed invoice and receives an end-of-file
condition.
Without publish/subscribe services, this process is more costly. To retrieve new
invoices that are inserted into the table after the end-of-file condition, the application
must close its cursor and reopen it, perhaps after waiting an interval, to see if new
invoices have arrived. This polling requires the closing and reopening of the cursor,
which has significant performance costs. It also requires application code to handle the
looping and end-of-file conditions.
You would probably code this application with an updatable cursor using a selection
predicate to include rows whose PROCESSED column is set to FALSE. You might also
use a positioned UPDATE statement to change the PROCESSED column to TRUE.
The application would need both of these statements to retrieve the information it
needs to process the invoice, and to make sure the invoice is processed only once. As
a result, every invoice would need two calls to the SQL executor, again at the expense