JTA versus JDBC Transactions

Starting from Hibernate 3 the implementation of the session factory has changed. The creation of a session factory is much easier and the factories you will find through out this book are quite different from the ones you can find in older examples.

Concerning the transaction handling, there are different options for session factories.

One option is to use the transaction management of your application server. Every JEE application server provides the Java Transaction API (JTA), for example Orion, Jonas, Bea Weblogic, Websphere, Jboss. JTA transactions are more flexible as JDBC transaction handling. You can enlist other transactional resources into the same transaction or run a transaction across multiple databases. This requires that the transactional resources supports two-phase-commit transactions.

A pure Servlet application server like Tomcat, Jetty does not include a JTA transaction manager. You may plug in a JTA solution (e.g. http://jotm.objectweb.org/ or JTA of Jboss) or use the other option JDBC transactions.

JDBC transactions can be used in servlet engines or in all other kind of Java applications. Christian Bauer and Gavin King argue in Java Persistence in Action that JTA transactions provide a higher quality transaction management. I do not agree with this opinion. JTA sooner or later has to call a JDBC transaction, this is why it cannot have a higher quality. If you run a application against a single database and don’t need distributed transactions or transaction monitoring – which might be provided by a JEE application server as well – then it is fine to use JDBC transactions.