Perhaps you are correct in that the onException gets fired within the bounds of the transaction thus making the operation, as a whole, atomic. However, and keep in mind that I am still learning Camel, from what I can tell the onException fires within the bounds of the transaction and the <handled><constant>true</constant></handled> elements are basically telling Camle that "everything is ok" which means that things do not get rolled back. In my case, I am trying to catch specific exceptions that are thrown from the restulful service (which means that no work happened...i.e. no DB updates or anything), and push the message onto the DLQ to get it out of the way. Essentially saying that those messages are bad and I don't/can't process them.
If I let the transaction rollback, then I have the message on the queue still and then run the risk of trying to process it a second time which will result in the same scenario and most likely end up in an endless loop. Unless I configure the redelivery policy to only attempt to redeliver N times as opposed to an infinite numer of times. On Fri, Jun 8, 2012 at 7:30 AM, James Carman-2 [via Camel] < ml-node+s465427n5714184...@n5.nabble.com> wrote: > You want it to be atomic with the get from the input queue don't you? It > would make sense to me. > On Jun 8, 2012 7:13 AM, "gramanero" <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5714184&i=0>> > wrote: > > > Now that you mention it, one might think that, but that does not appear > to > > be the case. With the DLQ put in the onException clause, the DLQ put > does > > not rollback. I think that is where the Handled clause comes into play. > > > > On Fri, Jun 8, 2012 at 7:10 AM, James Carman-2 [via Camel] < > > [hidden email] <http://user/SendEmail.jtp?type=node&node=5714184&i=1>> > wrote: > > > > > Won't the dlc "put" be in the transaction too? That would rollback > too, > > > thus nothing ever happened. > > > On Jun 8, 2012 6:56 AM, "James Carman" <[hidden email]< > > http://user/SendEmail.jtp?type=node&node=5714181&i=0>> > > > wrote: > > > > > > > Try it with client cache control. Take a look at my example. > > > > > > > > On Fri, Jun 8, 2012 at 6:47 AM, gramanero <[hidden email]< > > http://user/SendEmail.jtp?type=node&node=5714181&i=1>> > > > wrote: > > > > > No, it is not rolling back if you use the Handles element with a > > > > constant value of true. If you use the Continue element then I > believe > > > it > > > > will roll back. > > > > > > > > > > Sent from my iPod > > > > > > > > > > On Jun 7, 2012, at 11:46 PM, "James Carman [via Camel]" < > > > > [hidden email] <http://user/SendEmail.jtp?type=node&node=5714181&i=2>> > > > > wrote: > > > > > > > > > >> Your transaction isn't rolling back if you "handle" the > exception, > > is > > > > it? > > > > >> > > > > >> On Thu, Jun 7, 2012 at 12:21 PM, gramanero <[hidden email]> > 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" clause...at > > > least > > > > I > > > > >> > think it is a clause). > > > > >> > > > > > >> > Hope that helps. > > > > >> > > > > > >> > -- > > > > >> > View this message in context: > > > > > > > > > > http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714139.html > > > > >> > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > >> > > > > >> > > > > >> If you reply to this email, your message will be added to the > > > > discussion below: > > > > >> > > > > > > > > > > http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714151.html > > > > >> To unsubscribe from Transacted vs DeadLetterQueue, click here. > > > > >> NAML > > > > > > > > > > > > > > > -- > > > > > View this message in context: > > > > > > > > > > http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714179.html > > > > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > > > > > > > > > > ------------------------------ > > > If you reply to this email, your message will be added to the > discussion > > > below: > > > > > > > > > http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714181.html > > > To unsubscribe from Transacted vs DeadLetterQueue, click here< > > > > > > > . > > > NAML< > > > http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml > > > > > > > > > > > > > -- > > View this message in context: > > > http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714182.html > > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714184.html > To unsubscribe from Transacted vs DeadLetterQueue, click > here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5713992&code=Z3JhbWFuZXJvQGdtYWlsLmNvbXw1NzEzOTkyfC0xNjAyMDYxMDQz> > . > NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://camel.465427.n5.nabble.com/Transacted-vs-DeadLetterQueue-tp5713992p5714194.html Sent from the Camel - Users mailing list archive at Nabble.com.
