If you want JTA support in Tomcat you'll need to use a standalone transaction manager like Atomikos, JOTM, Bitronix, SimpleJTA, JBossTS or GeronimoTM/Jencks. But honestly, if you're not going to handle transactions across multiple resources, then you can live without JTA (and if you really need JTA, use a full blown application server).
As Duffy already mentioned, JTA is not synonymous with 2 phase commit, which is something done via the XA protocol.
In JBoss AS for example, you can explicitly choose whether you want a given data source to be an xa-datasource or a tx-datasource. In both cases, transactions are managed via JTA.
In some cases you might already have been using JTA without knowing it. If you send a JMS message transactionally, or update a transactional cache in the same transaction where you modify something in a database, the transaction manager automatically switches to XA mode. The datasource representing your DB may not be XA, but in an XA transaction 1 resource is allowed to be non-XA. Updates to this resource then happens via the last resource commit optimization
.
Although you should always calculate the risks and test for your self, I do want to warn against unfounded fear. XA seems to be one of those things we as developers have been brought up to fear. There was an interesting discussion on the JBoss forum about this recently: when to use xa-datasource.
The thing is that XA might have been a complex technology with sub-par implementations in the past, but almost a decade and a half since this FUD this might not be the case anymore. What was complex big enterprise stuff in 1995 is your common run of the mill technology in 2011.
Compare this with the fear we were once brought up with for EJB, which is now completely irrelevant anymore, or the fear for virtual machines (obviously not a problem for Java programmers), or when you're really participating in this industry for a long time, the fear for doing something as basic as function calls ;)
Best Answer
JTA transactions are always recommended above other kinds of transaction APIs, especially if you are referring to the native transactions that are still part of the JPA API. Note that you can't say 'JTA vs resource local transactions', as JTA actually manages resource local transactions among others.
Gavin King (creator of Hibernate) once indicated in an interview that this JPA specific API was a mistake and that the much more flexible JTA API should be preferred. Especially when using declarative transactions, JTA is very lightweight. The word
overkill
would actually apply more to using the JPA native transaction API, then to using JTA.There is something to say about the choice between using XA or resource local transactions with JTA. See my answer here for some more details about that: JTA or LOCAL transactions in JPA2+Hibernate 3.6.0?
I do wonder why you are using EJB 2 in combination with JPA 2.0. EJB 3.1 would be a much more logical choice here. EJB 2 is completely deprecated (will be pruned in Java EE 7).