| Author |
Message
|
| misun |
 Posted: Mon Dec 06, 2010 1:02 pm Post subject: TimeoutNotification and Throw to rollback transaction |
 |
|
Newbie
Joined: 06 Dec 2010
Posts: 6
|
Hi,
I've developed a flow triggered by TimeoutNotification and when it experience an error, it should Throw the error and rollback the transaction. When I was developing I was expecting it to behave like how MQ input queue would work with 0 backout allowance. However with TimeoutNotification node, it would endlessly retry the error and won't rollback.
How do I actually cause an error to terminate the flow started by TimeoutNotification node?
Thanks heaps in advance |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Dec 06, 2010 1:36 pm Post subject: Re: TimeoutNotification and Throw to rollback transaction |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| misun wrote: |
| How do I actually cause an error to terminate the flow started by TimeoutNotification node? |
You need to connect the Catch and Failure terminals & not abend as described here
| misun wrote: |
| When I was developing I was expecting it to behave like how MQ input queue would work with 0 backout allowance |
Why? That link clearly states, for a number of scenarios:
| Quote: |
| the TimeoutNotification node tries to process the message again until the problem is resolved. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 06, 2010 1:40 pm Post subject: Re: TimeoutNotification and Throw to rollback transaction |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| misun wrote: |
| how MQ input queue would work with 0 backout allowance. |
Slightly off topic, but the MQInput node doesn't have a 0 backout allowance; it has the backout allowance specified on the queue it's reading.
Not relevant to this problem and more for the benefit of future readers who may stumble across this thread. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| misun |
| Posted: Mon Dec 06, 2010 1:48 pm Post subject: |
|
|
Newbie
Joined: 06 Dec 2010
Posts: 6
|
I do have catch and failure node connected to TimeoutNotification, but if I handle the error, the flow doesn't rollback as I expected.
The problem I have is, the flow write an output queue then try to update the database. If it have problem updating the database, it should retrieve back the message sent to the output queue. With proper error handling, the sent messages are still in the output queue... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Dec 06, 2010 2:11 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Your problem is really to do with transactionality.
If the write to the WMQ Output Queue is not comitted then if the DB update fails a rollback of the thread will also rollback the WMQ Write.
My suggestion is to read up me the subject of transactionality & Units of work.
_________________
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 |
|
|
| misun |
| Posted: Mon Dec 06, 2010 2:59 pm Post subject: |
|
|
Newbie
Joined: 06 Dec 2010
Posts: 6
|
I've created a simplified version:
TimeoutNotification (TransactionMode=yes) - MQOutput (TransactionMode =yes) - Throw
with TimeoutNotification's catch node connected to Trace
The output queue still have the message in it after the Throw.
How do I make it really transactional? I must be missing something... |
|
| Back to top |
|
|
| misun |
| Posted: Mon Dec 06, 2010 5:25 pm Post subject: |
|
|
Newbie
Joined: 06 Dec 2010
Posts: 6
|
I couldn't figure out alternative solution.
Ended up adding queue logic between the TimeoutNotification and rest of the flow.
TimeoutNotification - OutputQueue
InputQueue - rest of the flow |
|
| Back to top |
|
|
| fatherjack |
| Posted: Tue Dec 07, 2010 3:25 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| misun wrote: |
I've created a simplified version:
TimeoutNotification (TransactionMode=yes) - MQOutput (TransactionMode =yes) - Throw
with TimeoutNotification's catch node connected to Trace
The output queue still have the message in it after the Throw.
How do I make it really transactional? I must be missing something... |
Again the doc is pretty clear. It says:
| Quote: |
| The message is written to the Catch terminal as part of the same transaction, and if the flow connected to the Catch terminal handles the error successfully the transaction is committed. |
But I see your problem as
| Quote: |
| •If the TimeoutNotification node has already propagated the message to the Catch terminal and an exception is thrown in the flow connected to the Catch terminal, the message is returned to the TimeoutNotification node. The TimeoutNotification node writes the error to the local error log and tries to process the message again. |
ad infinitum. Maybe in your catch terminal flow you need to cancel the timeout request. Will that work?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| misun |
| Posted: Tue Dec 07, 2010 5:02 pm Post subject: |
|
|
Newbie
Joined: 06 Dec 2010
Posts: 6
|
I've tried modifying the OutputLocalEnvironment's request and set it to CANCEL right before the flow Throw. If I view the message in debug mode between TimeoutNotification and the first node, the message is as it was originally.
I came to think of new possible scenario though.
Is there a way to delete the uncommitted messages written into the output within the flow's exception handling?
MQGet wouldn't work cause it's uncommitted. Any other ways...? |
|
| Back to top |
|
|
|
|
