| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| commit() not working correctly on MQ53 CSD5 |
« View previous topic :: View next topic » |
| Author |
Message
|
| mutley |
 Posted: Fri Jun 18, 2004 9:09 am Post subject: commit() not working correctly on MQ53 CSD5 |
 |
|
Novice
Joined: 12 Jun 2003
Posts: 13
|
We have an application that is getting a message under syncpoint. Once it has the message, it is committed. However, this is multi-threaded and is designed to run permenantly. So during testing we use ctrl-alt-del to end the app although there is a more realistic (but timeconsuming) method of stopping which invokes disconnect. Now, if we run this and a thread reads the message and passes it back to the calling app, it issues a qmgr.commit() call and moves on, no problem. However, if we subsequently terminate the program the message is rolled back to the Q? Why does it do this if we have already asked for the got messages to be committed? Is there a way to "force" the qmgr to immediately commit for example? Does the qmgr "cache" commit requests? I know that default behaviouor on crash is to rollback, whereas if you disconnect without issuing commit it automatically commits for you.
We are running MQ53, CSD5 on AIX.
Cheers
Neil |
|
| Back to top |
|
 |
| mutley |
| Posted: Fri Jun 18, 2004 10:29 am Post subject: |
|
|
Novice
Joined: 12 Jun 2003
Posts: 13
|
| sorry, thats ctrl-c not ctrl-alt-del |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Jun 18, 2004 10:51 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
I know that default behaviouor on crash is to rollback, whereas if you disconnect without issuing commit it automatically commits for you.
|
Where did you get this information from?? |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Jun 18, 2004 11:21 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Mutley,
There are many questions that are unanswered from your explanation and hence the question is not really clear.
"However, if we subsequently terminate the program the message is rolled back to the Q?"
---How do you know and confirm that it is the same message rolled back to the queue that was gotten by your threaded get app.
"Why does it do this if we have already asked for the got messages to be committed?"
---If a UOW is committed. It is committed. That's it. There is no way of rolling it back. So, i would go back and check the code to see if it was really committed. Meaning explicitly, rather than leaving the decision of committing a transaction onto the queue manager under "pull-the-plug" conditions and others.
"Is there a way to "force" the qmgr to immediately commit for example?"
---Commit is a commit. Once you issue it, the message is commited immediately.
"Does the qmgr "cache" commit requests?"
---I am not aware of any such feature.
Venny.
"Quote:
I know that default behaviouor on crash is to rollback, whereas if you disconnect without issuing commit it automatically commits for you.
Where did you get this information from??"
---This is documented in App prog ref manual.
If the application ends with uncommitted changes in a unit of work, the disposition of those changes depends on how the application ends:
If the application issues the MQDISC call before ending:
For a queue-manager-coordinated unit of work, the queue manager issues the MQCMIT call on behalf of the application. The unit of work is committed if possible, and backed out if not.
On z/OS, batch programs (including IMS batch DL/1 programs) are like this.
For an externally-coordinated unit of work, there is no change in the status of the unit of work; however, the queue manager will typically indicate that the unit of work should be committed, when asked by the unit-of-work coordinator.
On z/OS, CICS, IMS (other than batch DL/1 programs), and RRS applications are like this.
If the application ends normally but without issuing the MQDISC call, the action taken depends on the environment:
On z/OS, and on VSE/ESA for CICS applications, the actions described under (a) above occur.
In all other cases, the actions described under (c) below occur.
Because of the differences between environments, applications which are intended to be portable should ensure that the unit of work is committed or backed out before the application ends.
If the application ends abnormally without issuing the MQDISC call, the unit of work is backed out.
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 18, 2004 1:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
Is there a way to "force" the qmgr to immediately commit for example?
|
Yeah, don't use SYNCPOINT_YES on the MQGET.
| Quote: |
We have an application that is getting a message under syncpoint. Once it has the message, it is committed.
|
So you do nothing between the get of the message and the commit of the message? Then why are you bothering with syncpoint?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mutley |
| Posted: Fri Jun 18, 2004 3:29 pm Post subject: |
|
|
Novice
Joined: 12 Jun 2003
Posts: 13
|
[quote="mqonnet"]Mutley,
There are many questions that are unanswered from your explanation and hence the question is not really clear.
"However, if we subsequently terminate the program the message is rolled back to the Q?"
---How do you know and confirm that it is the same message rolled back to the queue that was gotten by your threaded get app.
I know it is this message because it is the only message on this particular Q in this scenario. Correlid/ Message ID and a unique App data random identifier match.
"Why does it do this if we have already asked for the got messages to be committed?"
---If a UOW is committed. It is committed. That's it. There is no way of rolling it back. So, i would go back and check the code to see if it was really committed. Meaning explicitly, rather than leaving the decision of committing a transaction onto the queue manager under "pull-the-plug" conditions and others.
Code has testing println's around the qmgr.commit(); and they are both executed and printed to the console. So the method is, or should be invoked against my qmgr object. I am of course catching MQExceptions, but none are thown.
"Is there a way to "force" the qmgr to immediately commit for example?"
---Commit is a commit. Once you issue it, the message is commited immediately.
See above.
"Does the qmgr "cache" commit requests?"
---I am not aware of any such feature.
Neither am I.
Cheers
Muts |
|
| 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
|
|
|
|
