Dequeue Features

The following features apply to dequeuing messages.

Recipients

A message can be retrieved by multiple recipients without the need for multiple copies of the same message. To see this feature applied in the context of the BooksOnLine scenario, refer to "Multiple Recipients".

Designated recipients can be located locally or at remote sites. To see this feature applied in the context of the BooksOnLine scenario, refer to "Local and Remote Recipients".

Navigation of Messages in Dequeuing

Users have several options to select a message from a queue. They can select the first message or once they have selected a message and established a position, they can retrieve the next. The selection is influenced by the ordering or can be limited by specifying a correlation identifier. Users can also retrieve a specific message using the message identifier.

To see this feature applied in the context of the BooksOnLine scenario, refer to "Message Navigation in Dequeue".

Modes of Dequeuing

A DEQUEUE request can either browse or remove a message. If a message is browsed, it remains available for further processing. If a message is removed, it is not available more for DEQUEUE requests. Depending on the queue properties, a removed message may be retained in the queue table.

To see this feature applied in the context of the BooksOnLine scenario, refer to "Modes of Dequeuing".

Optimization of Waiting for the Arrival of Messages

A DEQUEUE can be issued against an empty queue. To avoid polling for the arrival of a new message, a user can specify if and for how long the request is allowed to wait for the arrival of a message.

To see this feature applied in the context of the BooksOnLine scenario, refer to "Optimization of Waiting for Arrival of Messages".

Retries with Delays

A message must be consumed exactly once. If an attempt to dequeue a message fails and the transaction is rolled back, the message will be made available for reprocessing after some user-specified delay elapses. Reprocessing will be attempted up to the user-specified limit.

To see this feature applied in the context of the BooksOnLine scenario, refer to "Retry with Delay Interval".

Optional Transaction Protection

ENQUEUE and DEQUEUE requests are normally part of a transaction that contains the requests, thereby providing the desired transactional behavior. You can, however, specify that a specific request is a transaction by itself, making the result of that request immediately visible to other transactions. This means that messages can be made visible to the external world as soon as the ENQUEUE or DEQUEUE statement is issued or after the transaction is committed.

Exception Handling

A message may not be consumed within given constraints, such as within the window of execution or within the limits of the retries. If such a condition arises, the message will be moved to a user-specified exception queue.

To see this feature applied in the context of the BooksOnLine scenario, refer to "Exception Handling".

Listen Capability (Wait on Multiple Queues)

The listen call is a blocking call that can be used to wait for messages on multiple queues. It can be used by a gateway application to monitor a set of queues. An application can also use it to wait for messages on a list of subscriptions. If the listen returns successfully, a dequeue must be used to retrieve the message.

To see this feature applied in the context of the BooksOnLine scenario, refer to "Listen Capability".

Dequeue Message Header with No Payload

The dequeue mode REMOVE_NODATA can be used to remove a message from a queue without retrieving the payload. Use this mode to delete a message with a large payload whose content is irrelevant.