camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: Transacted vs DeadLetterQueue
Date Thu, 07 Jun 2012 16:26:10 GMT
Sorry, didn't see the rest of your message.  Anyway, the problem
you're going to face here is that suppose you do some stuff (database
inserts, place messages on queues, etc.) between your input queue and
your web service.  That "stuff" needs to get rolled back when you have
an issue and route your message to the DLC.  If you tell Camel you've
"handled" the exception, the transaction doesn't rollback and your
message goes to DLC.  So, you are sending your message to the
dead-letter channel where you may potentially replay it later and some
of the "stuff" that needs to go on during the processing of that
message has already taken place as a result of the committed
transaction.  Therein lies the issue.

On Thu, Jun 7, 2012 at 12:23 PM, James Carman
<> wrote:
> Your transaction isn't rolling back if you "handle" the exception, is it?
> On Thu, Jun 7, 2012 at 12:21 PM, gramanero <> wrote:
>> I have tested the case of using a route specific onException clause within a
>> transaction and it appears to work as I would expect (or hope). So I have a
>> route that is transactional and the final endpoint in the route throws an
>> exception I forced my restful service to just throw an exception). Without
>> the onException clause the message lands back in the queue as you would
>> expect due to it running within a transaction. With the onException clause,
>> I look for specific exceptions and if it is one of the exceptions that I
>> have specified I tell tell Camel that the exception has been "handled" (via
>> the handled clause) and I route the message to the dead letter queue, thus
>> moving the "bad message" out of the way of the messages remaining on the
>> queue. I think the key here is the use of the "handled" clause that tells
>> Camel that the message has been handled and therefore to NOT rollback the
>> transaction. The alternative choice is to tell Camel to "continue" on with
>> its normal processing which would have rolled back the transaction and put
>> the message back onto the queue (via the "continue" least I
>> think it is a clause).
>> Hope that helps.
>> --
>> View this message in context:
>> Sent from the Camel - Users mailing list archive at

View raw message