| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| XA coordination question |
« View previous topic :: View next topic » |
| Author |
Message
|
| sunny_30 |
 Posted: Wed May 15, 2013 5:01 pm Post subject: XA coordination question |
 |
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Take a very simple Message-flow that is configured to use only 1 DSN, using only 1 compute node, talking to only 1 type of database & does only 1 DB Insert operation.
In such a scenario, is there any value (or) a use case that requires to setup Global XA (2PC) coordination in the message-flow ?
If yes- please explain an example situation where that would be necessary..
As I understand, if the flow's compute node is set to Automatic transaction, & the flow processing is successful, the Insert would be commited to the database. If the "insert-commit-request"'s response from database is a failure, the flow backs out automatically- Am I correct ?
Also, AFAIK, 2PC (XA) is only relevant in a scenario where eg: multiple databases are invoked from the flow and a particular commit to database1 cannot rollback another commit from the same flow to the database2. In this situation an external TM might be necessary to rollback database2's commit when the database1's commit aborts - Is my understanding correct ? Please clear up. Thanks in advance. |
|
| Back to top |
|
 |
| marko.pitkanen |
| Posted: Wed May 15, 2013 9:03 pm Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
I might be wrong, but how about situation if this simple flow is part of distributed transaction where other resources are updated by other network hosts and all systems must have consistent state, whether the transaction success or fails as a whole?
--
Marko |
|
| Back to top |
|
|
| Esa |
| Posted: Wed May 15, 2013 11:48 pm Post subject: Re: XA coordination question |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| sunny_30 wrote: |
As I understand, if the flow's compute node is set to Automatic transaction, & the flow processing is successful, the Insert would be commited to the database. If the "insert-commit-request"'s response from database is a failure, the flow backs out automatically- Am I correct ?
Also, AFAIK, 2PC (XA) is only relevant in a scenario where eg: multiple databases are invoked from the flow and a particular commit to database1 cannot rollback another commit from the same flow to the database2. In this situation an external TM might be necessary to rollback database2's commit when the database1's commit aborts - Is my understanding correct ? Please clear up. Thanks in advance. |
Yes, I think your understanding is correct, but there is one more scenario that you must consider.
If you are using a non-coordinated automatic transaction, the database and MQ commits are done in sequence after the flow instance has run. There is a theoretical possibility that MQ commit fails after the database operation has been committed successfully, which would leave the system in inconsistent state.
If you think you can live with that or if it does not harm if an entry may be inserted in the database twice, not at all or after manually processing the backout queue, or trying to insert the same entry twice would cause a constraint violation and a database exception anyway, you may perhaps do without an XA transaction. |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Thu May 16, 2013 4:34 pm Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Esa- do you mean that, using 1PC, after a commit is sent out to database, the flow can never roll it back if the subsequent MQ commit failed? Does the flow, once the commit is sent out, even wait for the response on the commit operation ?
Using 1PC (no XA), if for eg: database commit follows after MQ commit. If the later database commit fails after the previous MQ commit, does the flow back out the MQ commit ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 16, 2013 7:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Easy answer is NO. YOU would have to write a COMPENSATING transaction and execute it. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Esa |
| Posted: Thu May 16, 2013 10:01 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| sunny_30 wrote: |
Esa- do you mean that, using 1PC, after a commit is sent out to database, the flow can never roll it back if the subsequent MQ commit failed? Does the flow, once the commit is sent out, even wait for the response on the commit operation ?
Using 1PC (no XA), if for eg: database commit follows after MQ commit. If the later database commit fails after the previous MQ commit, does the flow back out the MQ commit ? |
Of course it waits for the commit response, otherwise you wouldn't know if it failed or not.
Keep in mind that message flow instance are always run in one single thread. The kind of parallellism that I suppose you are supposing does not exist.
And: database commit does not follow MQ commit, it preceeds it. People please correct me if I'm wrong, but to me the opposite would not make sense.
It the preceeding database commit fails, MQ operations are rolled back. You don't have to write a compensating transaction for a failed transaction.
The problem -- the probability of which is very very small, as you perhaps can imagine -- is that if the MQ commit fails, the message will be retried
and there is no way to know if the database operation has been committed or not. Unless you can somehow test it from the database itself.
To determine if you need to do something about the scenario, answer this simple question:
"Is there money in the message?" |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Sat May 18, 2013 7:31 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
| Esa wrote: |
| Of course it waits for the commit response, otherwise you wouldn't know if it failed or not. |
Let me summarize this: The 1PC flow is a single UOW, in this case if its inserting into a DB & later writing to a Queue, the flow initially runs the instance, determines that both MQ & DB are commit-able & sends a commit to both participants DB & MQ in that order (or is it at same time?). The flow waits for response for its commit to DB, but if it fails, the flow cannot send an immediate rollback to the DB (1PC limitation) but as it has full control on the MQ queue (as MQ is not an external participant), it could even at this stage, even after sending a commit to the queue, it can still get the queue commit to rollback?
| Esa wrote: |
| database commit does not follow MQ commit, it preceeds it. People please correct me if I'm wrong, but to me the opposite would not make sense.. |
I agree my question may not make much sense in terms of implementation. But the scenario is still possible to code in the flow. It is just a Question- so please assume its possible to implement this way.. More importantly what Im trying to understand here (or get an answer for) is that, if MQ commit is sent prior to the DB commit (as per the order of nodes the flow) will it still make any difference in the outcome/ behavior of MQ & DB if the order of execution reverses ( compared to the question in previous section) ?
| Esa wrote: |
| there is no way to know if the database operation has been committed or not.. |
Correct- I agree the window is very small, coz the flow instance has already run to make sure all connections are working fine- so very rarely it could fail during commit phase. If 2PC(XA) is used, after the instance is run & it is ready, it sends a prepare-commit instead of commit, which is relatively safer but but does it mean even 2PC cannot be 100% reliable or ensure consistency (for eg: what happens after the TM never heard back after it has eg: say it sent a rollback to RMs, coz it never heard back from 1 of the RMs in the previous commit phase..) ?
I know I may be complicating the question (actually- myself, Im finding it a bit difficult to understand this whole thing- so please excuse me for that). To be frank, this whole confusion started, when I as a WMB guy was mentioning to the Oracle person (who is a working on a stored procedure for WMB flow to invoke) at my work, asking him not to explicitly commit in the stored-proc, & always check for duplicates. I said WMB will run an automatic 1PC transaction but its not 100% reliable unless XA is setup. So- he came back saying that WMB is not a good tool, (figured I wasnt 100% sure what Im talking about ..) & he cannot rely on it, & now he is saying that he will put an explicit commit at the end of stored-proc, so Oracle has full control on it.. OMG- I couldnt give him a straight answer (' '). Looks like now Im almost there to get back to him...haha
Really appreciate your help ! Let me know if Im correct in the above assumptions & please clarify. Thank you !!! |
|
| Back to top |
|
|
| Esa |
| Posted: Sun May 19, 2013 4:58 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| sunny_30 wrote: |
| if MQ commit is sent prior to the DB commit (as per the order of nodes the flow) |
The order of nodes is not important. All commits are done only after the flow instance has run, and it's always MQ commit that comes last.
Let's put it like this: if your flow only operates against one single datasource, you normally don't need an XA transaction.
The queue manager is always local and you can trust that MQ is able to commit if it has been able to issue the requested operation.
Meaning: if a put operation fails because the queue is full or something, you will get an exception and the db commit is not even tried.
If you update several datasources from the same flow, then you may need a coordinated transaction.
Think about a situation where the first datasource is committed but the second fails. In that case backing out MQ transaction doesn't help
and you must issue a compensating transaction to return to the consistent starting point. |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Mon May 20, 2013 7:00 pm Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
| Thank you for the info Esa ! Really appreciate !!! |
|
| 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
|
|
|
|
