| Author |
Message
|
| veeru_hyd |
 Posted: Wed Jan 05, 2011 2:23 am Post subject: MQoutput Roll back |
 |
|
Novice
Joined: 28 Oct 2010
Posts: 23
|
Hi,
I have a requirement as follows.
MQInput---Compute---MQOutput----Compute(DBInsert)
My flow should be in the position to avoid to put the message in MQOutput node or roll back that message from Mqoutput, if any failure occured while inserting into the database.
Thanks,
Veera |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Jan 05, 2011 2:47 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
So how is this question different from this one -> http://www.mqseries.net/phpBB2/viewtopic.php?t=56174
That was posted last friday?
_________________
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 |
|
|
| veeru_hyd |
| Posted: Wed Jan 05, 2011 4:28 am Post subject: |
|
|
Novice
Joined: 28 Oct 2010
Posts: 23
|
Yes the same requirement, i have infront of me. But it looks incomplete. I have tried all these.
As well as i tried by using flow order node.
First: connected to MQOutput
Second terminal: Connected to perform the DB Operation.
MQOutput Message is processing as usual.
IF Transaction mode: Yes. It is waiting till finishes the whole transaction and processing the MQOutput Message As usual(Message is not rolling back incase DBFailure, other flow which is listening is processing)
If the Transaction mode : No. First terminal transaction(Other flow which is listning that queue is pickingup and processing) is not waiting till finishes the second terminal transaction.
But my requirement is, listeneing flow should not process till the DBoperation succeeded.
Thanks,
Veera |
|
| Back to top |
|
|
| optimist |
| Posted: Wed Jan 05, 2011 5:47 am Post subject: |
|
|
Apprentice
Joined: 18 Nov 2010
Posts: 33
|
Once again, your flow above will not do what you want to do, since the DB update can only start AFTER a transaction commit on the MQ Output Queue. You have to take the time to read and understand why it is so.
You have a possibility using a Flow Order though. I assume your DB trabsaction is not being enlisted in the overall transaction scope. Since you can have one 1 phase resource in a 2 phase commit transaction, you can reverse the output connections in the flow order and achieve what you want to do.
In other words, connect the first terminal from Flow Order to DB update & the second to MQ Output. If there is a failure during DB update, you can rollback the entire transaction. If not, the transaction can proceed to put a message on the output queue. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Jan 05, 2011 5:55 am Post subject: Re: MQoutput Roll back |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| veeru_hyd wrote: |
Hi,
I have a requirement as follows.
MQInput---Compute---MQOutput----Compute(DBInsert)
My flow should be in the position to avoid to put the message in MQOutput node or roll back that message from Mqoutput, if any failure occured while inserting into the database.
Thanks,
Veera |
Maybe you already tried this or it does not meet your requirement, but could you possibly do this :
MQInput -> Compute -> Compute(DbInsert) -> MQOutput
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| veeru_hyd |
| Posted: Wed Jan 05, 2011 6:40 am Post subject: |
|
|
Novice
Joined: 28 Oct 2010
Posts: 23
|
Thanks for your valuable response
That will work, but my requirement is different, after placing the message on to the queue the state should be inserted with the current failure indiaction state name, which indicates or maintain the record in database that the message processed successfully.
Thanks,
Veera |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Jan 05, 2011 6:44 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| veeru_hyd wrote: |
Thanks for your valuable response
That will work, but my requirement is different, after placing the message on to the queue the state should be inserted with the current failure indiaction state name, which indicates or maintain the record in database that the message processed successfully.
Thanks,
Veera |
Then add a Compute(DbRollback/DbReversePost) node on the right side of the MQOutput node connected to the appropriate terminal (perhaps Failure).
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Wed Jan 05, 2011 6:48 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
To be clear - your requirement is to audit whether the message was put successfully to the output queue or not, and if the auditing fails, back out the business transaction? But you do not want the business transaction to back out of its own accord preventing the auditing happening?
If that is so you certainly could meet that requirement (think about inserting the success audit after the MQOutput but the failure audit where you catch the exception) but you should be aware that most auditing systems are designed not to impact the business transaction if e.g. the audit database was full. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Jan 05, 2011 7:06 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| vmcgloin wrote: |
To be clear - your requirement is to audit whether the message was put successfully to the output queue or not, and if the auditing fails, back out the business transaction? But you do not want the business transaction to back out of its own accord preventing the auditing happening?
If that is so you certainly could meet that requirement (think about inserting the success audit after the MQOutput but the failure audit where you catch the exception) but you should be aware that most auditing systems are designed not to impact the business transaction if e.g. the audit database was full. |
There are several good solutions to this:
1.
MQInput -> Compute -> Compute(DbInsert) -> MQOutput -> (MQO failure terminal) -> Compute(DbUpdate status of transaction)
2.
MQInput -> Compute -> Compute(DbInsert) -> MQOutput
...... Compute(DbUpdate status) -> Catch of MQOutput unhappy path
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| optimist |
| Posted: Wed Jan 05, 2011 12:26 pm Post subject: |
|
|
Apprentice
Joined: 18 Nov 2010
Posts: 33
|
Like "lancelotlinc" says above, you have to break your logic into two parts (Because of the transaction scope rules within MQ, you cannot do both ie., status of processing from the queue & as well as the DB update with the above status, in one shot. It will work for the happy path though).
If you decide to use Flow Order instead, then:
First terminal : DB Insert (insert with a status of "message processing in progress")
Second terminal: MQ Output
Note: In the rare event that you fail to put the message on the MQ Output queue, you need to handle the "undo" of the above message insert manually be means of a compensating transaction.
Now, within the flow that kicks off from the MQ Output, you need to update the status of the above row from "in progress" to either "complete" (or) "failed".
Not sure if this is what you wanted to accomplish... |
|
| Back to top |
|
|
|
|
