camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henryk Konsek <hekon...@gmail.com>
Subject Re: Need for XA?
Date Mon, 06 Jan 2014 21:30:07 GMT
> 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

Mime
View raw message