| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Assured Delivery With Websphere MQ Clients |
« View previous topic :: View next topic » |
| Author |
Message
|
| AlphaOmega |
 Posted: Fri May 05, 2006 11:49 am Post subject: Assured Delivery With Websphere MQ Clients |
 |
|
Newbie
Joined: 05 May 2006
Posts: 9
|
Hello:
Can assured delivery be accomplished with Websphere MQ clients? Rather, would an MQ server wait for the acknowledgement of delivery from the MQ client before committing the message, and back out the message if no acknowledgement is received? Thank you. |
|
| Back to top |
|
 |
| mvic |
| Posted: Fri May 05, 2006 12:02 pm Post subject: Re: Assured Delivery With Websphere MQ Clients |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
When under syncpoint, you would say
MQPUT
MQCMIT
... and if you get a good completion code/reason code from the MQCMIT, this is evidence that the message was successfully placed on the queue.
When not under syncpoint, you would say only
MQPUT
... and if you get a good completion code/reason code from the MQPUT, this is evidence that the message was successfully placed on the queue.
Does this answer the question? |
|
| Back to top |
|
|
| AlphaOmega |
| Posted: Fri May 05, 2006 12:12 pm Post subject: From The Client Side |
|
|
Newbie
Joined: 05 May 2006
Posts: 9
|
| What about from the queue manager (server) perspective? If a client does an MQGET, how would the MQ server know that the client actually received the message (or that the receiving application received the message) so that it can commit the transaction and remove the message from the queue, and conversely to backout the transaction and leave the message on the queue if it receives no acknowledgement from the MQ client (or the MQ client's application) that the message was received over the network after the MQGET was done? |
|
| Back to top |
|
|
| mvic |
| Posted: Fri May 05, 2006 12:28 pm Post subject: Re: From The Client Side |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| AlphaOmega wrote: |
| What about from the queue manager (server) perspective? If a client does an MQGET, how would the MQ server know that the client actually received the message |
You could use syncpoint:
MQGET(specify MQGMO_SYNCPOINT)
MQCMIT
The app issues MQCMIT to indicate it has successfully processed the message. When the server receives the MQCMIT, it then proceeds to remove the message permanently from the queue.
| Quote: |
| and conversely to backout the transaction and leave the message on the queue if it receives no acknowledgement from the MQ client (or the MQ client's application) that the message was received over the network after the MQGET was done? |
If the app ends without disconnecting cleanly, this will be interpreted by the server as a failure, and the MQGET will be rolled back.
Full rules are in this section of the manuals: http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/usesync.htm |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 05, 2006 2:55 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
and think about what happens if the MQCMIT returns a 2009. 
Did it work, (the MQCMIT called completed, but the connection dropped before the QM was able to send back the good return code? Or did it not work because the connection dropped before the MQCMIT made it to the QM? Notice you have the exact same dilima on apps running in bindings mode, but of course the window of oppourtunity is much smaller for a lost connection to the QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
