JTA or LOCAL transactions in JPA2+Hibernate 3.6.0?

Question

We are in the process of re-thinking our tech stack and below are our choices (We can't live without Spring and Hibernate due to the complexity etc of the app). We are also moving from J2EE 1.4 to Java EE 5.

Technology stack

1. Java EE 5
2. JPA 2.0 (I know Java EE 5 only supports JPA 1.0 but we want to use Hibernate as the JPA provider)
3. Hibernate 3.6.0 (We already have lots of hbm files with custom types etc. so we doesn't want to migrate them at this time to JPA. This means we want both jpa/hbm mappings work together and hence the Hibernate as the JPA provider instead of using the default that comes with App Server)

Now the problems is that I want to stick with local transactions but other team members want to use JTA. I have been working with J2EE for last 9 years and I've heard time and again people suggesting to stick with local transactions if I doesn't need two phase commits. This is not only for performance reasons but debugging/troubleshooting a local transaction is lot easier than a JTA (even if JTA only does single phase commit when required).

My suggestion is to use spring declarative transaction management + local transactions (HibernateTransactionManager) instead of container JTA

I want to make sure if I am being paranoid or I have a valid point. I'd like to hear what the rest of the Java EE world thinks. Or please point me an appropriate article.

Answer 1

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 ;)