XA transactions are usually only needed if you have multisystem transactions to be coordinated. So if you read from a JMS queue and because of that store a message in a database then send a message on to another queue, you want both the DB and the JMS to roll back if there is a 500 error calling a web site or something. For that you need XA. If you are just going broker queue to queue tyou dont need XA.
*Robert Simmons Jr. MSc. - Lead Java Architect @ EA* *Author of: Hardcore Java (2003) and Maintainable Java (2012)* *LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39 <http://www.linkedin.com/pub/robert-simmons/40/852/a39>* On Fri, Jan 3, 2014 at 3:33 AM, Henryk Konsek <hekon...@gmail.com> wrote: > Hi Tom, > > > In our application we have a lot of routes that follow the same pattern: > > read a message, do some processing, update/insert in the database and > then > > send a message to the next route. > > (...) > > do we need XA transactions (...) ? > > That's right. You don't need XA to transactionally process your > message flow. Plain local JMS transaction, ActiveMQ reredelivery > mechanism and some Camel magic will be fine here. :) > > Just mark consumer endpoint as transactional [1] (as demonstrated on > the snippet below) and ActiveMQ will handle the message redelivery for > you. > > <from uri="activemq:div.line"/> > <transacted/> > <bean ref="divServiceActivator" method="validateDivLine"/> > > Keep in mind that ActiveMQ broker will keep the message in div.line > queue until the transaction will be committed by the Camel at the end > of the route (after sending message to div.line.processed queue). If > divServiceActivator will throw the exception during the DB update, the > Camel will not commit and message incoming from div.line will be > redelivered by the broker. You can control how many times message will > be redelivered by the broker on the ActiveMQ configuration level [2]. > > Now is the tricky part. Notice that it is still possible that Camel > can fail to commit JMS transaction *after* successful DB update (power > outages happen). That would mean that incoming message will be > redelivered and processed twice. To handle this situation and keep > your system state concise make divServiceActivator#persistDivVehicle() > bean invocation idempotent [3], so it won't try to alter database > twice. You can also try to make > divServiceActivator#persistDivVehicle() operation idempotent on the > business logic level (sometimes it is as trivial as checking if entity > with given ID hasn't been persisted already). > > Cheers. > > [1] http://camel.apache.org/transactional-client.html > [2] http://activemq.apache.org/message-redelivery-and-dlq-handling.html > [3] http://camel.apache.org/idempotent-consumer.html > > -- > Henryk Konsek > http://henryk-konsek.blogspot.com >
