when to use global transaction Or use spring aop for transaction

Q1. i do understand when we need to deal with multiple databases, we need to use global transaction. but from this post http://fogbugz.atomikos.com/default.asp . the person suggested just use spring aop to advise on the different transactionmanager ( more > datasource/sessionfactory). can anyone explain in what kind of开发者_Python百科 situation we can just use this approach And In what kind of situation do we need XA (global transaction) with atomikos or jotm or ejb..etc

I think Pascal has answered your question thoroughly, but I want to try and simplify / summarize it.

• If you need to perform paralel, independent tasks on datasources without a transactional scope requirement (e.g. if when a transaction fails in one datasource, it doens't have to rollback in others), use Pascal's suggestion or the approach in http://fogbugz.atomikos.com/default.asp?community.6.596.2 (e.g. non JTA / non XA / non distributed)

• If you need a transaction scope accross different datasources, e.g. if a rollback in in one datasource should rollback the changes in another datasource underthe same logical transaction scope, (e.g. bank database and credit card database doing transfer of funds, you can't get a decreese / increese in one without a respective increese / decreese in the other) you need a JTA transaction manager (XA / distributed)

Hope this makes the picture clearer (I'm open for comments if I over simplified it or simply wrong)

If you are referring to this message http://fogbugz.atomikos.com/default.asp?community.6.596.2, then the important part in the question from the OP is:

The task can either be a set of sql commands against datasource1 or datasource2.

In other words, the OP won't enlist multiple transactional resources, he will use one or the other (and explicitly writes that he doesn't really need XA-support). So, he doesn't really need global transactions support, he could use local transactions only and using a J2EE transaction manager is not mandatory for his use case.

And this is what the answer is suggesting: using Atomikos is not a necessary and might be overkill.

Using two dataSource, two txManager, two txAdvice and defining distinct <aop:advisor/> elements with differing 'pointcut' and 'advice-ref' attribute values would allow to apply totally different transactional configuration to different service layer objects/methods.

See section 9.5.4. Configuring different transactional semantics for different beans for the details.

But if you need to work with multiple transactional resources (typically relational databases and message queues), then you need global transactions support which means a J2EE transaction manager (provided by a J2EE application server or standalone like Atomikos, JBossTS, JOTM, etc).