This section discusses some of the factors you need to take into account when designing new applications that will use shared queues, and when migrating existing applications to the shared-queue environment.
Certain types of applications might have to ensure that messages are retrieved from a queue in exactly the same order as they arrived on the queue. For example, if WebSphere MQ is being used to shadow database updates on to a remote system, a message describing the update to a record must be processed after a message describing the insert of that record. In a local queuing environment, this is often achieved by the application that is getting the messages opening the queue with the MQOO_INPUT_EXCLUSIVE option, thus preventing any other getting application from processing the queue at the same time.
WebSphere MQ allows applications to open shared queues exclusively in the same way. However, if the application is working from a partition of a queue (for example, all database updates are on the same queue, but those for table A have a correlation identifier of A, and those for table B a correlation identifier of B), and applications want to get messages for table A updates and table B updates concurrently, the simple mechanism of opening the queue exclusively is not possible.
If this type of application is to take advantage of the high availability of shared queues, you might decide that another instance of the application that accesses the same shared queues, running on a secondary queue manager, will take over if the primary getting application or queue manager fails.
If the primary queue manager fails, two things happen:
The secondary application might start before all the incomplete units of work have been dealt with, which could lead to the secondary application retrieving the messages out of sequence. To solve this type of problem, the application can choose to be a serialized application.
A serialized application uses the MQCONNX call to connect to the queue manager, specifying a connection tag when it connects that is unique to that application. Any units of work performed by the application are marked with the connection tag. WebSphere MQ ensures that units of work within the queue-sharing group with the same connection tag are serialized (according to the serialization options on the MQCONNX call).
This means that, if the primary application uses the MQCONNX call with a connection tag of Database shadow retriever, and the secondary takeover application attempts to use the MQCONNX call with an identical connection tag, the secondary application will not be able to connect to the second WebSphere MQ until any outstanding primary units of work have been completed, in this case by peer recovery.
You should consider using the serialized application technique for applications that depend on the exact sequence of messages on a queue. In particular:
In this case, the serialized application technique is only applicable if the application works in syncpoint.
In this case, the serialized application technique is only required if the application cannot open the queue for exclusive input.
Some features of WebSphere MQ are not supported when you are using shared queues, so applications that use these features are not suitable for the shared queue environment. You should consider the following points when designing your shared-queue applications:
There are queues other than application queues that you might want to consider sharing:
If you define a shared initiation queue, you do not need to have a trigger monitor running on every queue manager in the queue-sharing group, as long as there is at least one trigger monitor running. (You can also use a shared initiation queue even if there is a trigger monitor running on each queue manager in the queue-sharing group.)
If you have a shared application queue and use the trigger type of EVERY (or a trigger type of FIRST with a small trigger interval, which behaves like a trigger type of EVERY) your initiation queue should always be a shared queue. For more information about when to use a shared initiation queue, see Table 14.
You must define the SYSTEM.QSG.* queues used for shared channels and intra-group queuing as shared queues.
You can also change the definitions of the SYSTEM.DEFAULT.LOCAL.QUEUE to be shared, or define your own default shared queue definition. This is described in the section Defining system objects in the WebSphere MQ for z/OS Concepts and Planning Guide.
You cannot define any of the other SYSTEM.* queues as shared queues.
Migrating your existing queues to shared queues is described in the WebSphere MQ for z/OS System Administration Guide.
When you are migrating your existing applications, you should consider the following things, which might work in a slightly differently way in the shared queue environment.
If you use triggering to start applications, you might want to use a shared
initiation queue. Table 14 describes what you need to consider when deciding which type
of initiation queue to use.
Table 14. When to use a shared-initiation queue
|
| Non-shared application queue | Shared application queue |
|---|---|---|
| Non-shared initiation queue | As for previous releases. | If you are using trigger type of FIRST or DEPTH, you can use a non-shared
initiation queue with a shared application queue. There is the
possibility of extra trigger messages being generated, but this setup is good
for triggering long-running applications (like the CICS bridge) and provides
high availability.
For trigger type FIRST or DEPTH, a trigger message will trigger an instance of the application on every queue manager that is running a trigger monitor and that does not already have the application queue open for input. |
| Shared initiation queue | You should not use a shared initiation queue with a non-shared application queue. | If you have a shared application queue that has a trigger type of EVERY,
you should use a shared initiation queue or you will lose trigger
messages.
For trigger type FIRST or DEPTH, one trigger message will be generated by each queue manager that has the named initiation queue open for input. If the initiation queue is defined as a local queue, one trigger message is available to any trigger monitors running on that queue manager against the queue. |