Author |
Message
|
santy |
Posted: Fri Jul 31, 2009 7:33 am Post subject: WMB Code- Database Interactions |
|
|
Centurion
Joined: 03 Nov 2006 Posts: 141
|
Hi
I have a code written in 6.0 which inserts and updates the records in Database.
I want the messages to stay on input queue if the database goes down.
Is this scenario can be achived through WMB?
Thanks |
|
Back to top |
|
 |
broker_new |
Posted: Fri Jul 31, 2009 7:40 am Post subject: |
|
|
 Yatiri
Joined: 30 Nov 2006 Posts: 614 Location: Washington DC
|
The correct way of implementing it is route the messages to an error queue and reprocess them when DB is back up.
Otherwise:
I remember you will receive a negative SQLCODE when the database is down in that case you have to either use the IA9Z(WebSphere Message Broker - Job Execution Node) to stop the message flow or use JCN to execute the script which will stop the message flow using mqsistopmsgflow. |
|
Back to top |
|
 |
santy |
Posted: Fri Jul 31, 2009 7:49 am Post subject: |
|
|
Centurion
Joined: 03 Nov 2006 Posts: 141
|
yes, I worked on SQLCODE, it works fine, based on that itself I want my messages to stay on input queue/stop the processing of message flows.
Can you tell me where can I find information about IA9Z(WebSphere Message Broker - Job Execution Node) ? |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Jul 31, 2009 7:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
In fact, it's very easy to accomplish this in WMB, without doing anything fancy.
Just fail to properly define a backout queue and backout retry count on the input queue, and ensure that you do not connect the failure terminal of the MQInput node and that all errors get thrown back to the MQinput node in the first place.
Then the message flow will sit in an infinite loop retrying the database, and logging errors, and using up system resources and generally making a mess of things.
But it won't leave the input queue until the database is working again. |
|
Back to top |
|
 |
santy |
Posted: Fri Jul 31, 2009 7:57 am Post subject: |
|
|
Centurion
Joined: 03 Nov 2006 Posts: 141
|
yes, I worked on SQLCODE, it works fine, based on that itself I want my messages to stay on input queue/stop the processing of message flows.
Can you tell me where can I find information about IA9Z(WebSphere Message Broker - Job Execution Node) ? |
|
Back to top |
|
 |
jbanoop |
Posted: Fri Jul 31, 2009 8:00 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005 Posts: 401 Location: SC
|
Define a backout queue for your message flow's input queue and set a backout threshold as you would like.
In the flow if the DB is down and an exception is thrown, allow the flow to roll back completely to the input node.
Then depending on the backout threshold the message would be moved to your backout queue. (If BO Threshold is 2 , the flow will try twice with that same message before moving it to the backout queue).
It is always good to create MB flows with backout queues and in most cases it is advisable and makes business sense to roll back the whole flow.
Hope it helps. |
|
Back to top |
|
 |
smdavies99 |
Posted: Fri Jul 31, 2009 8:07 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
santy wrote: |
Can you tell me where can I find information about IA9Z(WebSphere Message Broker - Job Execution Node) ? |
Follow the link at the top of the page to the IBM Support PAcks site. _________________ 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 |
|
 |
santy |
Posted: Fri Jul 31, 2009 8:12 am Post subject: |
|
|
Centurion
Joined: 03 Nov 2006 Posts: 141
|
If the BOTHRESH is set 2 and message gets replayed twice, so after second attemp will the message move the DEAD LETTER Queue? |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jul 31, 2009 8:13 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
santy wrote: |
If the BOTHRESH is set 2 and message gets replayed twice, so after second attemp will the message move the DEAD LETTER Queue? |
Or a backout queue if one is defined _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
santy |
Posted: Fri Jul 31, 2009 8:19 am Post subject: |
|
|
Centurion
Joined: 03 Nov 2006 Posts: 141
|
Hi Vitor, Do you mean the messages will stay on backout queue after trying 2 attempts.
if I sepcify the details as - BOQNAME( LOCALQ ) BOTHRESH(2) ?
If yes then, how the messages come to know when to try for next time, I mean if the DB is up ? |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jul 31, 2009 8:34 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
santy wrote: |
Hi Vitor, Do you mean the messages will stay on backout queue after trying 2 attempts. |
Yes
santy wrote: |
If yes then, how the messages come to know when to try for next time, I mean if the DB is up ? |
How does "the system" determine the DB is back up? Whatever makes that determination moves them back. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
santy |
Posted: Fri Jul 31, 2009 8:59 am Post subject: |
|
|
Centurion
Joined: 03 Nov 2006 Posts: 141
|
Hi Vitor,
if the messages are going to stay on backout queue after restrying attempts, then they will be continuasly monitored by message flows, if the input queue name and backout queue name is same.
This may lead to infine looping situation.
For eg.
QUEUE(LOCALQ) TYPE(QLOCAL)
ACCTQ(QMGR) ALTDATE(2008-12-01)
ALTTIME(14.46.4 BOQNAME(2)
BOTHRESH(LOCALQ) |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jul 31, 2009 9:05 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
santy wrote: |
Hi Vitor,
if the messages are going to stay on backout queue after restrying attempts, then they will be continuasly monitored by message flows, if the input queue name and backout queue name is same.
This may lead to infine looping situation.
For eg.
QUEUE(LOCALQ) TYPE(QLOCAL)
ACCTQ(QMGR) ALTDATE(2008-12-01)
ALTTIME(14.46.4 BOQNAME(2)
BOTHRESH(LOCALQ) |
This is a) pointless and b) leads to the situation mqjeff was talking about.
What you need is BOQNAME(BACKQ) and a mechanism to move the messages from BACKQ to LOCALQ when the DB is back up. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jbanoop |
Posted: Fri Jul 31, 2009 9:35 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005 Posts: 401 Location: SC
|
your flow will not only have DB errors . It is very likely that different situations might cause a variety of exceptions to occur in the flow.
Eg: You could have bad data that causes a parser error.
If you do not have a backout queue and the transaction rolls back to the MQInput node, that message will remain there at the front of the queue causing other (possibly valid) messages to pile up behind that while the flow continuously tries to process the corrupt message.
Ideally any errors should be logged using a possibly horizontal error handling mechanism so that the people responsbile for maintainence of the system(s) can be alerted. They should decide what needs to be done to rectify the situation and move the messages back to the input queue once the issue has been resolved.
In general you cannot code a flow in such a way that it self-recovers / self-corrects from every possible infrastructure/system errors.
Hope it helps. |
|
Back to top |
|
 |
|