This content has been marked as final. Show 5 replies
When the DB is down you have to pause the queue for consumption, this can be done directly on Weblogic console or scripted in WSLT or in Java.
I'm assuming you have scheduled DB shutdowns for maintenance, i.e. you know previously when your DB will be down, otherwise your requirement doesn't make much sense... The DB should be supposed to be up all the time and if it's down is an exception, and should be treated as exception by your JMS configuration as well... You can do it by tuning the message redelivery/expiration parameters in order for it to remain in the queue and keep retrying long enough until the DB is up again...
Hope this helps...
When the DB is up, should the messages be processed as soon as they are placed on the queue or do you want them to be scheduled even when DB is up?
The most usual scenario for handling DB outages is to implement reliable messaging and is NOT done by disabling/enabling polling based on DB state. It is usually achieved by ensuring that the polling from JMS queue and publish to DB happens within same global transaction. If you make sure that all the processing is happening in a global transaction then the messages will not be committed(and deleted) from the source queue when DB is down because DB adapter will fail to write messages to a DB when its down and throw an error which will roll back the transaction. You can configure retry properties on JMS side to ensure that messages when failed are retried only after some time, allowing to give some time for DB to come up and reducing number of retries.