| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Using MQ as transaction coordinator for MQ/DB2 (z/OS) |
« View previous topic :: View next topic » |
| Author |
Message
|
| Vitor |
 Posted: Wed Dec 07, 2011 12:53 pm Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Thanks for the update. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| Sandman |
| Posted: Mon Feb 13, 2012 8:19 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
We've gotten much farther with this, thanks to DB2 Support help. There was a bug in the version of the JDBC driver we were using. We were asked to update driver and now we have two-phased commit working to DB2 on z/OS, and backout is also working but with an exception (XA_RBROLLBACK) showing in log; but we've been instructed to ignore seeing it doesn't get rethrown to our test app.
However, after we verified application-driven backout, we wanted to next test failing components besides our app (i.e. MQ dies, DB2 dies). So app does MQPUT and DB2 insert, then breakpoint at MQCMIT. While at breakpoint, I taskkill all MQ processes (to simulate queue manager dying). Then I step over MQCMIT. As expected, app catches exception and logs, but doesn't attempt backout (seeing it knows qmgr is gone).
When I brought the qmgr back up, it had backed out the MQPUT that our app did. But how and when (if ever) does DB2 realize that it can cleanup the uncommitted thread? We're seeing that it just hangs onto it and we have to kill it.
Am I missing something? Thank you.
Last edited by Sandman on Mon Feb 13, 2012 10:21 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 13, 2012 9:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
When the qmgr restarts, it looks to see if any transactions did not complete.
It will go through a redo/undo process (described in the system admin documentation) to commit transactions that were successful, AND backout transactions that were unsuccessful.
If the transaction included other resource managers (DB2, for example), the restart process will automatically contact DB2 to coordinate the backout/commit process. This usually works perfectly; and both qmgr and resource manager(s) are happy.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Feb 13, 2012 9:30 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
| Any idea how long MQ might take to do this? I've tested this with DB2 on both Windows and z/OS and MQ doesn't cleanup the DB2 threads on either. Do we have to configure something else on MQ or DB2? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 13, 2012 10:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Sandman wrote: |
| Any idea how long MQ might take to do this? I've tested this with DB2 on both Windows and z/OS and MQ doesn't cleanup the DB2 threads on either. Do we have to configure something else on MQ or DB2? |
Do what?
The admin work to set this up? On z/OS, you need to do some stuff with RRS. On Win/UNIX you will need to enable XA stuff.
Or to do a restart? Restart will take as long as necessary to mount the logs required to undo whatever needs to be undone.
In any case, how to set up XA-compliance is well-documented in the InfoCenter and relevant manuals.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Feb 13, 2012 10:28 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Neither. We already understand the admin work to setup XA, as we have it working, after working with IBM MQ and DB2 Support, eventually leading us to a buggy JDBC driver and some other method calls.
What I'm asking now is:
Given an already-XA-functioning configuration of MQ and DB2 (z/OS or Windows), if the queue manager dies before the app asks it to 2PC, when the qmgr restarts, is there a delay in it communicating to DB2 to rollback uncommitted transactions? I ask this because after we restart the qmgr, the DB2 threads on z/OS continue to hang. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 13, 2012 11:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Sandman wrote: |
What I'm asking now is: ...
if the queue manager dies before the app asks it to 2PC, when the qmgr restarts, is there a delay in it communicating to DB2 to rollback uncommitted transactions? I ask this because after we restart the qmgr, the DB2 threads on z/OS continue to hang. |
Yes, there will be a delay.
The qmgr will determine that it did not end gracefully (no closing checkpoint). It will replay the logs (from the last good checkpoint) to complete any successful transactions.
It will then attempt to backout transactions that did not successfully complete. If any of these include other resource managers, the qmgr will negotiate with that resource manager as how to complete (commit or backout) the in-doubt transaction.
Most often, the negotiation process is successful. If it is not, then there are MQSC commands (and equivalent ISPF panels) to direct the qmgr and resource manager(s) what to do. Until then, both the qmgr and the resource manager(s) will still be in-doubt.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Feb 13, 2012 11:47 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
| Thank you for the explanation. I will investigate further. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
