| Author |
Message
|
| international |
 Posted: Wed Sep 20, 2006 4:14 am Post subject: MQOutput node and rollback |
 |
|
Apprentice
Joined: 19 Jun 2006
Posts: 37
|
Hello.
How can an uncommitted MQPut get rolled back?
I have a simple flow. An MQInput node is connected to an MQOutput node (with "Transaction Mode = Yes"). Downstream of the MQOutput node I have a Compute node which divides by zero, resulting in a runtime exception which rolls back to the MQInput node where it is caught and written to a trace file.
The MQPut is successfully committed once the flow completes (i.e. when the trace node has completed its I/O).
This makes sense in the context of "the MQOutput I/O is transactional so is committed once the flow completes". However, it doesn't make sense from an application design perspective, where you would expect the MQPut to be backed out when the stream rolled back past the MQOutput node.
Is there any way round this, or is there no way to back out an MQPut once its been made?
cheers
Tony |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Sep 20, 2006 4:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| international |
| Posted: Wed Sep 20, 2006 4:56 am Post subject: |
|
|
Apprentice
Joined: 19 Jun 2006
Posts: 37
|
| The documentation actually suggests that rollback will occur at the MQ level. The Uncoordinated Auxiliary Transactions topic suggests that MQ UOW is done separately to the "main" UOW. It also talks about the "state of the system remaining unchanged" if a rollback occurs - no mention there that the MQ state remaining changed (i.e. an uncommitted put exists). Rather, it strongly suggests that an MQ rollback occurs - which doesn't happen of course. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 20, 2006 5:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm confused.
First you say "The MQPut is successfully committed once the flow completes (i.e. when the trace node has completed its I/O). "
Then you say "an uncommitted put exists".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| international |
| Posted: Wed Sep 20, 2006 5:31 am Post subject: |
|
|
Apprentice
Joined: 19 Jun 2006
Posts: 37
|
To make it clearer what my objection/query is, lets start again:
We have a simple flow - MQInput node connected to a TryCatch connected to a Compute node (Compute1) connected to an MQOutput node connected to a Compute node (Compute2).
The Compute1 node does some tinkering with the Root, the MQOutput node has "Transaction Mode = Yes" and the Compute2 node does a divide by zero.
A message is consumed, gets propagated past the MQOutput node (where an MQPut is issued but not committed ) and gets as far as Compute2 where a runtime exception occurs. The stream is rolled back to the TryCatch node where the Root is restored to its previous state (i.e. all Compute1 changes are rolled back). The MQPut however has not been rolled back. It is still in an uncommitted state and will remain so until a subsequent propagation downstream of the TryCatch Catch terminal ends successfully (resulting in an commit of the MQPut) or, as you say, a THROW is ultimately made back to the MQInput node (with no Catch connection, resulting in a backout of the MQPut).
This just seems wrong! The rollback should rollback everything, including the MQPut. Hence my question - I was wondering if I'd missed a trick, and that there was a way of causing the MQPut to be backed out at the same time and along with the other rollback processing. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Wed Sep 20, 2006 5:50 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi international,
I think Jeff's link explains what ur looking for
| Quote: |
Updates made by a coordinated flow are committed when the flow successfully completes processing the input message. The updates are backed out if:
1. Any node within the flow throws an exception that is not caught by a node other than the input node, and
2. The input node’s catch terminal is not connected.
|
Regards. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 20, 2006 5:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
As far as your application logic is concerned, the Put hasn't happened yet when you go to the Catch terminal of the Try/Catch node.
The fact that it's uncommitted, rather than explictly rolled back, shouldn't matter.
Just like it shouldn't matter to you if Broker has actually garbage collected anything from "rolling back" the changes made in Compute1. Those things haven't happened yet and your code is perfectly safe in acting that way.
If you need to make a decision on whether to rethrow and cause the transaction to get rolled back, you can look at the ExceptionList you get.
And, again, the documentation is fairly clear that the transaction is NOT rolled back until the flow ends UNSUCCESSFULLY. It's that last bit that gets most people, they fail to understand that they have to let the *Input node go to it's failure terminal to cause the flow to... fail.
If you want to have some fun, you can look at what happens when you go back to the same MQOutput node from your Catch block.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| international |
| Posted: Wed Sep 20, 2006 6:03 am Post subject: |
|
|
Apprentice
Joined: 19 Jun 2006
Posts: 37
|
| I guess I'm too picky. I want to be able to issue "rollback" (or have Root,Local Env etc. rollback occur in sync with I/O rollback), rather than having to hop skip and jump my way up rolled back streams, back downstream with my error processing (including an MQPut - out of syncpoint of course!) and then make sure I throw enough to bypass all TryCatches and eventually arrive back at an MQInput node with the Catch terminal unattached! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 20, 2006 6:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I guess I've always been glad that Broker has completely simplified transactional handling, and I don't have to worry about whether a particular resource will be committed or rolled back and at what state it's in at what point in the flow.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 20, 2006 6:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| international wrote: |
| I guess I'm too picky. |
Maybe, but why not? All this IT is supposed to make things easier! 
IMHO (and I stress the My), I find the way failure is handled easy to code for. Depends on the design naturally, but I find it's much better to run down an ExceptionList to try and determine a problem. From this, I throw back to the input node as something of a last resort, triggering a more serious "You'll never guess what's happened now" message if the backout queue gets used! 
(It's always an embarassingly serious problem when the impossible error happens......  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
