Hibernate not releasing data base connections

Following is the configuration details:

<property name="hibernateProperties">
   <props>
    <prop key="hibernate.dialect">
     org.hibernate.dialect.Oracle9iDialect
    </prop>
    <prop key="hibernate.show_sql">false</prop>
    <prop key="hibernate.cache.provider_class">
     org.hibernate.cache.OSCacheProvider
    </prop>
    <prop key="hibernate.cache.use_second_level_cache">
     true
    </prop>
    <!-- <prop key="hibernate.hbm2ddl.auto">update</prop>-->
    <!-- HIBERNATE CONNECTION POOLING!!-->
    <prop key="c3开发者_JAVA技巧p0.acquire_increment">5</prop>
    <prop key="c3p0.idle_test_period">100</prop>
    <!-- seconds -->    
    <prop key="c3p0.max_statements">5</prop>
    <prop key="c3p0.min_size">15</prop>
                            <prop key="c3p0.max_size">100</prop> 
    <prop key="c3p0.timeout">100</prop>
    <!-- seconds -->
   </props>
  </property>

Our application is developed through Spring & Hibernate.

Once we bring the application up and hit it, its opening 140 connections and not releasing it.

Our DAO looks like this:

import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
...
public class ActionDAO extends HibernateDaoSupport implements IActionDAO {
 public Action findById(ActionPK actionPK) {
  return (Action) getHibernateTemplate().get(Action.class, actionPK);
 }

 public void add(Action action) {
  getHibernateTemplate().save(action);
 }
}

We had a similar issue some time ago, and the root cause was that the Hibernate session factory was not closed before the app terminated. Although I understand that you are using Spring, which is supposed to take care of this automagically, still it might be worth checking.

Are your sessions part of a transaction? If they are, then the session/connection closing may only happen when the transaction ends, and if that's not happening, you'll get leaked connections.

Enabling debug logging on org.hibernate.jdbc and org.hibernate.transaction may help... also look at the HibernateTemplate class (which HibernateDaoSupport uses) and see the options for how session creation/closing is configured. You may just want to wrap your DAO objects inside a Spring transaction wrapper or something similar.

I don't think your c3p0 settings are being hit, seeing as you have > 100 db connections. That being said you should set your idle_test_period to a value less than c3p0 timeout.

In addition, which version of hibernate matters in determining why c3p0 is not being used.

You also mentioned spring; you need to see what you're doing with regard to transactions. Do you have some sort of service or something that is or in your case, is not wrapping your DAO use in a transaction?

If u are using spring autowiring and hibernateTemplate

please make sure that you are not creating more than one instance of HibernateTemplate, ie

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("META-INF/spring/applicationContext.xml");
Object o=context.getBean("hibernateTemplate");

The object o has to be cached somewhere and returned when your app code is asking for instance of hibernatetemplate.

Thanks

Delete the min size and try: c3p0.min_size

I had a similar issue in Jboss-hibernate. We had the impression that while performing a read operation under a transactional session, there was no need to commit the transaction. However we realized that the transaction must be commited although it is only a read opeartion (if you have begun a transaction). Once we commited the transaction everywhere, the leakage was gone.

Buggy code was like this:

1. Begin transaction
2. Execute read operation
3. Close the session

The above was replaced with the following procedure and the leakage was gone.

1. Begining transaction
2. Perform read operation
3. Commit the transaction
4. Close the session