Hi Eric You are touching some grounds there that many hasn't done so often ;)
The Camel transactional stuff is documented here: http://activemq.apache.org/camel/transactional-client.html There is a JIRA ticket to improve this documentation. We target this for Camel 1.5, but since its wiki documentation the docs is online. Back to your problem: I had a peek and I am also a bit puzzled why Camel's TransactionInterceptor isn't testing for isFailed() and doesn't set the rollbackonly flag on the spring tx manager. http://static.springframework.org/spring/docs/2.5.x/reference/transaction.html You could try changing the TransactionInterceptor code in Camel to test for the isfailed, eg: This is my code I am trying with right now: public void process(final Exchange exchange) { transactionTemplate.execute(new TransactionCallbackWithoutResult() { protected void doInTransactionWithoutResult(TransactionStatus status) { try { // begin transaction (actually its done by Spring, wrapping this template) LOG.debug("Transaction begin"); processNext(exchange); // if the exchange failed then mark it as rollback if (exchange.isFailed()) { LOG.debug("Transaction rollback"); status.setRollbackOnly(); return; } // exchange success so we mark it for commit LOG.debug("Transaction commit"); } catch (Throwable t) { LOG.debug("Transaction rollback"); status.setRollbackOnly(); // TODO: Should we rethrow the exception now that we marked it for rollback? throw new RuntimeCamelException(t); } } }); } I guess it would be great to get the attention of the original contributor on this transaction support in Camel = James. Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: EJLeVin1 [mailto:[EMAIL PROTECTED] Sent: 28. juni 2008 20:57 To: [email protected] Subject: Transaction policy not correctly rolling back on exception. Hi Everyone, So I have been working on this issue for almost the past 15 hours straight and can't seem to find the solution. I created a simply maven project to display what I am seeing. I have thus far been unable to get a JMS transaction manager (defined as a policy in my camel route) to force redelivery from AMQ on an exception occurring. I looked through the user forum and went through a bunch of the examples, but unfortunately, it was to no avail. All you need to do to run the test is extract the zip (renamed to .zzz for the post) and execute 'mvn test' and you should see the results I am seeing... :) Here is a quick breakdown: from("activemq:queue:TestQueue") .errorHandler(noErrorHandler()) //We don't want a local re-delivery policy .policy(required) //Set the transactional client before the error producing processor .process(errorProducingProcessor) //This processor will throw exceptions on messages .to("mock:foo"); when I do not throw exceptions, the route works perfectly in my test case; however, when I have the errorProducingProcessor in my route, the transaction manager still seems to commit the message. I have noticed something strange in the way the exceptions are occurring, maybe it is my lack of understanding for the route exception handling, but when I throw an exception from my processor, it doesn't seem to be thrown down to the transaction manager as I would expect. I debugged the transaction processor code and the exchange.isFailed() is returning true when it reaches the TransactionInterceptor, but it doesn't actually throw the exception as the try..catch within the class is expecting (or so it seems to me). Any idea as to why the exceptions wouldn't be getting thrown as one would expect? Any help in this matter is greatly appreciated. Thanks so much! -Eric -- View this message in context: http://www.nabble.com/Transaction-policy-not-correctly-rolling-back-on-exception.-tp18173845s22882p18173845.html Sent from the Camel - Users mailing list archive at Nabble.com.
