use JTA transaction or not?

Question

I am developing a J2EE application which is deployed on JBoss application server. The application is composed of an EJB 2.x component and a web component and is running on local computer or remote server. The database is either Oracle or SQL Server and is not in a distributed envrionment.

I am using Hibernate 3.6 (JPA 2.0 implementation) for the transactions. Should I use JTA which is container managed transaction or is it overkilled to use it?

Currently I am using JTA and it turns out it is running fine but with some small issues which I do not know whether it is related to the transaction management or not. Will it be easier or more reliable to use local transaction management?

Lattimore

possible duplicate of JTA or LOCAL transactions in JPA2+Hibernate 3.6.0? – Iridic

Thank you for your comment. So what transaction manager should I use if I use both EJB 2.x and JPA? For the Spring-Roo application the default is org.springframework.orm.jpa.JpaTransactionManager but I guess I should be using something else. – Lattimore

Answer 1

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

Racing

Thank you arjan. I am currently at a migration stage of my project so I need both of EJB 2 and JPA 2 running well to be able to test the changes do not affect the behaviour my project used to have. At the end of the day my project will be migrated to JPA 2 completely. – Lattimore

You're welcome. Note that the most powerful combinations is EJB 3.1 + JPA 2. Those two complement each other greatly. – Racing

Answer 2

I would recommend to use XA transaction, even if the application currently accesses only one resource (the database). Resons:

1) In future, if the application decides to include some other transactional resource apart from the current database, it will find it easier as the XA transaction management is already in place and the multiple transactional resources can then be combined into a single transaction.

2) As you have a single transactional resource currently, I don't think performance would suffer with use of XA compared to local transaction. The reason is that XA/JTA transaction managers already do some kind of optimization for cases of single transactional resource (they call it one-phase optimization).

Hope that helps.

Nitin

Cheer

YAGNI, one should never build things based on speculative requirements. If there is a clear need for XA then use it. Don't do it because you might need it. – Fourposter