| Author |
Message
|
| zpat |
 Posted: Mon Feb 16, 2009 2:42 am Post subject: Accessing a remote database from message flow |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
This must be a fairly common requirement but I am interested in how it's generally solved. AIX, WMQ v6, WMB v6.0, Database on i-Series.
We want to have a message queue which contains messages with information to be inserted into a database by a WMB message flow using a compute node (EQSL).
The database is on a different platform to the message broker.
What happens if the database is not available when the message flow tries to access it? I assume an exception is thrown and the message will propagate to the failure terminal of the MQINPUT node?
If this is not connected - it will presumably roll-back and get re-processed and then moved to the backout-requeue queue when the backout threshold is reached?
Is this the best way to handle this? What do other people do in this situation?
What I would want to happen is the messages remain on the original queue until successfully processed and the database update retried at a reasonable interval. How could this be coded? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Feb 16, 2009 2:55 am Post subject: Re: Accessing a remote database from message flow |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| I assume an exception is thrown and the message will propagate to the failure terminal of the MQINPUT node? |
Or the first connected failure terminal of a downstream node (typically a TryCatch node)
| zpat wrote: |
| If this is not connected - it will presumably roll-back and get re-processed and then moved to the backout-requeue queue when the backout threshold is reached? |
Yes. Hence the use of a try block to divert the error.
| zpat wrote: |
| Is this the best way to handle this? What do other people do in this situation? |
We use a Filter node to weed out transient errors (like database) from permanent errors and route them accordingly.
| zpat wrote: |
| What I would want to happen is the messages remain on the original queue until successfully processed and the database update retried at a reasonable interval. How could this be coded? |
Why the original queue? This interferes with poison message handling. We use a cron job to move the contents of the "transient" errors queue back onto the original queue at intervals, subject to some checking about how many times they've gone round the loop. This is achieved by some hand-rolled code and the <usr> folder.
You could probably manage something similar with Timer nodes now, but this mechanism pre-dates them.
Other solutions are undoubtably possible and may be superior. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Feb 16, 2009 3:15 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| Or the first connected failure terminal of a downstream node (typically a TryCatch node) |
I think you mean "Or the first connected catch terminal..."
Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Feb 16, 2009 3:19 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
OK so using an error (re-queue) queue and timer node to re-submit them to the original queue at intervals is definitely one option.
Can anyone give me some examples of likely transient and permanent errors to handle?
Last edited by zpat on Mon Feb 16, 2009 3:25 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 16, 2009 3:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mgk wrote: |
| Quote: |
| Or the first connected failure terminal of a downstream node (typically a TryCatch node) |
I think you mean "Or the first connected catch terminal..."
|
D'oh! 
It's the smell of Windolene in here; fumes right up my nose. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
