| Author |
Message
|
| liquidchen |
 Posted: Tue Oct 17, 2006 12:20 am Post subject: do I need to use SYNCPOINT option with MQPUT and MQGET |
 |
|
Novice
Joined: 30 Mar 2006
Posts: 21
|
Hello, I am a little confuse that if my application behavior is every MQPUT with MQCMIT and MQGET with MQCMIT, do I need to
set SYNCPOINT and do MQCMIT?? Thanks... |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Oct 17, 2006 12:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You only need to use syncpoint if you want the get/put in a logical unit of work. If you're not using syncpoint commiting is redundant.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| liquidchen |
| Posted: Wed Oct 18, 2006 1:42 am Post subject: guarantee message delivery |
|
|
Novice
Joined: 30 Mar 2006
Posts: 21
|
| hi, thanks for your answer, because I had some information (maybe wrong information) that we have to turn on SYNCPOINT to make sure MQ guarantee message delivery, thanks again... |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 18, 2006 1:52 am Post subject: Re: guarantee message delivery |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| liquidchen wrote: |
| we have to turn on SYNCPOINT to make sure MQ guarantee message delivery |
That's certainly wrong information. To guarantee message delivery you should turn on persistence. Persistent messages will always be delivered, non-persistent messages may not be delivered if there's a serious software problem (queue manager failure serious!  )
You're quite welcome. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Oct 18, 2006 2:38 am Post subject: Re: guarantee message delivery |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Vitor wrote: |
| liquidchen wrote: |
| we have to turn on SYNCPOINT to make sure MQ guarantee message delivery |
That's certainly wrong information. To guarantee message delivery you should turn on persistence. Persistent messages will always be delivered, non-persistent messages may not be delivered if there's a serious software problem (queue manager failure serious! )
You're quite welcome. |
You don't need a "serious" problem to loose non-persistent messages, a simple stop/start of the queue manager will do. And, by default, if non-persistent messages can't be delivered across a channel, they are lost also.
_________________
-wayne |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 18, 2006 2:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Oops...... 
Can everyone tell I'll do anything to ensure a) queues hold messages for the bare minimum time possible & b) get fanactical about channel monitoring?
Apologies for spreading my views as fact! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tleichen |
| Posted: Wed Oct 18, 2006 9:14 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| Vitor wrote: |
| You only need to use syncpoint if you want the get/put in a logical unit of work. If you're not using syncpoint commiting is redundant. |
This is kind of true, but not absolute. Committing can be important because it controls when certain events occur, i.e., taking the message off the queue (in the case of an MQGET), even if you don’t have a TM in the mix. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 18, 2006 2:09 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| tleichen wrote: |
| Vitor wrote: |
| You only need to use syncpoint if you want the get/put in a logical unit of work. If you're not using syncpoint commiting is redundant. |
This is kind of true, but not absolute. Committing can be important because it controls when certain events occur, i.e., taking the message off the queue (in the case of an MQGET), even if you don’t have a TM in the mix. |
Don't see how this changes Vitor's point of view. I believe you just described a logical unit of work...(for which you need to use syncpoint of course) and by the way if you are using syncpoint the TM is the qmgr in the absence of an external TM...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| liquidchen |
| Posted: Thu Oct 19, 2006 2:43 am Post subject: |
|
|
Novice
Joined: 30 Mar 2006
Posts: 21
|
| Sorry to interrupt, Now I know that I do not need to do syncpoint for my app, but I want to know that if for some reason, we have to use this kind of behavior, will this cause some problem?? Performance or something ?? Because now we see lot of 2009 error after MQCMIT, and the IBM lab suggest us not use MQCMIT, so, I want to know that will MQCMIT cause this kind of problem (MQRC_CONNECTION_BROKEN), thanks a lot |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Oct 19, 2006 5:43 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
2009 simply means the MQ client connection has broken.
This return code will be reported on the next MQI call (of any kind) that is issued after the problem happens. Usually it happens on a MQGET with WAIT because that is the current call in progress.
If you delay issuing a CMIT then there is more chance that a 2009 condition could have happened. But CMIT won't cause it any more than any other MQI call.
Try specifying KEEPALIVE on your TCP sessions. |
|
| Back to top |
|
|
|
|
