forhas forhas - 3 months ago 104x
Java Question

When are connections returned to the connection pool with Spring JPA (Hibernate) Entity Manager?

In my java process I'm connecting to MySql using the following spring configuration:

@PropertySources({ @PropertySource("classpath:/"), @PropertySource("classpath:/") })
public class MyConfiguration {

protected Environment env;

* @return EntityManagerFactory for use with Hibernate JPA provider
@Bean(destroyMethod = "destroy")
public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
LocalContainerEntityManagerFactoryBean em = new LocalContainerEntityManagerFactoryBean();

return em;

* @return jpaVendorAdapter that works in conjunction with the
* persistence.xml
public JpaVendorAdapter jpaVendorAdapter() {
HibernateJpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter();
vendorAdapter.setGenerateDdl(env.getProperty("jpa.generateDdl", Boolean.class, false));
vendorAdapter.setShowSql(env.getProperty("jpa.showSql", Boolean.class, false));

return vendorAdapter;

public PersistenceUnitManager persistenceUnitManager() {
DefaultPersistenceUnitManager pum = new DefaultPersistenceUnitManager();

return pum;

@Bean(destroyMethod = "close")
public DataSource dataSource() {
Properties dsProps = new Properties();
dsProps.put("driverClassName", env.getProperty("hikari.driverClassName"));
dsProps.put("username", env.getProperty("hikari.username"));
dsProps.put("password", env.getProperty("hikari.password"));
dsProps.put("jdbcUrl", env.getProperty(""));
dsProps.put("connectionTimeout", env.getProperty("hikari.connectionTimeout", Integer.class));
dsProps.put("idleTimeout", env.getProperty("hikari.idleTimeout", Integer.class));
dsProps.put("maxLifetime", env.getProperty("hikari.maxLifetime", Integer.class));
dsProps.put("maximumPoolSize", env.getProperty("hikari.maximumPoolSize.rtb.source", Integer.class));
dsProps.put("leakDetectionThreshold", env.getProperty("hikari.leakDetectionThreshold", Integer.class));
dsProps.put("jdbc4ConnectionTest", env.getProperty("hikari.jdbc4ConnectionTest", Boolean.class));

HikariConfig config = new HikariConfig(dsProps);
HikariDataSource ds = new HikariDataSource(config);

return ds;

@Bean(name = "sourceTxMgr")
public PlatformTransactionManager sourceDatatransactionManager() {
JpaTransactionManager transactionManager = new JpaTransactionManager();

return transactionManager;

public PersistencyManager persistencyManager() {
return new JpaPersistencyManager();

public PersistenceExceptionTranslationPostProcessor exceptionTranslation() {
return new PersistenceExceptionTranslationPostProcessor();


The Entity-Manager is injected to the data access layer by the container:

@PersistenceContext(type = PersistenceContextType.TRANSACTION, unitName = "my-pu")
private EntityManager myEntityManager;

And my public business logic methods are annotated with the

As far as I understand the container is responsible for ensuring that the entity-manager returns connections to the pool (in my case HikariCP) once a transaction is done but I did not find any official documentation that describes how the connections are managed. Can anyone explain it to me or provide a good reference that can explain when exactly connections are returned to the pool when using such a configuration?


The best related info I could come up with so far (taken from here):

The persistence context proxy that implements EntityManager is not the only component needed for making declarative transaction management work. Actually three separate components are needed:

The EntityManager Proxy itself
The Transactional Aspect
The Transaction Manager
Let's go over each one and see how they interact.

The Transactional Aspect

The Transactional Aspect is an 'around' aspect that gets called both before and after the annotated business method. The concrete class for implementing the aspect is TransactionInterceptor.

The Transactional Aspect has two main responsibilities:

At the 'before' moment, the aspect provides a hook point for determining if the business method about to be called should run in the scope of an ongoing database transaction, or if a new separate transaction should be started.

At the 'after' moment, the aspect needs to decide if the transaction should be committed, rolled back or left running.

At the 'before' moment the Transactional Aspect itself does not contain any decision logic, the decision to start a new transaction if needed is delegated to the Transaction Manager.

The Transaction Manager

The transaction manager needs to provide an answer to two questions:

should a new Entity Manager be created?
should a new database transaction be started?
This needs to be decided at the moment the Transactional Aspect 'before' logic is called. The transaction manager will decide based on:

the fact that one transaction is already ongoing or not
the propagation attribute of the transactional method (for example REQUIRES_NEW always starts a new transaction)
If the transaction manager decides to create a new transaction, then it will:

create a new entity manager
bind the entity manager to the current thread
grab a connection from the DB connection pool
bind the connection to the current thread
The entity manager and the connection are both bound to the current thread using ThreadLocal variables.

They are stored in the thread while the transaction is running, and it's up to the Transaction Manager to clean them up when no longer needed.

Any parts of the program that need the current entity manager or connection can retrieve them from the thread. One program component that does exactly that is the EntityManager proxy.


It's not complicated at all.

  1. First you need to understand that Spring transaction manager is only a transaction management abstraction. In your case the actual transactions happen at JDBC Connection level.

  2. All @Transactional service method calls are intercepted by the TransactionInterceptor Aspect.

  3. The TransactionIntreceptor delegates transaction management to the current configured AbstractPlatformTransactionManager implementation (JpaTransactionManager in your case).

  4. JpaTransactionManager will bind the current running Spring transaction to an EntityManager, so all DAOs participating in the current transaction share the same Persistence Context.

  5. JpaTransactionManager simply uses EntityManager Transaction API for controlling transactions:

    EntityTransaction tx = txObject.getEntityManagerHolder().getEntityManager().getTransaction();

    The JPA Transaction API simply delegates the call to the underlying JDBC Connection commit/rollback methods.

  6. When the transaction is done (commit/rollback), the org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction calls:


    which triggers a Hibernate Session (Entity Manager) close.

  7. The underlying JDBC connection is therefore triggered to be closed as well:

  8. Hibernate has a logical JDBC connection handle:

    public Connection close() {
        LOG.tracev( "Closing JDBC container [{0}]", this );
        if ( currentBatch != null ) {
        return logicalConnection.close();
  9. The logical connection handle delegates the close call to the currently configured connection provider (DataSourceConnectionProvider in your case), which simply calls the close method on the JDBC connection:

    public void closeConnection(Connection connection) throws SQLException {
  10. Like any other connection pooling DataSource, the JDBC connection close simply returns the connection to the pool and doesn't close the physical database connection. That's because the connection pooling DataSource returns a JDBC Connection proxy that intercepts all calls and delegates the closing to the connection pool handling logic.