What we're not seeing is the connection handle re-establish after the first message is caught as an exception, the subsequent messages also error.  May be this is because of the XA configuration we have put in place.  

Also, in terms of sharing the database for broker and application usage this was run past IBM and is documented in there manuals as something that is supported.  We also wanted to avoid dedicating an entire Oracle database just for the brokers use.


"Robert Broderick" <[EMAIL PROTECTED]>

Sent by: "MQSeries List" <[EMAIL PROTECTED]>

16-Nov-2004 18:05
Please respond to "MQSeries List" <[EMAIL PROTECTED]>


        To:        MQSERIES

        Subject:        Re: WBIMB Broker restart without Broker restart

You are going to get two different exception thrown. (at least as of 2.1, I
have not verified if this is the case on 5.0). The first on is that the
database is not available. The second is that the connection handle is

When the database is taken offline the flow reacts with the DB not
available. When the DB comes back online the first attempt to access the
database fails with a message that the current handle is not valid
(something like that). At this point you reprocess the message and all
should work ok. What we did, if memory serves me right was to turn write a
message to a queue and throw an exception in the CATCH connection that
caught the DB error and place the message back on the queue. The message
that was written triggered a queue that shut down the flow. We had a script
that ran every so often that would query the DB. If it was online it would
check the queue and it it was "GET DISABLED" it would reenable it so
processing could start again. Simple and it worked.

OH BTW....if you are using the Broker or Configuration Manager DB for an
application dbatabase STOP IT or you will go blind!!!!!

FRom a pure operations standpoint. the Broker and Configuration amanger DB's
are infrastructure databases. Application should not be allowed to store
data in these databases. They are used for subscriptions and aggregation
besides the normal broker stuff. These DB's are under the ownership of the
IBM WBI suite of applications. You risk infrastruction issues with WBIMB and
possibly your application by keeping application data there. (just my two


>From: "Kulbir S. Thind" <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>Subject: WBIMB Broker restart without Broker restart
>Date: Tue, 16 Nov 2004 16:38:39 +0000
>In a scenario where the WBIMB broker database is restarted without the
>WBIMB broker being restarted we find that flows throw exceptions when
>processing messages as the connection handle for the database is not
>valid.  Eventually, however the broker manages to re-establish connection
>with the broker and continue processing as normal.
>Ideally we should be re-starting the broker if the underlying database is
>restarted, however for various reasons we want to be able to handle the
>scenario above.  Is there a way of tuning WBIMB so that it refreshes its
>connection handles more regularly?
>Also, please note that the database used serves two purposes, its the
>broker internal database and the database used by the message flows for
>lookups, etc.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Reply via email to