You
could MQOPEN Q1, put message1 with a COA, read the COA to see what QM
got Message1, and then MQOPEN Q2 specifying the QM where the COA came from,
put message2 then commit both and close both queues.
Now
both messages will always be on Q1 / Q2 on the same QM. But you will get a
random QM each time.
-----Original Message-----
From: Jim Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, October 04, 2004 4:55 PM
To: [EMAIL PROTECTED]
Subject: Clustering w/ Message Affinity
We don't use clustering at our site, but are considering it for a couple of high volume applications. Some of these applications, though, use correlation ID to match messages on two different queues.
To be more specific, a binary message is put to Q1 under syncpoint. A second message is put to Q2. The second message's correlation ID is set to the first message's message ID. Then a commit is done. The getting app gets the message from Q1, and gets the correlated message from Q2 and processes them. This works fine.
But this design requires that both messages have to be delivered to the same target queue manager. How can we guarantee that if we use clustering? Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy all copies.
