The following sections provide an overview to the Oracle Tuxedo Message Queue product:
The Oracle Tuxedo Message Queue (OTMQ) component improves and enhances the Oracle Tuxedo queuing services. Besides the existing queuing features of the Oracle Tuxedo /Q component, the OTMQ also provides richer queuing features, such as Reliable Message Delivery, Synchronous/Asynchronous Messaging, Publish/Subscribe, Message Filtering, Dynamic Queue Alias (Naming), Journal, etc. Also since the OTMQ was implemented based on the Oracle Tuxedo infrastructure, it can provide supports on transaction, security, scalability and HA.
The following sections provide an overview of OTMQ features:
Oracle OTMQ can have multiple attributes, which define its behaviors. For more information, see
tmqadmin() in the .
According to the life cycle of queues, the queue types can be:
The permanent queue must be pre-allocated. The permanent queue has active property defined as permanent or temporary. The permanent active queue can always receive and store messages even there is no application attaching to it, unless storage quota is exceeded. The temporary active queue can only receive and store messages when it is attached by application. The permanent queue is created by
The permanent queue should be specified as one of the following types when being created:
The primary queue acts as the main mailbox for a user process to receive messages from other processes. It can be attached by only one queue client. An application can have only one primary queue, although it may associate with queues of other types.
The secondary queue acts as an alternate mailbox for a user process to receive messages. An application owns the secondary queue by attaching to it. When an application attaching to a primary queue that is the owner of the secondary queue, the application is automatically attached to the secondary queue at the same time. When the application detaching from its primary queue, all secondary queues associated will be detached too.
The multi-reader queue is pre-allocated. It can be attached by multiple queue clients at the same time.
The unlimited queue's behavior is totally same as the traditional Tuxedo /Q queue. An application need not attach the unlimited queue to dequeue from it.
The temporary queue is created at runtime when an application requests to attach a temporary queue. The process attaching to the temporary queue is the owner of this queue, and no other processes can attach or receive messages from this queue. Once the application detaches from the temporary queue, all the messages left in this queue will be deleted. The temporary queue count and range are specified by tmqadmin() qspacecreate command.
Oracle OTMQ provides reliable message delivery, which can make sure the message be delivered to the receiver successfully.
For more information, see Using Recoverable Messaging in the.
Delivery Interest Point (DIP) is the checkpoint during the message delivery. When a message passes the specified checkpoint, an ACK notification message is returned to the sender application to indicate the message delivery status.
Oracle OTMQ supports following DIPs:
Oracle OTMQ applications can enqueue/send messages in the following modes:
The application waits for acknowledgement after sending messages to target. Also the application can choose to wait until the message is sent to specific Delivery Interest Points.
The application doesn't wait after sending messages, but should explicitly call
tpdeqplus(3c) to get ACK notification message to verify if the message has been successfully delivered to target.
The application does not wait after sending messages, also doesn't expect any acknowledge messages. This mode is for performance sensitive scenarios.
Undelivered Message Action (UMA) means the action when the message sender receives a failure acknowledgment notification.
If Reliable Message Delivery is enabled, UMA means the action when the message fails to be stored in the SAF/DQF storage.
Otherwise, UMA means the action when the message fails to be delivered.
The valid Oracle OTMQ UMA options are listed in following table.
Messages are read from queues in FIFO order unless another order is defined for the queue. Oracle OTMQ also provides message filter that allow user to read message that matching the selection criteria defined by the message filter. For more information, see Using Filter in the.
The publish-and-subscribe capability sends a message to multiple recipients registered to receive information from a message broadcasting stream. It is the asynchronous routing of events among the message queuing clients and servers.
Oracle OTMQ application can send a broadcast message using the standard
tpqpublish () function. The sending application can generate broadcast messages without knowing the location or number of recipient programs.
Oracle OTMQ application can selectively receive a broadcast message by first subscribing to a broadcast stream. To subscribe to a message stream, the receiving application first use
tpqsubscribe() to subscribe a message stream. Broadcast messages are then enabled for the application and flow into the receiver's queue for processing using the standard
For more information, see Publish/Subscribe in the.
Naming is a powerful capability that enables applications to refer to queues by alias instead of by their queue names. Naming separates applications from the details of the current environment configuration and enables system managers to make configuration changes without requiring developers to change their applications.
For more information, see Using Naming in the.
Oracle OTMQ uses message recovery journal queues to store messages that are designated as recoverable.
The message journal queue on the local queue space is called the store-and-forward (SAF). The message journal queue on the remote queue space is called the destination-queue-file (DQF). If a recoverable message cannot be delivered, it is stored in either the SAF or DQF, and automatically re-sent to the target.
Dead letter queue (DLQ) is a memory-based mechanism for storing undeliverable messages that cannot be stored for automatically recovery. Similar as DLQ, dead letter journal (DLJ) is a disk-based mechanism for storing undeliverable messages that cannot be stored for automatically recovery.
Another auxiliary journal queue is the post confirmation journal (PCJ). Recoverable messages that are successfully confirmed by the receiver can be written into the PCJ for audit.
Oracle OTMQ provides the
tpqreadjrn() function to dump messages from these journal queues.
For more information, see Using Recoverable Messaging in the.
In WS mode, OTMQ messages that are sent using a recoverable delivery mode are written to the local store-and-forward (SAF) journal file (tmqsaf.jrn), when the connection to the server system is not available.
|Note:||this WS SAF feature is available only when the WS client is in "Single-context" mode. For more information, see
For OTMQ, QSPACE can exceed 2G size limitation at 64bit unix platform for both persistent and non-persistent messages.
In tmqadmin, sub-command "
crdl" will create persistent device for qspace. The maximun value of this command is 2147483647, which is a system value, and the unit is system block size. So, the maximun size of persistent QSpace is 2147483647*block (bytes).
tmqadmin->qspacecreate command has a -n optional, which indicates the size of the area that reserved in shared memory for non-persistent messages for all queues in the queue space. The size may be specified in bytes (b) or blocks (B), where the block size is equivalent to the disk block size.For both "block(B)" and "byte(b)" argument of qspacecreate -n command, the max value is 2147483647. If using block(B) argument, the maximun size for non-persistent messages reserved is 2147483647*block.
|Notes:||For HPUX ia 64-bit platform, in |
|Note:||There is another environment variable
The Oracle Tuxedo API
tpinit() has two modes of operation: single-context mode and multicontext mode. For OTMQ, if an application calls
tpinit() explicitly, OTMQ does not go into multi-context mode automatically.
If application does no tcall
tpinit(), then following calling of
tpqattach() OTMQ goes into mulitcontext mode automatically. For WS client, the automation of multicontext mode association is not available.
Oracle OTMQ provides following system-level components for queuing services:
The Oracle OTMQ Message Forwarding Server. It is also known as the Oracle OTMQ Offline Trade Driver, which can forward messages from Journal to target queues automatically, when the original queuing operation was chosen to use recoverable delivery mode, or the operation was failed and the message was put into Journal for re-delivery.
To support the queuing service, Oracle OTMQ provides a new Transaction Management Server TMS_TMQM as the X/OPEN XA-compliant resource manager interface to manage the Oracle OTMQ queue space.
Besides the basic queuing services, Oracle OTMQ also provides supplemental features for customer. To support these features, Oracle OTMQ has following system level component:
TMQ_NA(), is the Oracle OTMQ Naming Server. It provides naming service which allows runtime queue alias binding and lookup.
TMQEVT(), is the Oracle OTMQ Event Broker, which is used to notify subscriber when topics are published using
tpqpublish(). The subscriber uses
tpqsubscribe(3c) to subscribe a topic.
TMQFORWARDPLUS(), is the message forwarding server. It forwards messages that have been stored using
tpenqueue(3c)/tpenqplus(3c)for later processing. The application administrator enables automated message processing for the application servers by specifying this server as an application server in the
Oracle OTMQ can also interoperate with another traditional message queue product: Oracle Message Queue (OMQ). To achieve the message level interoperability, the Oracle OTMQ provides following two system level components:
TuxMsgQLD(), is the Oracle OTMQ Link Driver Server. It is the bridge for Oracle OTMQ to interoperate with another messaging product, Oracle Message Queue (OMQ). For more information, see Interoperablity in the .
TuxCls(), is the Oracle OTMQ Client Library Server. It acts as a remote agent to perform queuing operations base on Oracle OTMQ queue space and queues on behalf of the existing Oracle Message Queue clients. For more information, see Interoperablity in the .