I have a requirement to pick(or consume) messages from Woblogic JMS Queue only when DB is UP.
When DB is down, messages should remain in queue. When DB is up, messaged should be picked on scheduler basis.
We are using SOA suite 11g(BPEL or mediator,JMS Adapter).
What is the best way to achive it in SOA 11g.
I tried, but when I setup a Consumer, there is no control over there. Messages are picked automatically.
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...
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.
why dont you set the retry options in the fault policies?
So if the external DB is down you could reprocess them after specified interval or make it go to human retry queue.
Then you could use SOA api to retry all of them.