Elements of Advanced Queuing (Native AQ)

By integrating transaction processing with queuing technology, persistent messaging in the form of Advanced Queuing is made possible.

Message

A message is the smallest unit of information inserted into and retrieved from a queue. A message consists of the following:

• Control information (metadata)

• Payload (data)

The control information represents message properties used by AQ to manage messages. The payload data is the information stored in the queue and is transparent to Oracle AQ. A message can reside in only one queue. A message is created by the enqueue call and consumed by the dequeue call.

Queue

A queue is a repository for messages. There are two types of queues: user queues, also known as normal queues, and exception queues. The user queue is for normal message processing. Messages are transferred to an exception queue if they can not be retrieved and processed for some reason. Queues can be created, altered, started, stopped, and dropped by using the Oracle AQ administrative interfaces (see Chapter 9, "Administrative Interface").

Queue Table

Queues are stored in queue tables. Each queue table is a database table and contains one or more queues. Each queue table contains a default exception queue. Figure 7-1, "Basic Queues" shows the relationship between messages, queues, and queue tables.

Agent

An agent is a queue user. This could be an end user or an application.There are two types of agents:

• Producers who place messages in a queue (enqueuing)

• Consumers who retrieve messages (dequeuing)

Any number of producers and consumers may be accessing the queue at a given time. Agents insert messages into a queue and retrieve messages from the queue by using the Oracle AQ operational interfaces (see Chapter 11, "Operational Interface: Basic Operations")

An agent is identified by its name, address and protocol (see "Agent" in Chapter 2, "Basic Components" for formal description of this data structure).

• The name of the agent may be the name of the application or a name assigned by the application. As will be described below, a queue may itself be an agent -- enqueuing or dequeuing from another queue.

• The address field is a character field of up to 1024 bytes that is interpreted in the context of the protocol. For instance, the default value for the protocol is 0, signifying a database link addressing. In this case, the address for this protocol is of the form

  queue_name@dblink
   
  

  where queue_name is of the form [schema.]queue and dblink may either be a fully qualified database link name or the database link name without the domain name.

Recipient

The recipient of a message may be specified by its name only, in which case the recipient must dequeue the message from the queue in which the message was enqueued. The recipient may be specified by name and an address with a protocol value of 0. The address should be the name of another queue in the same database or another Oracle8 database (identified by the database link) in which case the message is propagated to the specified queue and can be dequeued by a consumer with the specified name. If the recipient's name is NULL, the message is propagated to the specified queue in the address and can be dequeued by the subscribers of the queue specified in the address. If the protocol field is nonzero, the name and address field is not interpreted by the system and the message can be dequeued by special consumer (see third party support in the propagation section).

Recipient and Subscription Lists

A single message can be designed for consumption by multiple consumers. There are two ways to do this.

• The enqueuer can explicitly specify the consumers who may retrieve the message as recipients of the message. A recipient is an agent identified by a name, address and protocol.

• A queue administrator can specify a default list of recipients who can retrieve messages from a queue. The recipients specified in the default list are known as subscribers. If a message is enqueued without specifying the recipients the message is implicitly sent to all the subscribers.

Different queues can have different subscribers, and the same recipient can be a subscriber to more than one queue. Further, specific messages in a queue can be directed toward specific recipients who may or may not be subscribers to the queue, thereby over-riding the subscriber list.

Rule

A rule is used to define one or more subscribers' interest in subscribing to messages that conform to that rule. The messages that meet this criterion are then delivered to the interested subscribers. Put another way: a rule filters for messages in a queue on a topic in which a subscriber is interested.

A rule is specified as a boolean expression (one that evaluates to true or false) using syntax similar to the WHERE clause of a SQL query. This boolean expression can include conditions on the following:

• message properties (currently priority and correlation identifier)

• user data properties (object payloads only)

• functions (as specified in the where clause of a SQL query)

Rule Based Subscriber

A rule-based subscriber is a subscriber that has rule associated with it in the default recipient list. A rule-based subscriber is sent a message that has no explicit recipients specified if the associated rule evaluates to TRUE for the message.

Queue Monitor

The queue monitor (QMNn) is a background process that monitors the messages in the queues. It provides the mechanism for message delay, expiration and retry delay. The QMNn also also performs garbage collection for the queue table and its indexes and index-organized tables. It is possible to start a maximum of 10 multiple queue monitors at the same time. You start the desired number of queue monitors by setting the dynamic init.ora parameter aq_tm_processes. The queue monitor wakes up every minute, or whenever there is work to be done, for instance, if a message is to be marked as expired or as ready to be processed.