| Author |
Message
|
| asincero |
 Posted: Fri Oct 14, 2005 10:25 am Post subject: How to stop MQ from auto-commiting? |
 |
|
Novice
Joined: 13 Mar 2003
Posts: 18
|
I'm doing an MQGET() with the MQGMO_SYNCPOINT option specified. If I do this MQGET(), and then shut down the queue manager via 'endmqm' before doing an MQCMIT(), I noticed that MQ effectively does an "auto-commit" (i.e. the message I just MQGET()'d is dequeued from the queue). I really need to have my application only dequeue a message from the queue when it does an explicit MQCMIT(). Is there an option I can specify to not auto-commit, or do I have to live with this? Or maybe have it do an auto-rollback instead of an auto-commit?
Thanks. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Oct 14, 2005 10:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| asincero |
| Posted: Fri Oct 14, 2005 10:44 am Post subject: |
|
|
Novice
Joined: 13 Mar 2003
Posts: 18
|
| jefflowrey wrote: |
| http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzal.doc/usesync.htm |
So I guess the answer to my question is "no, there's no way to have it not auto-commit (or "implicit syncpoint" as the docs call it) if the queue manager is explicitly shutdown via 'endmqm'". |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 14, 2005 10:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess the answer to your question is, read the documentation to learn the explicit and implicit behavior of syncpoints for your particular platform and environment.
Which, since you didn't say, I can't help you with.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| asincero |
| Posted: Fri Oct 14, 2005 10:53 am Post subject: |
|
|
Novice
Joined: 13 Mar 2003
Posts: 18
|
| jefflowrey wrote: |
I guess the answer to your question is, read the documentation to learn the explicit and implicit behavior of syncpoints for your particular platform and environment.
Which, since you didn't say, I can't help you with. |
Yes, I figured I should've mentioned the platform I was on which is why I made sure to mention that in the other thread I just made regarding MQPUT()'s.
The platform I'm on is Linux. Specifcally, Mandrake Linux 9.0. The platform the application will ultimately run on is AIX 5.3. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 14, 2005 10:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| asincero wrote: |
Yes, I figured I should've mentioned the platform I was on which is why I made sure to mention that in the other thread I just made regarding MQPUT()'s.
The platform I'm on is Linux. Specifcally, Mandrake Linux 9.0. The platform the application will ultimately run on is AIX 5.3. |
I'm, in particular, not likely to keep track of information about people's systems between different threads... so posting it here would have been much better.
The answer in your case, then, is http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/csqzal1079.htm
I'm assuming it has a typo, where it says "a global unit of work". What this page basically says is, unless you are using XA/2pcommit, then you can control the choice to auto-commit or auto-rollback at failure by either calling or not calling MQDISC.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Oct 14, 2005 11:09 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Or, alternately, you can explicitly call MQBACK and then MQDISC if you get a 2161/2 (which I assume you are getting from your MQGET with wait) 
_________________
-wayne |
|
| Back to top |
|
|
| asincero |
| Posted: Fri Oct 14, 2005 11:12 am Post subject: |
|
|
Novice
Joined: 13 Mar 2003
Posts: 18
|
| jefflowrey wrote: |
I'm assuming it has a typo, where it says "a global unit of work". What this page basically says is, unless you are using XA/2pcommit, then you can control the choice to auto-commit or auto-rollback at failure by either calling or not calling MQDISC. |
Unfortunately, I think I'm still screwed here because that seems to assume that the queue manager is still up and running. If I shut down the queue manager while the app is still connected, the app will never get a chance to do an MQDISC(). |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Oct 14, 2005 11:15 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
MQ will not autocommit a message if its in a unit-of-work unless you explicity MQCMIT or MQDISC before the qmgr shuts down. If the qmgr goes away before you get to do the MQDISC, the unit-of-work is rolled-back.
btw..are you SURE that you're not failing on the MQGET and still doing a successful MQCMIT or MQDISC? They will work for a short time after the MQGET gets a 2161/2.
_________________
-wayne |
|
| Back to top |
|
|
| asincero |
| Posted: Fri Oct 14, 2005 11:27 am Post subject: |
|
|
Novice
Joined: 13 Mar 2003
Posts: 18
|
| wschutz wrote: |
| Or, alternately, you can explicitly call MQBACK and then MQDISC if you get a 2161/2 (which I assume you are getting from your MQGET with wait) |
No, because what happens is this:
1. Process A successfully MQGET()s a message from MQ queue. The MQGMO_SYNCPOINT option is specified.
2. Process A sends message to Process B via UNIX pipes and waits for acknowledgement that it has successfully received and digested the message. I didn't feel this detail was worth mentioning earlier, but I'll include it here for completeness.
3. If Process B is successful in processing the message it tells Process A to do an MQCMIT(). Otherwise it tells Process A to do an MQBACK().
At step 2, I shut down the queue manager with 'endmqm'. So doing either an MQCMIT(), MQBACK(), or even an MQDISC() will return an error when I get to step 3. |
|
| Back to top |
|
|
| asincero |
| Posted: Fri Oct 14, 2005 11:36 am Post subject: |
|
|
Novice
Joined: 13 Mar 2003
Posts: 18
|
| wschutz wrote: |
MQ will not autocommit a message if its in a unit-of-work unless you explicity MQCMIT or MQDISC before the qmgr shuts down. If the qmgr goes away before you get to do the MQDISC, the unit-of-work is rolled-back.
btw..are you SURE that you're not failing on the MQGET and still doing a successful MQCMIT or MQDISC? They will work for a short time after the MQGET gets a 2161/2. |
That's interesting because that doesn't seem to be what is happening in my development environment. Stuff is getting auto-committed when I shut the queue manager down. Is there some option I can set on the queues when I create them or something? I'll check the administrator's manual. I just used the Quick Beginnings document for Linux to get an MQ server up and running so I could work on the app.
Check out my reply to your first post for more details on what I am doing. In short, I'm sure that MQGET() is not failing however by the time I get to the MQCMIT() the queue manager has already gone away and thus that call would fail. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Oct 14, 2005 1:55 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| I'm sure that MQGET() is not failing however by the time I get to the MQCMIT() the queue manager has already gone away and thus that call would fail. |
So you see a non-zero return code from the MQCMIT? What value is it?
_________________
-wayne |
|
| Back to top |
|
|
| asincero |
| Posted: Fri Oct 14, 2005 5:38 pm Post subject: |
|
|
Novice
Joined: 13 Mar 2003
Posts: 18
|
| wschutz wrote: |
| Quote: |
| I'm sure that MQGET() is not failing however by the time I get to the MQCMIT() the queue manager has already gone away and thus that call would fail. |
So you see a non-zero return code from the MQCMIT? What value is it? |
Yes, I get reason code 2009 (MQRC_CONNECTION_BROKEN).
FWIW, I am using version 5.2 of the MQ SDK and client libraries and version 5.3 of MQ Server. Also, this is all on Linux. |
|
| Back to top |
|
|
| wschutz |
| Posted: Sat Oct 15, 2005 2:50 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| FWIW, I am using version 5.2 of the MQ SDK and client libraries and version 5.3 of MQ Server. Also, this is all on Linux. |
The behaviour your are seeing is not what should be happening. Uncommitted work should not be auto-committed (and no, there is no setting on the qmgr or queue to change that). Can you upgrade you client and server to 5.3 CSD11 or V6?
Also, is the client linux as well? What language are you writing in?
_________________
-wayne |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 15, 2005 3:10 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| wschutz wrote: |
| Can you upgrade you client and server to 5.3 CSD11 or V6? |
I don't think that's it - MQ in every version I ever knew (from v2 to v6) has always rolled-back uncommited units of work, it doesn't make any sense to do otherwise. Asincero - to be clear - this is how transactional mechanisms work by design, no matter if it's MQ or some db, so the behavior your describing is strange indeed.
I think we are facing a simpler problem here -probably a bug in his code, or the MQGMO_SYNCPOINT not properly set up; Could you post your code here so we can take a look?
I would also suggest you write a very simple code that just MQGETs from queue without commiting, and experiment with it - take some elements of complexity out of the equation; you should write it anew, not use the code snippet from your original prog, or you'll end up having the same prob.
Btw, when you said "endmqm" did you mean "endmqm -i"? And do you have QMGR_QUIESING specified? |
|
| Back to top |
|
|
|
|
