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.

Weedy

Answer 1

JTA doesn't mean two phase commits. I think it's the combination of JTA and XA drivers that makes two phase commits possible.

I'd still recommend using JTA and declarative transactions over embedding transaction logic in code. Transactions are best done in aspect oriented fashion, a la Spring.

UPDATE:

With the additional information you've posted, I agree with your argument. I'd recommend using Spring declarative transactions and the HibernateTransactionManager class.

Scenario

Right. Idea use to use spring for transactions. I understand JTA doesn't really mean 2-phase but my point is if we already know we doesn't want 2 phase then why to go for JTA? – Weedy

My suggestion is to use spring declarative transaction management+local transactions – Weedy

If I use local transactions then I no need to define "org.springframework.transaction.jta.JtaTransactionManager" bean in spring. I just define "HibernateTransactionManager" or "JpaTransactionManager" – Weedy

thanx. Its getting harder for me to convince them on my approach. They are saying that the two points I brought up (performance and difficult to debug) are too abstract and I doesn't have enough data to prove that. Can you think of any other dis-advantages of using JTA or advantage of using local trans with spring declarative trans. They are also suggesting to use EJB 3 and CMT. – Weedy

I'd ask to see their data to prove their point. I'd bet that neither of you have any data either way. They're arguing for EJB3 and CMT and criticizing Spring with a straight face? Please. It comes down to Spring or EJB 3.1 preference. The good news for you is that either one will work. My preference would be Spring, of course. You can defer your choices by writing everything in terms of interfaces. You can switch implementations without affecting clients. – Scenario

We are using EJB 3.0 and NOT EJB 3.1 because we are in JEE 5 container. So we have the weired combination of hibernate+EJB 3.0+JPA 2 (JEE 6 thing but we use it in JEE 5 container) – Weedy

Answer 2

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

Issiah

You wrote : "The datasource representing your DB may not be XA, but in an XA transaction 1 resource is allowed to be non-XA." Why is non-XA allowed in this case ? Indeed, couldn't it lean to an uncohesive behavior regarding the globality of results after transaction commits ? For example, if this non-XA resource is not able to support 2-phases-commit, how can we ensure that global transaction (targeting multiple datasources) has well happened ? – Gowen

@Gowen see my notion of the last resource commit optimization. If it's the turn of the last resource to commit, you know one specific thing that you didn't know earlier: all other resources are able to commit. So it only depends on this last resource whether the full TX can commit or not, and that's simple. If it indeeds commit, the whole TX is committed (meaning the others, that already said they could commit), if it doesn't commit (e.g. throws), then the others are rollbacked. – Issiah

I didn't know the concept of "last resource commit". Now I understand the rule "at most one Non-XA datasource allowed and no more" Thanks :) – Gowen