> If the write operation to the database and the system consuming from > the second queue is idempotent, ie they can both gracefully handle > that the same message is processed twice. Then you can think about > skipping XA.
100% true. Keep also in mind that even if the DB service itself is not idempotent, you can usually still make it such be using Camel's idempotent consumer [1] pattern. > In the scenario you describe I would defiantly consider using XA just > to be safe. Actually I can't agree with the sentence above. If the resources taking part in the transaction are idempotent (DB service and second queue in discusses case) then you can safely resign from XA. There is no place for "just to be safe" here, as idempotent-based processing model is 100% safe. Moreover, I would even say that you *should* resign from XA whenever it is possible. XA transactions come with really heavy performance, latency and scalability penalty. In case of Camel it is not only the matter of the raw XA performance issues, but also JMS component [2] performance (Camel can't cache JMS consumers while using XA). Actually even the one of the most famous articles dedicated for messaging (Starbucks Does Not Use Two-Phase Commit [3] by G. Hohpe) basically says that XA should be avoided on the favor of the idempotent consumers and local transactions. In my humble opinion you should have really good reason to use heavy XA, instead of idempotent-based processing which perform and scales like a hell. Creating bottlenecks in the system should have really good explanation :) . Cheers. [1] http://camel.apache.org/idempotent-consumer.html [2] http://camel.apache.org/jms.html [3] http://www.eaipatterns.com/ramblings/18_starbucks.html -- Henryk Konsek http://henryk-konsek.blogspot.com
