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...
Thank you Vlad.
Basically, this is to address unexpected external DB outages in BPEL design. BPEL Scheduler(may be quartz) should check external DB first and then go and pick messages available in JMS Queue.
thank you agian.
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.
something wrong with the design.
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.
When the DB is up, should the messages be processed as soon as they are placed on the queue And scheduler for only unprocessed during DB outage.