ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WMB Code- Database Interactions

Post new topic  Reply to topic
 WMB Code- Database Interactions « View previous topic :: View next topic » 
Author Message
santy
PostPosted: Fri Jul 31, 2009 7:33 am    Post subject: WMB Code- Database Interactions Reply with quote

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
View user's profile Send private message
broker_new
PostPosted: Fri Jul 31, 2009 7:40 am    Post subject: Reply with quote

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
View user's profile Send private message
santy
PostPosted: Fri Jul 31, 2009 7:49 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Fri Jul 31, 2009 7:49 am    Post subject: Reply with quote

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
View user's profile Send private message
santy
PostPosted: Fri Jul 31, 2009 7:57 am    Post subject: Reply with quote

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
View user's profile Send private message
jbanoop
PostPosted: Fri Jul 31, 2009 8:00 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
smdavies99
PostPosted: Fri Jul 31, 2009 8:07 am    Post subject: Reply with quote

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
View user's profile Send private message
santy
PostPosted: Fri Jul 31, 2009 8:12 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Jul 31, 2009 8:13 am    Post subject: Reply with quote

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
View user's profile Send private message
santy
PostPosted: Fri Jul 31, 2009 8:19 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Jul 31, 2009 8:34 am    Post subject: Reply with quote

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
View user's profile Send private message
santy
PostPosted: Fri Jul 31, 2009 8:59 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Jul 31, 2009 9:05 am    Post subject: Reply with quote

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
View user's profile Send private message
jbanoop
PostPosted: Fri Jul 31, 2009 9:35 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WMB Code- Database Interactions
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.