jms - Need help to handle MDB Exception in two ways -

i'm trying handle 2 different types of problems while processing message.

the first problem if remote database down. in case, message should stop processing, , try again later. message should never go dlq, , should keep trying until remote database up.

the second problem when there problem message. in case, should go dlq.

how should structuring following code?

@override public void onmessage(message message) {     try {      // processing     messageprocessing(message);  // should dlq if message bad      // save database     putnamedlocation(message);  // <<--- exception when external db down      } catch (exception e) {         logger.error(e.getmessage());         mdc.setrollbackonly();     } } 

assuming can detect bad messages definitively in code body of mdb, write bad messages dlq directly. gives bit more freedom perhaps categorize error , optionally send different types of bad messages different "dlq-like" queues, and/or apply time-to-live dlq'ed messages no-hope-of-ever-being-processed type messages don't pile in queue ever. can add @resource annotated instance variables mdb class referencing connectionfactory , queue references support sending of messages target dlq. bottom line is, make sure detect error , dlq message yourself.

as db being down, can detect catching exceptions when acquiring connection or writing updates. in case, clean resources , throw runtimeexception. cause message redelivered, want check jms configuration 2 things:

1. make sure max-redelivery count high enough, otherwise count tick on , message dlqed anyway.
2. if jms implementation supports it, add redelivery delay rejected messages allow time db come up, otherwise messages endlessly spin in deliver/reject loop.

to avoid #2 (which tricky if jms implementation not support redilvery delay, webspheremq), can use jboss jmx management interface mdb stop (and later restart) delivery on mdb. however, can't inside mdb in same thread processing message because mdb wait message complete processing, can't because waiting mdb stop, can't because...[and on] so... best bet start sort of sentry polls db , when finds down, stops mdb , when finds again, restarts it. see question snippet on how that.

that last part should deal unexpected exceptions resulting message validations. (i.e. db fine, reason message totally fubar resulting in uncaught exceptions causes message redelivered). since down-db messages should not redelivered more few times (on account of sentry), can check message's redelivery count , if ridiculously high know have poison message , can ditch it, or dlq it.

hope that's helpful.