| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Rollback on DB-exception |
« View previous topic :: View next topic » |
| Author |
Message
|
| sunny_30 |
 Posted: Tue Sep 25, 2012 11:57 am Post subject: |
 |
|
Master
Joined: 03 Oct 2005
Posts: 258
|
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Sep 25, 2012 1:44 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sunny_30 wrote: |
| lancelotlinc wrote: |
| You'll have to try out your theory. I think you will find that your database INSERT will not rollback once execution has moved past the Compute node that the INSERT took place. |
As long as the INSERT is not committed, & the flow is part of UOW, i expect the DB-operations to rollback on flow-error, even if no XA has been configured. Lets wait for some1 to confirm |
As has been mentioned, compute nodes are indeed transactional with respect to the database actions they take, provided they're not configured NOT to be.
But the commit or rollback of those transactions occurs based on the success or failure of the FLOW, not of the NODE.
If you are constructing a message flow that you know will need to roll back transactional actions that occur downstream of the input node that starts the flow, you need to make sure that any exception handling you wire to the input node DOES NOT connect to the failure terminal and that the logic that is connected to the catch terminal DOES end with a Throw node.
Lancelotlinc's experience with transactions is almost certainly due to a slight misunderstanding of that - he's had to code compensation logic because his exception handling is expected to complete the flow instance successfully rather than causing the flow to throw errors to the system log.
| lancelotlinc wrote: |
Sounds like we need a wager. I'd like a Bud light lime if my theory is validated on your system. |
that's not beer, why would you drink it? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Sep 25, 2012 11:02 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
| lancelotlinc wrote: |
Sounds like we need a wager. I'd like a Bud light lime if my theory is validated on your system. |
that's not beer, why would you drink it? |
Agreed. Any beer where the brewer is proud of 'using Rice' in the brew certainly isn't a beer (According to the German Beer Laws) and yes I have been to a Bud Brewery. I visited the one in Merrimack NH when I was working in Maynard MA back in the 1980's. . To add lime to it is a throwback to the 1970's (Lager & Lime).
Mines a pint of H.B.B., T.E.A, 6X, any Ringwood brew or Harveys Best.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Wed Sep 26, 2012 6:01 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Thank you mqjeff
| mqjeff wrote: |
| If you are constructing a message flow that you know will need to roll back transactional actions that occur downstream of the input node that starts the flow, you need to make sure that any exception handling you wire to the input node DOES NOT connect to the failure terminal and that the logic that is connected to the catch terminal DOES end with a Throw node. |
1) if there is a parsing error in MQinput, & the failure terminal is not connected, will the message take its catch terminal, if connected ?
2) in theory, even if both failure & catch terminals are connected, and both end with a throw node (failure) shdnt that suffice for transaction-rollback of the flow operations ? |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Sep 27, 2012 2:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
| Lancelotlinc's experience with transactions is almost certainly due to a slight misunderstanding of that ... |
If lancelotlinc believes that the message flow ought to roll back uncommitted database operations for caught Exceptions as well as for uncaught Exceptions, then that would explain a lot.
| sunny_30 wrote: |
| 1) if there is a parsing error in MQinput, & the failure terminal is not connected, will the message take its catch terminal, if connected? |
No. The Catch terminal (if connected) only catches downstream Exceptions, and the Failure terminal (if connected) only handles errors within the node itself. This is generally true for all the nodes that have Catch and Failure terminals.
| sunny_30 wrote: |
| 2) in theory, even if both failure & catch terminals are connected, and both end with a throw node (failure) shdnt that suffice for transaction-rollback of the flow operations? |
Yes. In this case, the MQInput node can propagate its message to one of two mutually exclusive paths:- MQInput.Out -> Exception -> MQInput.Catch -> Exception -> roll back
- MQInput.Failure -> Exception -> roll back
So, the nodes in the Failure path don't need to worry about uncommitted operations in the Out/Catch path, because there aren't any. (And vice versa.) |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Thu Sep 27, 2012 7:23 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
| mqjeff wrote: |
| If you are constructing a message flow that you know will need to roll back transactional actions that occur downstream of the input node that starts the flow, you need to make sure that any exception handling you wire to the input node DOES NOT connect to the failure terminal and that the logic that is connected to the catch terminal DOES end with a Throw node. |
Assume an MQInput node is being used. If the parsing errors inside this node have to be 'examined', then I believe the failure terminal must be connected. But for rollback to occur, the failure path needs to end with an exception (throw).
rekarm01, Im just elaborating the error-paths you depicted.
please let me know if Im correct
| Code: |
If MQInput.Out (transactional/persistent)-> Exception ->
If MQInput.catch connected:
MQInput.Catch -> Exception ->
If MQInput.failure connected:
MQInput.Failure -> Exception -> RollBack
else RollBack
else
If MQInput.failure connected:
MQInput.Failure -> Exception -> RollBack
else RollBack
else If (eg: parsing-error)
If MQInput.failure connected:
MQInput.Failure -> Exception -> RollBack
else RollBack |
|
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Sep 27, 2012 6:58 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| sunny_30 wrote: |
| Assume an MQInput node is being used. If the parsing errors inside this node have to be 'examined', then I believe the failure terminal must be connected. |
Or, the MQInput node could set 'On Demand' parsing, instead of 'Immediate' or 'Complete'. Then any parsing errors occur in the Out flow, and can be handled in the Catch flow.
| sunny_30 wrote: |
| Im just elaborating the error-paths you depicted. please let me know if Im correct |
Not quite. Within a message flow transaction, it is impossible to propagate a message from the Out/Catch flows to the Failure flow, (or vice versa):
| Code: |
If (no internal error) MQInput.Out -> Exception ->
If MQInput.catch connected:
MQInput.Catch -> Exception -> RollBack
else
RollBack
else If (internal error)
If MQInput.failure connected:
MQInput.Failure -> Exception -> RollBack
else
RollBack |
While it might appear that a message can propagate from MQInput.Out -> MQInput.Catch -> MQInput.Failure, this is actually two separate transactions:- try: queue -> no error -> MQInput.Out -> Exception -> MQInput.Catch -> Exception -> roll back -> backout
- retry: queue -> internal error (bothreshold?) -> MQInput.Failure -> Exception -> roll back -> backout
Each transaction commits/rolls back its own operations, and any exception information from the first transaction is discarded before the second transaction.
Consult the InfoCenter here, here, and here, for more details. |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Fri Sep 28, 2012 6:35 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Thanks much for the detail info & the links.
I actually did refer to those links sometime before, but found the info in this old redbook misleading/ conflicting (atleast to me ):MB v6 - Bullet Proofing Message Flows
please refer to the flowchart on page-6, its showing that in a situation mqInput-out resulted in an exception to 'flow back' to the mqinput node, both when catch terminal is not connected (or) if connected & catch flow resulted in a failure, the mqInput-failure path is taken, if connected. As per the chart, the BOQ-threshold check comes in the next step, after the failure-path is taken !
I found this latest infocenter link much helpful |
|
| 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
|
|
|
|
