| Author |
Message
|
| nethaji |
 Posted: Thu May 30, 2002 6:59 am Post subject: Commit on Queue Remote |
 |
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
Hi,
We are planning to have a design as follows:
Transfer all the information in a single queue with priority 5 and then,
Trigger the receiving application by sending a 9 priority message in the same queue.
Commit the transcation.
My doubt here is,
Will the application gets triggered only after all the message reaches the receiving side?
How is the commit going to work on the remote queue? |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Thu May 30, 2002 7:12 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well all the messages will sit in the transmit queue uncommited until you
send the put the last message and commit, then the channel will send the
whole series of messages to the remote queue manager.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| nethaji |
| Posted: Thu May 30, 2002 7:21 am Post subject: |
|
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
Thanks.
I think I have to rephrase the question. The receiving application will try to fetch all the messages that are sent. Is there any chance for the receiving application to fail saying that there are no messages? In other way ,what if the receiving application works faster than the channel MCA programs,trying to fetch a message which is on the way to the receiving side. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu May 30, 2002 7:30 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Yes you could end up with only part of the complete message, example
network glitch, There are some MQSeries message segmentation options
that will allow you to issue the MQGET and check that all messages in the group are present, I am not sure if the priority of the last message can be change (doesnt mean it wont work) I just dont know.
Note: you have to use the MQPUT with segmentation also
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| nethaji |
| Posted: Thu May 30, 2002 8:08 am Post subject: |
|
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
Thanks jeff. Thanks for the clearing my doubt. Let me just repeat what I infer.
So even though we commit the remote queue after placing all the messages, The high priority trigger message will reach the other end first and there is the possibility that rest of the message won't be available for the triggered application to retrieve from the queue immdly. Correct me if I am wrong? |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu May 30, 2002 8:31 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
No the messages should arrive in order they are sent, however since TCP/IP doesnt guarntee it's packet order it is possible for the last message
to arrive ahead of the other messages(This is a rare happening for most everyone.)
So my suggestion is to use the message segmentation that IBM provides
and do your MQGET with the option that ALL the messages are there.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| nethaji |
| Posted: Thu May 30, 2002 9:02 am Post subject: |
|
|
Apprentice
Joined: 23 Jul 2001
Posts: 26
Location: Virginia
|
| The version of the MQ series we are using does not support MQ segmentation / grouping . We are using message ID for this reason to retreive message in order. We are just worried that when we specify this message id and issue a MQget api call, will it fail because the message have not be received yet? ( on its way to the destination or due to any channel problem it is held up in the sending side itself) |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu May 30, 2002 9:09 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well since you cant do MQ Segmentation, and you plan on using triggering based on priority and the last message is the trigger then the only thing
you need to worry about is the rare case where the are deleiverd out of order.
You can have application do a MQGET with wait for X amount of time and
also you can set the trigger interval to allow a second trigger message to be generated after y amount of time.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 30, 2002 10:52 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
You could also send the last priority 5 message with the COA report option set and then commit. When the COA comes back, you know the last Priority 5 message is on the queue, so then send your priority 9 message.
Of course, now you can worry that the second to last priority 5 message did not make it, while the last did....
Its better to put all the priority 5 messages in the same UOW, all non persistent or persistent, all to the same remote queue definition that only points to the same xmit queue which is being serviced by only 1 channel. If there are no intermediate queue managers in your message's travels (it's just the 2 QMS), then you can be pretty sure the message will arrive in order.
Add some info into the Priority 9 message like how many Priority 5 messages there should be and in what order. Have the triggered app do a get with wait juuuuuust in case something weird happens to screw up the order and you need to wait for the straggler to show up, although if you follow the above rules I don't see how it would happen.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
