You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Mikeycmccarthy <Mi...@gmail.com> on 2012/02/15 23:46:52 UTC
Correct situation to use XA
Hi all, two weeks into using camel in earnest and loving it already :)
One point of confusion though...I have a very simple route, message off of a
queue and into a database (using a DAO type bean though in preference to the
JDBC component). If the write to the db fails I want to take a few attempts
to write again then eventually pop it back on the queue for later
consumption.I am using spring 3.1 and camel 2.9.
My question is, should I be using XA to do this? I have setup atomikos but
am getting mixed advice from the manuals (maybe I am just reading it wrong).
The camel book and the activemq page on XA on the site say I should really
be using XA. The camel site page on using Spring for transaction management
seems to suggest Spring will take care of the transactionality of the entire
route.
Is XA the correct option for what I am doing?
Many thanks
--
View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487694.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Correct situation to use XA
Posted by Mikeycmccarthy <Mi...@gmail.com>.
Hi Babak,
I actually raised a separate thread on the polling from the queue stuff -
http://camel.465427.n5.nabble.com/Checking-a-message-is-back-on-the-queue-td5489222.html.
What I mean was inspecting the queue during a unit test to see what is on
there. I was under the impression that this is what
consumer.receiveBodyNoWait was intended to do, but as you already have a
route setup you can't add a second consumer.
Anyways, probably off topic. Appreciate the XA advice!
On 16 February 2012 11:55, Babak Vahdat [via Camel] <
ml-node+s465427n5489302h70@n5.nabble.com> wrote:
> Hi
>
> > Thanks all - this is essentially my issue, that there seem to be
> multiple different ways of achieving the same thing. I'm using the book as
> a base for all my learning, checking the website for any new stuff we get
> by using the later version of Camel. The original thinking with XA is it
> seems to be exactly what the book example is demonstrating in the section
> on XA. I'm guessing what Claus is saying is that in this case XA is
> overkill.
>
> Thanks God every body in the forum can freely express his own opinion, I
> did that as well as Claus where both were personal opinions. As I used to
> have exactly the same situation as you I though I could give back some
> lessons learned. In my case (JBoss (5.1)) it was IBM WebSphere MQ
> (camel-jms) and DB2 z/OS (camel-jpa) both of which are XA-complaint.
> However as Claus already said the setup of XA is not that easy. So consult
> your vendor's documentation for a correct setup of your XA-Resources.
>
> > At the end of the day a decent test should prove both working. I've got
> a test that simulates the database breaking, but my issue is I can't seem
> to do consumer.receiveBodyNoWait to check the queue as it complains about
> me introducing a second consumer for the same route. I'll raise this as a
> separate point on the forums if it's not covered already. I notice in the
> chapter nine example tests that it's the DLQ that gets inspected not the
> original queue.
>
> Don't poll activley from the JMS queue by yourself but just let camel-jms
> do it for you inside the DSL:
>
> from(jms:queue:...)
>
> > To answer some of Babak's points:
>
> > - I use Spring 3.1 and put the exclusion on the camel dependency. It all
> seems to work fine like this. Having said that we aren't using new features
> of Spring quite yet so if there's a reason to avoid using 3.1 then let us
> know. I've been using dependency:tree to make sure we have only a single
> version of the jars at the same level, but obviously with that level being
> 3.1 in this case.
>
> I hope at least at this point Claus does agree with me ;-) IMHO you should
> NOT do that. Camel 2.9.0 has been intensively tested with Spring 3.0.7 and
> who would guarantee you that Spring 3.1 is 100% binary backward compatible
> (not even Jürgen Höller :-)). Maven is all about TRANSITIV dependency
> management, so better rely on the version Maven recommends you. Probably in
> some corner cases (negative-testing) you would trigger some logic both in
> Camel and/or Spring where it's not part of your everyday App-Flow and
> suddenly BOOM! "NoClassDefFoundError", "NoSuchMethodError", "LinkageError"
> etc.
>
> > - Even though we do deploy to Jboss, we tend to do most most things
> within in the app rather than rely on the container. Again, I don't know if
> this is good or bad, it's just the way stuff seems to be done here.
> Presumably if we were going to rely on jboss doing the XA stuff we'd need
> to include these dependencies at test time for our integration tests.
>
> No, XA-TM of JBoss (Arjuna) is sitting there but you can NOT rely on him
> to the the Job for you as somebody has to TALK to him. You have (at least)
> two options for this:
>
> - Either talk to him DIRECTLY (through JNDI) using the plain JTA
> UserTransaction API, begin() commit() rollback() etc. However it's NOT
> trivial at all to code a correct transaction-demarcation along your 2
> XA-Resources.
> - Delegate this hard job to Spring JtaTransactionManager!
>
> Last but not least you've got two feedbacks in this free-mind-space-forum,
> think about them carefully and make you own way...
>
> Good luck!
>
> Babak
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489302.html
> To unsubscribe from Correct situation to use XA, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5487694&code=TWlrZXljbWNjYXJ0aHlAZ21haWwuY29tfDU0ODc2OTR8LTE5MTEzMDE4NTI=>
> .
> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489312.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Correct situation to use XA
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi
> Thanks all - this is essentially my issue, that there seem to be multiple
> different ways of achieving the same thing. I'm using the book as a base
> for all my learning, checking the website for any new stuff we get by
> using the later version of Camel. The original thinking with XA is it
> seems to be exactly what the book example is demonstrating in the section
> on XA. I'm guessing what Claus is saying is that in this case XA is
> overkill.
Thanks God every body in the forum can freely express his own opinion, I did
that as well as Claus where both were personal opinions. As I used to have
exactly the same situation as you I though I could give back some lessons
learned. In my case (JBoss (5.1)) it was IBM WebSphere MQ (camel-jms) and
DB2 z/OS (camel-jpa) both of which are XA-complaint. However as Claus
already said the setup of XA is not that easy. So consult your vendor's
documentation for a correct setup of your XA-Resources.
> At the end of the day a decent test should prove both working. I've got a
> test that simulates the database breaking, but my issue is I can't seem to
> do consumer.receiveBodyNoWait to check the queue as it complains about me
> introducing a second consumer for the same route. I'll raise this as a
> separate point on the forums if it's not covered already. I notice in the
> chapter nine example tests that it's the DLQ that gets inspected not the
> original queue.
Don't poll activley from the JMS queue by yourself but just let camel-jms do
it for you inside the DSL:
from(jms:queue:...)
> To answer some of Babak's points:
> - I use Spring 3.1 and put the exclusion on the camel dependency. It all
> seems to work fine like this. Having said that we aren't using new
> features of Spring quite yet so if there's a reason to avoid using 3.1
> then let us know. I've been using dependency:tree to make sure we have
> only a single version of the jars at the same level, but obviously with
> that level being 3.1 in this case.
I hope at least at this point Claus does agree with me ;-) IMHO you should
NOT do that. Camel 2.9.0 has been intensively tested with Spring 3.0.7 and
who would guarantee you that Spring 3.1 is 100% binary backward compatible
(not even Jürgen Höller :-)). Maven is all about TRANSITIV dependency
management, so better rely on the version Maven recommends you. Probably in
some corner cases (negative-testing) you would trigger some logic both in
Camel and/or Spring where it's not part of your everyday App-Flow and
suddenly BOOM! "NoClassDefFoundError", "NoSuchMethodError", "LinkageError"
etc.
> - Even though we do deploy to Jboss, we tend to do most most things within
> in the app rather than rely on the container. Again, I don't know if this
> is good or bad, it's just the way stuff seems to be done here. Presumably
> if we were going to rely on jboss doing the XA stuff we'd need to include
> these dependencies at test time for our integration tests.
No, XA-TM of JBoss (Arjuna) is sitting there but you can NOT rely on him to
the the Job for you as somebody has to TALK to him. You have (at least) two
options for this:
- Either talk to him DIRECTLY (through JNDI) using the plain JTA
UserTransaction API, begin() commit() rollback() etc. However it's NOT
trivial at all to code a correct transaction-demarcation along your 2
XA-Resources.
- Delegate this hard job to Spring JtaTransactionManager!
Last but not least you've got two feedbacks in this free-mind-space-forum,
think about them carefully and make you own way...
Good luck!
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489302.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Correct situation to use XA
Posted by Mikeycmccarthy <Mi...@gmail.com>.
Thanks all - this is essentially my issue, that there seem to be multiple
different ways of achieving the same thing. I'm using the book as a base
for all my learning, checking the website for any new stuff we get by using
the later version of Camel. The original thinking with XA is it seems to be
exactly what the book example is demonstrating in the section on XA. I'm
guessing what Claus is saying is that in this case XA is overkill.
At the end of the day a decent test should prove both working. I've got a
test that simulates the database breaking, but my issue is I can't seem to
do consumer.receiveBodyNoWait to check the queue as it complains about me
introducing a second consumer for the same route. I'll raise this as a
separate point on the forums if it's not covered already. I notice in the
chapter nine example tests that it's the DLQ that gets inspected not the
original queue.
To answer some of Babak's points:
- I use Spring 3.1 and put the exclusion on the camel dependency. It all
seems to work fine like this. Having said that we aren't using new features
of Spring quite yet so if there's a reason to avoid using 3.1 then let us
know. I've been using dependency:tree to make sure we have only a single
version of the jars at the same level, but obviously with that level being
3.1 in this case.
- Even though we do deploy to Jboss, we tend to do most most things within
in the app rather than rely on the container. Again, I don't know if this
is good or bad, it's just the way stuff seems to be done here. Presumably
if we were going to rely on jboss doing the XA stuff we'd need to include
these dependencies at test time for our integration tests.
On 16 February 2012 08:55, Claus Ibsen-2 [via Camel] <
ml-node+s465427n5488917h35@n5.nabble.com> wrote:
> On Wed, Feb 15, 2012 at 11:46 PM, Mikeycmccarthy
> <[hidden email] <http://user/SendEmail.jtp?type=node&node=5488917&i=0>>
> wrote:
>
> > Hi all, two weeks into using camel in earnest and loving it already :)
> >
> > One point of confusion though...I have a very simple route, message off
> of a
> > queue and into a database (using a DAO type bean though in preference to
> the
> > JDBC component). If the write to the db fails I want to take a few
> attempts
> > to write again then eventually pop it back on the queue for later
> > consumption.I am using spring 3.1 and camel 2.9.
> >
> > My question is, should I be using XA to do this? I have setup atomikos
> but
> > am getting mixed advice from the manuals (maybe I am just reading it
> wrong).
> > The camel book and the activemq page on XA on the site say I should
> really
> > be using XA. The camel site page on using Spring for transaction
> management
> > seems to suggest Spring will take care of the transactionality of the
> entire
> > route.
> >
> > Is XA the correct option for what I am doing?
> >
>
> No. XA is complicated, overkill, and hard to setup, and leads to false
> impressions, that a message can never be lost.
> Its better to architect a system, to detect duplicate messages, and
> allow messages to be replayed in case of failures.
> XA is slow and not so many people use it. Also not all resources
> participating in a XA works well together. You have to
> test this throughly.
> Disclaimer: This is my personal opinion.
>
> In your case, if writing to the DB is the last "step" in the
> processing of the message. Then a regular single resource transaction
> from the JMS broker is often sufficient. If writing to the DB fails,
> then an exception is thrown, and that exception can be conveyed back
> to the JMS TX manager, which then issues a rollback. A rollback in JMS
> broker in transacted mode, is in fact a non-ack. So for example if the
> server crashes after the DB has thrown an exception, then the message
> is still on the JMS queue, when the server restarts. The JMS broker in
> transacted mode, is in fact, waiting for a commit (= ack) of the
> message before its regarded as successfully consumed.
>
>
> Chapter 9 in the Camel in Action has such an example.
>
>
>
>
> > Many thanks
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487694.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: [hidden email]<http://user/SendEmail.jtp?type=node&node=5488917&i=1>
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5488917.html
> To unsubscribe from Correct situation to use XA, click here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5487694&code=TWlrZXljbWNjYXJ0aHlAZ21haWwuY29tfDU0ODc2OTR8LTE5MTEzMDE4NTI=>
> .
> NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489016.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Correct situation to use XA
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Feb 15, 2012 at 11:46 PM, Mikeycmccarthy
<Mi...@gmail.com> wrote:
> Hi all, two weeks into using camel in earnest and loving it already :)
>
> One point of confusion though...I have a very simple route, message off of a
> queue and into a database (using a DAO type bean though in preference to the
> JDBC component). If the write to the db fails I want to take a few attempts
> to write again then eventually pop it back on the queue for later
> consumption.I am using spring 3.1 and camel 2.9.
>
> My question is, should I be using XA to do this? I have setup atomikos but
> am getting mixed advice from the manuals (maybe I am just reading it wrong).
> The camel book and the activemq page on XA on the site say I should really
> be using XA. The camel site page on using Spring for transaction management
> seems to suggest Spring will take care of the transactionality of the entire
> route.
>
> Is XA the correct option for what I am doing?
>
No. XA is complicated, overkill, and hard to setup, and leads to false
impressions, that a message can never be lost.
Its better to architect a system, to detect duplicate messages, and
allow messages to be replayed in case of failures.
XA is slow and not so many people use it. Also not all resources
participating in a XA works well together. You have to
test this throughly.
Disclaimer: This is my personal opinion.
In your case, if writing to the DB is the last "step" in the
processing of the message. Then a regular single resource transaction
from the JMS broker is often sufficient. If writing to the DB fails,
then an exception is thrown, and that exception can be conveyed back
to the JMS TX manager, which then issues a rollback. A rollback in JMS
broker in transacted mode, is in fact a non-ack. So for example if the
server crashes after the DB has thrown an exception, then the message
is still on the JMS queue, when the server restarts. The JMS broker in
transacted mode, is in fact, waiting for a commit (= ack) of the
message before its regarded as successfully consumed.
Chapter 9 in the Camel in Action has such an example.
> Many thanks
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487694.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Correct situation to use XA
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Feb 16, 2012 at 11:52 AM, Babak Vahdat
<ba...@swissonline.ch> wrote:
> Hi
>
> Yeah of course, like many other people around the world I was also one of
> the first readers of that "Kicks Ass" book back in December 2010 as I
> intended to setup my first App using Apache Camel with NO previous
> knowledege about it.
>
> I'm deeply thankful to BOTH Claus & Jonathan who provided such a wonderful
> book. And if buying that book of mine could help Claus for just 0.1 cents to
> enjoy his (well known) swiss made coffee machine [1], well that makes me
> more than happy...
>
> @Claus I hope you enjoy that swiss made quality :-)
>
> [1]
> http://davsclaus.blogspot.com/2011/11/coffe-machine-and-camel-in-action.html
>
Yep the swiss quality is outstanding. It works every time, and is easy to use.
I spoke to my colleague G.Nodet whom also has a Jura machine.
> Babak
>
>
>
> surya aditya wrote
>>
>> Babak,
>>
>> Thanks for such informative reply. Would like to add there is one full
>> chapter dedicated for handling transactions with camel in 'Camel in
>> Action'
>> book by Claus, et al.
>>
>> peace,
>>
>> On Wed, Feb 15, 2012 at 6:54 PM, Babak Vahdat
>> <babak.vahdat@>wrote:
>>
>>> Hi
>>>
>>> Given your use case using XA you're definetly on the right way! What you
>>> need is a *global* transaction and not a *local* one as you need the
>>> orchestration of the transaction boundries along the way through JMS
>>> together with your DB.
>>>
>>> If you would make use of local transaction managers, let's say spring
>>> JmsTransactionManager and DatasourceTransactionManager then you would
>>> already commit your jms message consumption through camel-jms before
>>> inserting the data into the DB. But then if you would violate some
>>> DB-Constraints while inserting the data then the message has been already
>>> consumed from the JMS point of view (alread commited). Making use of XA
>>> in
>>> this case has the advantage of not lossing any unsuccessfully processed
>>> message. So using XA you have a real "unit-of-work" while dealing with
>>> more
>>> than one single "resource". Following some notes:
>>>
>>> - You don't have to pop the message back on the queue for later
>>> consumption
>>> by yourself (as you said), as that's already given for free through the
>>> transaction (rollback of JMS message consumption).
>>>
>>> - If you run your App inside a JEE container then rely on its XA-TM, for
>>> example JBoss makes use of Arjuna. And then let Spring
>>> JtaTransactionManager
>>> talk to it. But if you run standalone then atomikos is a good choice.
>>>
>>> - Make sure your JMS provider has a meaningful setup for exhaustion of
>>> failed JMS messages otherwise you get the "poission message effect". For
>>> example Apache ActiveMQ exhausts after 6 retries after which it puts the
>>> unconsumed message into DLQ.
>>>
>>> - Don't use spring version 3.1 but the one Camel 2.9 relies on (3.0.7).
>>> if
>>> you make use of Maven for your build then you will get that dependency
>>> transitively for free if you would depend on camel-spring. Using "mvn
>>> dependency:tree" would show you already now that you've got a dependency
>>> conflict by your POM.
>>>
>>> Babak
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487888.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489165.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Correct situation to use XA
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi
Yeah of course, like many other people around the world I was also one of
the first readers of that "Kicks Ass" book back in December 2010 as I
intended to setup my first App using Apache Camel with NO previous
knowledege about it.
I'm deeply thankful to BOTH Claus & Jonathan who provided such a wonderful
book. And if buying that book of mine could help Claus for just 0.1 cents to
enjoy his (well known) swiss made coffee machine [1], well that makes me
more than happy...
@Claus I hope you enjoy that swiss made quality :-)
[1]
http://davsclaus.blogspot.com/2011/11/coffe-machine-and-camel-in-action.html
Babak
surya aditya wrote
>
> Babak,
>
> Thanks for such informative reply. Would like to add there is one full
> chapter dedicated for handling transactions with camel in 'Camel in
> Action'
> book by Claus, et al.
>
> peace,
>
> On Wed, Feb 15, 2012 at 6:54 PM, Babak Vahdat
> <babak.vahdat@>wrote:
>
>> Hi
>>
>> Given your use case using XA you're definetly on the right way! What you
>> need is a *global* transaction and not a *local* one as you need the
>> orchestration of the transaction boundries along the way through JMS
>> together with your DB.
>>
>> If you would make use of local transaction managers, let's say spring
>> JmsTransactionManager and DatasourceTransactionManager then you would
>> already commit your jms message consumption through camel-jms before
>> inserting the data into the DB. But then if you would violate some
>> DB-Constraints while inserting the data then the message has been already
>> consumed from the JMS point of view (alread commited). Making use of XA
>> in
>> this case has the advantage of not lossing any unsuccessfully processed
>> message. So using XA you have a real "unit-of-work" while dealing with
>> more
>> than one single "resource". Following some notes:
>>
>> - You don't have to pop the message back on the queue for later
>> consumption
>> by yourself (as you said), as that's already given for free through the
>> transaction (rollback of JMS message consumption).
>>
>> - If you run your App inside a JEE container then rely on its XA-TM, for
>> example JBoss makes use of Arjuna. And then let Spring
>> JtaTransactionManager
>> talk to it. But if you run standalone then atomikos is a good choice.
>>
>> - Make sure your JMS provider has a meaningful setup for exhaustion of
>> failed JMS messages otherwise you get the "poission message effect". For
>> example Apache ActiveMQ exhausts after 6 retries after which it puts the
>> unconsumed message into DLQ.
>>
>> - Don't use spring version 3.1 but the one Camel 2.9 relies on (3.0.7).
>> if
>> you make use of Maven for your build then you will get that dependency
>> transitively for free if you would depend on camel-spring. Using "mvn
>> dependency:tree" would show you already now that you've got a dependency
>> conflict by your POM.
>>
>> Babak
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487888.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
--
View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489165.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Correct situation to use XA
Posted by surya aditya <su...@gmail.com>.
Babak,
Thanks for such informative reply. Would like to add there is one full
chapter dedicated for handling transactions with camel in 'Camel in Action'
book by Claus, et al.
peace,
On Wed, Feb 15, 2012 at 6:54 PM, Babak Vahdat
<ba...@swissonline.ch>wrote:
> Hi
>
> Given your use case using XA you're definetly on the right way! What you
> need is a *global* transaction and not a *local* one as you need the
> orchestration of the transaction boundries along the way through JMS
> together with your DB.
>
> If you would make use of local transaction managers, let's say spring
> JmsTransactionManager and DatasourceTransactionManager then you would
> already commit your jms message consumption through camel-jms before
> inserting the data into the DB. But then if you would violate some
> DB-Constraints while inserting the data then the message has been already
> consumed from the JMS point of view (alread commited). Making use of XA in
> this case has the advantage of not lossing any unsuccessfully processed
> message. So using XA you have a real "unit-of-work" while dealing with more
> than one single "resource". Following some notes:
>
> - You don't have to pop the message back on the queue for later consumption
> by yourself (as you said), as that's already given for free through the
> transaction (rollback of JMS message consumption).
>
> - If you run your App inside a JEE container then rely on its XA-TM, for
> example JBoss makes use of Arjuna. And then let Spring
> JtaTransactionManager
> talk to it. But if you run standalone then atomikos is a good choice.
>
> - Make sure your JMS provider has a meaningful setup for exhaustion of
> failed JMS messages otherwise you get the "poission message effect". For
> example Apache ActiveMQ exhausts after 6 retries after which it puts the
> unconsumed message into DLQ.
>
> - Don't use spring version 3.1 but the one Camel 2.9 relies on (3.0.7). if
> you make use of Maven for your build then you will get that dependency
> transitively for free if you would depend on camel-spring. Using "mvn
> dependency:tree" would show you already now that you've got a dependency
> conflict by your POM.
>
> Babak
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487888.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Correct situation to use XA
Posted by Babak Vahdat <ba...@swissonline.ch>.
Hi
Given your use case using XA you're definetly on the right way! What you
need is a *global* transaction and not a *local* one as you need the
orchestration of the transaction boundries along the way through JMS
together with your DB.
If you would make use of local transaction managers, let's say spring
JmsTransactionManager and DatasourceTransactionManager then you would
already commit your jms message consumption through camel-jms before
inserting the data into the DB. But then if you would violate some
DB-Constraints while inserting the data then the message has been already
consumed from the JMS point of view (alread commited). Making use of XA in
this case has the advantage of not lossing any unsuccessfully processed
message. So using XA you have a real "unit-of-work" while dealing with more
than one single "resource". Following some notes:
- You don't have to pop the message back on the queue for later consumption
by yourself (as you said), as that's already given for free through the
transaction (rollback of JMS message consumption).
- If you run your App inside a JEE container then rely on its XA-TM, for
example JBoss makes use of Arjuna. And then let Spring JtaTransactionManager
talk to it. But if you run standalone then atomikos is a good choice.
- Make sure your JMS provider has a meaningful setup for exhaustion of
failed JMS messages otherwise you get the "poission message effect". For
example Apache ActiveMQ exhausts after 6 retries after which it puts the
unconsumed message into DLQ.
- Don't use spring version 3.1 but the one Camel 2.9 relies on (3.0.7). if
you make use of Maven for your build then you will get that dependency
transitively for free if you would depend on camel-spring. Using "mvn
dependency:tree" would show you already now that you've got a dependency
conflict by your POM.
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487888.html
Sent from the Camel - Users mailing list archive at Nabble.com.