Hi I suggest to check the EIP http://camel.apache.org/transactional-client.html
And if you have a copy of Camel in Action, then chapter 9 is all about transactions. The source code of the book is freely available to peek Also the unit tests of the camel components itself can be worthwhile https://svn.apache.org/repos/asf/camel/trunk/components/camel-jms/src/test/ For ActiveMQ, often all you need is to set transacted=true, and .transacted() in the Camel route. Although if you use blueprint, you would need to refer to the transacted policy by its id. You dont need to setup the transacted error handler explicitly, Camel will automatic do that when you use .transacted. And yes for performance then the cache level of the consumer can make a big difference. And mind that if you use XA you may not be able to use caching as some TX managers dont work well with that. http://camel.apache.org/jms On Mon, Jul 9, 2012 at 5:58 PM, Thomas Johansen <thxm...@gmail.com> wrote: > Hi, > > Are there any working examples with a Camel transacted route and ActiveMQ > endpoints? There are a lot of parameters to toggle, and my test is not > quite working. > > Essentially I have a route like this: > > SpringTransactionPolicy transactionalPolicy = new > SpringTransactionPolicy(transactionManager); > transactionalPolicy.setPropagationBehaviorName("PROPAGATION_REQUIRED"); > from("activemq:SourceQueue") > .errorHandler(transactionErrorHandler(transactionPolicy)) > .transacted().policy(transactionPolicy) > .inOut(myProcessor) > .inOnly("activemq:TargetQueue"); > > I have also configured the broker with an individual dead letter strategy: > > <individualDeadLetterStrategy > queuePrefix="DLQ." > useQueueForQueueMessages="true" > processExpired="true" > processNonPersistent="false"/> > > If something fails in the route (ie. in myProcessor or producing to target > queue) I wish to have the message placed on the "DLQ.SourceQueue". A test I > created triggers a "ResourceAllocationException: Usage Manager Store is > Full" when producing to the target, as the broker is configured with a low > (enough) store usage. However, after the rollback the message is neither on > SourceQueue, TargetQueue, DLQ.SourceQueue nor DLQ.TargetQueue. I actually > would expect the message to still be on the SourceQueue, as there is no > store space to move the message to either of the other queues. > > Is this as expected? I need to know how to prevent message loss in all > cases... > > BR, > Thomas -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen