SQL/MX Queuing and Publish/Subscribe Services

Introduction
HP NonStop SQL/MX Queuing and Publish/Subscribe Services—523734-002
1-4
Traditional Implementation of Publish/Subscribe
Traditional Implementation of
Publish/Subscribe
Most transaction processing systems have implemented these services with separate,
special-purpose resource managers. Messaging and queue management systems
allow applications to enqueue and dequeue requests. Publish/subscribe services allow
applications to publish and subscribe to notifications.
Transactions that must access both a queuing and publish/subscribe resource
manager and an SQL database system are very inefficient to run. The resource
manager and the database must participate in an expensive two-phase commit
protocol. Their lack of integration does not allow the SQL compiler to optimize access
to both notifications and SQL data.
Because of these inefficiencies, some SQL database products now have integrated
transactional queuing and publish/subscribe services. These implementations remove
the need for a two-phase commit protocol, but instead require special purpose objects
for queues and publication channels. This solution prevents queues and publication
channels from being accessed as part of SQL SELECT and UPDATE statements and
prevents the SQL compiler from optimizing access to notifications and SQL data.
SQL/MX Implementation of Publish/Subscribe
Publish/subscribe and queuing extensions were added to SQL/MX to:
•
Allow applications to use regular SQL audited tables as transactional queues and
transactional publish/subscribe channels without introducing special objects.
•
Allow applications to use SQL SELECT statements to subscribe or dequeue
notifications.
•
Allow applications to use SQL INSERT and UPDATE statements to publish and
enqueue operations.
•
Remove the need for a two-phase commit protocol.
Queuing,
enqueueing
Inserting entries into a queue by using an INSERT or UPDATE
statement.
Dequeueing Reading and deleting entries with a single operation by using a
SELECT statement with an embedded DELETE or UPDATE. This
dequeue operation is sometimes referred to as a destructive
SELECT. For another description of a destructive SELECT, see
Concepts on page 1-5.
Semi-
queuing
Reading a queue by skipping rows that are locked by another
transaction so that transactions do not block each other.