Dynamic queues
When an application program issues an MQOPEN call to open a model queue,
the queue manager dynamically creates an instance of a local queue with the
same attributes as the model queue. Depending on the value of the DefinitionType field of the model queue, the queue manager creates
either a temporary or permanent dynamic queue (See Creating dynamic queues).
Properties of temporary dynamic queues
Temporary dynamic queues have the following properties:
- They cannot be shared queues, accessible from queue managers in a queue-sharing
group (only available on WebSphere MQ for z/OS).
- They hold nonpersistent messages only.
- They are non-recoverable.
- They are deleted when the queue manager is started.
- They are deleted when the application that issued the MQOPEN call that
created the queue closes the queue or terminates.
- If there are any committed messages on the queue, they are deleted.
- If there are any uncommitted MQGET, MQPUT, or MQPUT1 calls outstanding
against the queue at this time, the queue is marked as being logically deleted,
and is only physically deleted (after these calls have been committed) as
part of close processing, or when the application terminates.
- If the queue is in use at this time (by the creating, or another application),
the queue is marked as being logically deleted, and is only physically deleted
when closed by the last application using the queue.
- Attempts to access a logically deleted queue (other than to close it)
fail with reason code MQRC_Q_DELETED.
- MQCO_NONE, MQCO_DELETE and MQCO_DELETE_PURGE are all treated as MQCO_NONE
when specified on an MQCLOSE call for the corresponding MQOPEN call that created
the queue.
Properties of permanent dynamic queues
Permanent dynamic queues have the following properties:
- They hold persistent or nonpersistent messages.
- They are recoverable in the event of system failures.
- They are deleted when an application (not necessarily the one that issued
the MQOPEN call that created the queue) successfully closes the queue using
the MQCO_DELETE or MQCO_DELETE_PURGE option.
- A close request with the MQCO_DELETE option fails if there are any messages
(committed or uncommitted) still on the queue. A close request with the MQCO_DELETE_PURGE
option succeeds even if there are committed messages on the queue (the messages
being deleted as part of the close), but fails if there are any uncommitted
MQGET, MQPUT, or MQPUT1 calls outstanding against the queue.
- If the delete request is successful, but the queue happens to be in use
(by the creating, or another application), the queue is marked as being logically
deleted and is only physically deleted when closed by the last application
using the queue.
- They are not deleted if closed by an application that is not authorized
to delete the queue, unless the closing application issued the MQOPEN call
that created the queue. Authorization checks are performed against the user
identifier (or alternate user identifier if MQOO_ALTERNATE_USER_AUTHORITY
was specified) that was used to validate the corresponding MQOPEN call.
- They can be deleted in the same way as a normal queue.
Uses of dynamic queues
You can use dynamic queues for:
- Applications that do not require queues to be retained after the application
has terminated.
- Applications that require replies to messages to be processed by another
application. Such applications can dynamically create a reply-to queue by
opening a model queue. For example, a client application can:
- Create a dynamic queue.
- Supply its name in the ReplyToQ field of the message
descriptor structure of the request message.
- Place the request on a queue being processed by a server.
The server can then place the reply message on the reply-to queue. Finally,
the client could process the reply, and close the reply-to queue with the
delete option.
Recommendations for uses of dynamic queues
Consider the following points when using dynamic queues:
- In a client-server model, each client must create and use its own dynamic
reply-to queue. If a dynamic reply-to queue is shared between more than one
client, deleting the reply-to queue might be delayed because there is uncommitted
activity outstanding against the queue, or because the queue is in use by
another client. Additionally, the queue might be marked as being logically
deleted, and inaccessible for subsequent API requests (other than MQCLOSE).
- If your application environment requires that dynamic queues must be shared
between applications, ensure that the queue is only closed (with the delete
option) when all activity against the queue has been committed. This should
be by the last user. This ensures that deletion of the queue is not delayed,
and minimizes the period that the queue is inaccessible because it has been
marked as being logically deleted.