Author |
Message
|
jeremydp |
Posted: Tue Apr 28, 2009 2:15 pm Post subject: 2PC? |
|
|
Novice
Joined: 28 Apr 2009 Posts: 20
|
Newbie here, I have spent most of the afternoon reading posts and there are some posts that are similar to my situation, but not exact.
Application to call 2 different remote QMgrs (Get and Put).
1. Connect to QMgr_Get
2. Get Msg
3. Convert Msg
4. Connect to QMgr_Put
5. Put Msg
6. Delete Msg from QMgr_Get
7. Disconnect from QMgr_Get
8. Disconnect from QMgr_Put
If there are any problems before 5, log the error and close/disconnect where applicable. If there are any errors with 5, do not do 6. If there are any errors with 6, delete Msg from QMgr_Put. Then log error and close/disconnect.
Also we do not have ETC. Is this required or is there another option?
Is this possible? If so, do I need anything besides WMQ v6 and VB.Net? I am so lost with Transaction Mgrs, Resource Mgrs, MQ Clusters, and XA. Are any of these needed? And is there some software that does this already out of the box?
TIA! |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Apr 28, 2009 4:51 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
1. MQCONN to QMgr_A
2. MQOPEN Get Queue
3. MQOPEN Remote Q definition on QMgr_A that points at destination Q on QMgr_B
Do Until 2033
4. MQGET Msg with convert option and specify syncpoint=yes.
5.Make sure MQMD_Backout Count < the # of times you would want to retry any 1 message. If Backout Count greater than your threshhold, move message to Backout Queue and get next message.
6. Do business logic here
7. MQPUT Msg to a remote queue on QMgr_A that points to the destination queue on QMgr_B. Use syncpoint option.
8.All good? MQCMIT both messages. Otherwise MQBACK both messages and log error.
End Do
9. MQCLOSE both queues
10. MQDISC from QMgr_A.
You don't need clustering, ETC, XA, Resource Managers etc...based on the details you have provided so far. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jeremydp |
Posted: Tue Apr 28, 2009 6:37 pm Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009 Posts: 20
|
Thanks Peter! Now I am looking forward to work tomorrow. Too bad I have meetings all morning.
2033 is file not found, right? |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Apr 28, 2009 7:43 pm Post subject: Re: 2PC? |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
jeremydp wrote: |
Thanks Peter! Now I am looking forward to work tomorrow. Too bad I have meetings all morning.
2033 is file not found, right? |
No 2033 is no message with matching criteria available.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
gbaddeley |
Posted: Wed Apr 29, 2009 5:18 pm Post subject: Re: 2PC? |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
jeremydp wrote: |
2033 is file not found, right? |
Jeremy, you have a lot to learn about MQ. Don't guess at what things mean, you will embarrass yourself on this forum. Do some reading, such as the WMQ v7 Application Programming Guide. Go on a training course! _________________ Glenn |
|
Back to top |
|
 |
jeremydp |
Posted: Thu Apr 30, 2009 7:27 am Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009 Posts: 20
|
Yes, I do have a lot to learn. I was at home when I posted my last message and took a guess. To your point, perhaps I should not have guessed. Instead waited until I got to work to look it up in my file.
Anyway, this all works as long as everything is using the same host and port, right? Or can I have multiple hosts and/or ports and still use the syncpoint and commits/backouts? |
|
Back to top |
|
 |
