| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Question on MQAX Default Behavior |
« View previous topic :: View next topic » |
| Author |
Message
|
| wellsfargo |
 Posted: Wed Jan 19, 2005 9:36 am Post subject: Question on MQAX Default Behavior |
 |
|
Newbie
Joined: 19 Jan 2005
Posts: 4
|
I am loading messages from a Win32 client (PowerBuilder) to a MVS based MQ queue using the MQAX interface. I am currently writing X number of messages to a queue and committing as a unit of work. This works fine. (no one can see these messages until the commit) But if my client crashes in process w/o an explicit commit the default behavior of the connection appears to be an implicit commit instead of a rollback.
How do I configure a connection so that if the connection is broken any uncommitted work will be rolled back.
TIA |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Wed Jan 19, 2005 10:24 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| You don't have control over this behavior. If you'll check out the App Prog Reference, there is a discussion in the MQCMIT section about the behavior of the unit of work if your program ends without issuing the MQCMIT. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 19, 2005 11:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Code: |
If the application ends with uncommitted changes in a unit of work, the
disposition of those changes depends on how the application ends:
a. If the application issues the MQDISC call before ending:
v 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.
v 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.
b. If the application ends normally but without issuing the MQDISC call, the
action taken depends on the environment:
v On z/OS, and on VSE/ESA for CICS applications, the actions described
under (a) above occur.
v 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.
c. If the application ends abnormally without issuing the MQDISC call, the unit
of work is backed out.
|
Looks to me like an MQClient conected to a QM on z/OS falls under:
| Quote: |
a. If the application issues the MQDISC call before ending:
v 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.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wellsfargo |
| Posted: Fri Jan 21, 2005 7:31 am Post subject: |
|
|
Newbie
Joined: 19 Jan 2005
Posts: 4
|
Thanks for the replies. On further research this is what I have found:
1) If a transaction is in process and the application is closed in a "friendly" manner such as a user closing the application, this allows for objects to be destroy properly including the MQAX object. The MQAX object appears to issue an explicit disconnect causing the QM to commit the partial transaction.
2) If a transaction is in process and the application is killed by the OS due to a SEGV, etc., nothing is issued and the QM rolls the partial transaction back. |
|
| 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
|
|
|
|
