3.8. J2EE Application Server integration

Hibernate has the following integration points for J2EE infrastructure:
  • Container-managed datasources: Hibernate can use JDBC connections managed by the container and provided through JNDI. Usually, a JTA compatible TransactionManager and a ResourceManager take care of transaction management (CMT), especially distributed transaction handling across several datasources. You can also demarcate transaction boundaries programmatically (BMT), or you might want to use the optional Hibernate Transaction API for this to keep your code portable.
  • Automatic JNDI binding: Hibernate can bind its SessionFactory to JNDI after start up.
  • JTA Session binding: the Hibernate Session can be automatically bound to the scope of JTA transactions. Simply lookup the SessionFactory from JNDI and get the current Session. Let Hibernate manage flushing and closing the Session when your JTA transaction completes. Transaction demarcation is either declarative (CMT) or programmatic (BMT/UserTransaction).
  • JMX deployment: if you have a JMX capable application server (e.g. JBoss Enterprise Application Platform ), you can choose to deploy Hibernate as a managed MBean. This saves you the one line start up code to build your SessionFactory from a Configuration. The container will start up your HibernateService and also take care of service dependencies (datasource has to be available before Hibernate starts, etc).
Depending on your environment, you might have to set the configuration option hibernate.connection.aggressive_release to true if your application server shows "connection containment" exceptions.

3.8.1. Transaction strategy configuration

The Hibernate Session API is independent of any transaction demarcation system in your architecture. If you let Hibernate use JDBC directly through a connection pool, you can begin and end your transactions by calling the JDBC API. If you run in a J2EE application server, you might want to use bean-managed transactions and call the JTA API and UserTransaction when needed.
To keep your code portable between these two (and other) environments we recommend the optional Hibernate Transaction API, which wraps and hides the underlying system. You have to specify a factory class for Transaction instances by setting the Hibernate configuration property hibernate.transaction.factory_class.
There are three standard, or built-in, choices:
delegates to database (JDBC) transactions (default)
delegates to container-managed transactions if an existing transaction is underway in this context (for example, EJB session bean method). Otherwise, a new transaction is started and bean-managed transactions are used.
delegates to container-managed JTA transactions
You can also define your own transaction strategies (for a CORBA transaction service, for example).
Some features in Hibernate (i.e., the second level cache, Contextual Sessions with JTA, etc.) require access to the JTA TransactionManager in a managed environment. In an application server, since J2EE does not standardize a single mechanism, you have to specify how Hibernate should obtain a reference to the TransactionManager:

Table 3.10. JTA TransactionManagers

Transaction Factory Application Server
org.hibernate.transaction. JBossTransactionManagerLookup JBoss
org.hibernate.transaction. WeblogicTransactionManagerLookup Weblogic
org.hibernate.transaction. WebSphereTransactionManagerLookup WebSphere
org.hibernate.transaction. WebSphereExtendedJTATransactionLookup WebSphere 6
org.hibernate.transaction. OrionTransactionManagerLookup Orion
org.hibernate.transaction. ResinTransactionManagerLookup Resin
org.hibernate.transaction. JOTMTransactionManagerLookup JOTM
org.hibernate.transaction. JOnASTransactionManagerLookup JOnAS
org.hibernate.transaction. JRun4TransactionManagerLookup JRun4
org.hibernate.transaction. BESTransactionManagerLookup Borland ES