Vitor |
Posted: Thu Apr 30, 2009 7:34 am Post subject: Re: 2PC? |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
jeremydp wrote: |
can I have multiple hosts and/or ports and still use the syncpoint and commits/backouts? |
How do you mean "multiple hosts"? If you've more than 1 queue manager it's still doing gets and puts. The software can't tell if 2 queue managers are on the same or different hosts.
If what you mean is:
Get on QMA -> Business Logic -> Put to QMB -> Get on QMB -> Business Logic -> Backout -> Message rolls back to QMA
then this is not an architecture you should be using with WMQ. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Apr 30, 2009 7:52 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Jeremey, the MQCMIT or MQBACK will be done on the Queue Manager object, so whether they are on the same server or not doesn't matter. You will have to make a MQBACK or MQCMIT call for each QM object to commit or backout all the calls in that QM's unit of work. This is why your original design of connecting to the other QM to put the 2nd message was not the best if you wanted to commit and rollback the get and put together. Its not a good idea for other reasons as well. MQClients typically connect to the QM they need to get messages from, and then rely on the QM to QM channels the MQ Admin built to have messages go to any other QM via the connected to QM. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jeremydp |
Posted: Thu Apr 30, 2009 8:01 am Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009 Posts: 20
|
PeterPotkay wrote: |
Jeremey, the MQCMIT or MQBACK will be done on the Queue Manager object, so whether they are on the same server or not doesn't matter. You will have to make a MQBACK or MQCMIT call for each QM object to commit or backout all the calls in that QM's unit of work. This is why your original design of connecting to the other QM to put the 2nd message was not the best if you wanted to commit and rollback the get and put together. Its not a good idea for other reasons as well. MQClients typically connect to the QM they need to get messages from, and then rely on the QM to QM channels the MQ Admin built to have messages go to any other QM via the connected to QM. |
Thank you Peter! So if during the commit phase, if the commit phase fails on one QM, the other QM doesn't know about it? So this would not be a true 2pc, right?
What other options should I be looking into? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Apr 30, 2009 8:46 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If you are connected to QMA and put a message under syncpoint to a remote queue on QMA that points to QMB, the messages never leaves QMA until you commit it. So QMB is never involved until you commit on QMA.
If you connect to QMA to get a message under syncpoint, then connect to QMB to put a message under syncpoit you will have to issue a MQCMIT or MQBACK to QMA and then to QMB, with an obvious oppourtunity for one to work and the other to fail. This is why I keep saying don't connect to another QM to do the put - use Remote Queue Definitions on QMA to get messages to QMB, QMC....QMZ. And then you can commit or rollback both calls.
Read this. Its big, but will save you more time in the end than if you don't read it:
http://www.redbooks.ibm.com/abstracts/sg247128.html
WebSphere MQ V6 Fundamentals
This IBM Redbook describes the fundamental concepts and benefits of message queuing technology. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jeremydp |
Posted: Thu Apr 30, 2009 10:11 am Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009 Posts: 20
|
Thank you again Peter. I'm off to get some caffine so I can read the material in the link.
I'm sure I'll have more questions later.
Jeremy |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Apr 30, 2009 10:21 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Jeremy, if you're looking for some 2 phase commit in a bridge or such you cannot have the qmgr be the transaction coordinator.
Supported transaction coordinators are CICS TM, WebSphere Application Server and WebLogic. If you use the jca pack any supported J2EE TM.
The connection to MQ needs to be a "client" connection and you need the etc (External Transactional Client) installed and active.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Apr 30, 2009 12:06 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Generally, an application only MQCONNects to one qmgr at a time; a unit of work can only include the resources of one qmgr.
At MQCONNect, the qmgr gives the application a connection handle that is used for all subsequent MQI calls to this qmgr. For MQI calls in _SYNCPOINT, the application will specify MQCMIT or MQBACK, passing the connection handle from the MQCONNECT.
Your application design has you MQCONNect to two qmgrs concurrently. Although this is possible, your app will need to manage the two connection handles, and decide which and when to comit/backout. _________________ 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 |
|
 |
jeremydp |
Posted: Tue May 05, 2009 4:26 pm Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009 Posts: 20
|
OK, after some reading I have more questions...
Not sure if I mentioned this, but I am coding in .Net.
Please tell me if I have these right:
The Begin, Commit, and Back are at the queue manager level and the Sync is at the message option level? Also the queue itself does not have options, it's the queues actions that have options (Get, Put, etc)?
So basically:
Connect/open to QMgr
create/open Q_Get
create/open Q_Put
Begin at QMgr
Get message with Syncpoint option
Business logic
Put message with Syncpoint option
Commit/Backout at QMgr
Clean up (closes and disconnect) |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue May 05, 2009 5:04 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
OK, after some reading I have more questions... |
Did you read the WMQ Application Programming Reference and the WMQ Application Programming Guide for the MQBEGIN, MQCMIT and MQBACK calls? _________________ 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 |
|
 |
|