| Author |
Message
|
| jeremydp |
 Posted: Tue May 05, 2009 5:17 pm Post subject: Re: 2PC? |
 |
|
Novice
Joined: 28 Apr 2009
Posts: 20
|
| bruce2359 wrote: |
| 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? |
My understanding is that the what I said to be true. But I am not confident of the logic. The syncpoints set at the message level then the commit processes all syncpoints?
If this is true, then if I have a get messasge and a put message each with a syncpoint and a put without a syncpoint do only the 2 with syncpoints occur with the commit while the one without the syncpoint occurs the moment the action occurs?
Thanks! |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue May 05, 2009 5:43 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Correct.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue May 05, 2009 6:30 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The MQBEGIN call is used to begin a UofW that spans this qmgr and another resource manager (like DB2).
_________________
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 |
|
|
| mqjeff |
| Posted: Wed May 06, 2009 4:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Just a note here. If you're only doing transactions with WMQ, you're not doing 2PC. You're doing single-phase commits to a single resource manager, no XA needed or involved.
And if you're only talking to MQ, then you don't need MQBEGIN and etc. You only need those when you *are* doing 2PC. |
|
| Back to top |
|
|
| jeremydp |
| Posted: Wed May 06, 2009 5:49 am Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009
Posts: 20
|
| mqjeff wrote: |
Just a note here. If you're only doing transactions with WMQ, you're not doing 2PC. You're doing single-phase commits to a single resource manager, no XA needed or involved.
And if you're only talking to MQ, then you don't need MQBEGIN and etc. You only need those when you *are* doing 2PC. |
I am only using MQ, no database work. We are getting from one queue, doing a conversion, then putting on another queue or queues.
With my needs, do I just use a COMMIT to destruct from the get queue and confirm my put on the put queue with out a BEGIN? Will a BACKOUT still work? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 06, 2009 5:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Again I'll ask: have you read the APR and APG on MQCMIT and MQBACK?
_________________
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: Wed May 06, 2009 6:18 am Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009
Posts: 20
|
| bruce2359 wrote: |
| Again I'll ask: have you read the APR and APG on MQCMIT and MQBACK? |
Yes, I have. But I do not completely understand it. I appreciate your patience with me.
Here is what it says:
The MQCMIT call indicates to the queue manager that the application has reached a syncpoint, and that all the message gets and puts that have occurred since the last syncpoint are to be made permanent. Messages put as part of a unit of work are made available to other applications; messages retrieved as part of a unit of work are deleted.
"since the last syncpoint" is of concern. In my situation I will have two syncpoints. Is it fair to assume that one or more syncpoints is implied here?
Also, the BEGIN starts a unit of work. Can you commit a unit of work without starting one?
MQGMO_SYNCPOINT
The request is to operate within the normal unit-of-work protocols.
It seems that this is all based on a unit of work. Can a unit of work exist without the BEGIN? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 06, 2009 6:36 am Post subject: Re: 2PC? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeremydp wrote: |
| In my situation I will have two syncpoints. |
Taking a step back, why do you want 2 syncpoints? It's an invitation to data loss.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 06, 2009 6:37 am Post subject: Re: 2PC? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jeremydp wrote: |
| Also, the BEGIN starts a unit of work. Can you commit a unit of work without starting one? |
The BEGIN signals the start of a GLOBAL unit of work, a 2PC unit of work.
MQGMO_SYNCPOINT/MQPMO_SYNCPOINT is all that is needed to start a LOCAL unit of work. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 06, 2009 6:37 am Post subject: Re: 2PC? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeremydp wrote: |
| Can a unit of work exist without the BEGIN? |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 06, 2009 6:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
MQBEGIN states the application intent to start a UofW that may span this qmgr and resources of another resource manager. If you are not doing SQL calls and MQ calls, MQBEGIN is not for you.
You can only have one UofW going at a time. A UofW begins when your app makes a change _IN_SYNCPOINT and ends when your app MQCMITs or MQBACKs the changes.
| Quote: |
| In my situation I will have two syncpoints. |
In your original post, you indicated that you wanted to make changes to queues in two different qmgrs, or did I misread? MQ doesn't support multi-qmgr UofW's. If you want to create a UofW that spans multiple qmgrs, you will need to create a UofW of your own, and manage it the best you can. This has been discussed here before.
You can have many syncpoints in a linear fashion: MQGET, MQPUT, MQCMIT, MQGET, MQPUT, MQCMIT... This is common when, for example, you are updating table rows, and each row represents a transaction - MQGET (the update information), SQL call, MQPUT, MQCMIT the MQGET, SQL call, and the MQPUT.
_________________
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: Wed May 06, 2009 6:57 am Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009
Posts: 20
|
| Vitor wrote: |
| jeremydp wrote: |
| In my situation I will have two syncpoints. |
Taking a step back, why do you want 2 syncpoints? It's an invitation to data loss. |
I thought I need a syncpoint for each action. Since I will be getting from one queue and setting a syncpoint, then doing business logic, then putting on one or more queues, I thought I needed a second syncpoint here. Then when I do a COMMIT both the get and put are finalized. Is this not the preferred way to do this?
Thank you! |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 06, 2009 7:01 am Post subject: Re: 2PC? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeremydp wrote: |
| Is this not the preferred way to do this? |
Yes, but you've got your terminology scrambled. What you're describing is two actions under syncpoint that are in a single unit of work, not 2 syncpoints (which end a unit of work).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed May 06, 2009 7:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A syncpoint is a place where, according to whatever business logic is appropriate, your app decides to comit/backout all changes since the last syncpoint. So, you get to decide which GETs and PUTs should be hardened. This is where MQCMIT/MQBACK are used - these harden the changes to queues.
What exactly is your business requirement? Are you trying to make changes to queues on two qmgrs inside a single UofW?
_________________
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: Wed May 06, 2009 8:17 am Post subject: Re: 2PC? |
|
|
Novice
Joined: 28 Apr 2009
Posts: 20
|
| bruce2359 wrote: |
| What exactly is your business requirement? Are you trying to make changes to queues on two qmgrs inside a single UofW? |
Business requirement is to Get a message from a QMgr, convert it, then Put it on another QMgr. Then issue a single commit to purge the message from the Get QMgr and finalize the Put on the Put QMgr. If there is a problem, the undo the Put and leave the Get alone. Does that make sense? And is this possible? What is it that I'm not getting? The documentation that I have been reading gives brief descriptions. So it leaves a lot to my imagination on how this actually operate.
There will be 2 different QMgrs. The Get will be from the local QMgr, the Put will be to a remote QMgr. My assumption is that because the Put QMgr is a remote definition under the Get QMgr that one COMMIT/BACKOUT would suffice. |
|
| Back to top |
|
|
|
|
