What is the best choice for database connection pooling library? (c3p0 problem)

Question

I have heavy loaded java application using hirbernate. And I used to use as connection pool DBCP, but it had problems with connections lossing. Than I switched to c3p0. But now it sometimes bloks thread and I dont know why. Like here:

"1343694829@qtp-515693101-1941" prio=10 tid=0x00007fa6b0940000 nid=0x4e12 runnable [0x00007fa6f8f1c000]
   java.lang.Thread.State: RUNNABLE
    at com.mchange.v2.resourcepool.BasicResourcePool.doCheckinManaged(BasicResourcePool.java:1258)
    at com.mchange.v2.resourcepool.BasicResourcePool.checkinResource(BasicResourcePool.java:647)
    - locked <0x00007fa7286d9728> (a com.mchange.v2.resourcepool.BasicResourcePool)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$ConnectionEventListenerImpl.doCheckinResource(C3P0PooledConnectionPool.java:636)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$ConnectionEventListenerImpl.connectionClosed(C3P0PooledConnectionPool.java:630)
    at com.mchange.v2.c3p0.util.ConnectionEventSupport.fireConnectionClosed(ConnectionEventSupport.java:55)
    at com.mchange.v2.c3p0.impl.NewPooledConnection.fireConnectionClosed(NewPooledConnection.java:510)
    at com.mchange.v2.c3p0.impl.NewPooledConnection.markClosedProxyConnection(NewPooledConnection.java:381)
    at com.mchange.v2.c3p0.impl.NewProxyConnection.close(NewProxyConnection.java:1246)
    - locked <0x00007fa794ccf020> (a com.mchange.v2.c3p0.impl.NewProxyConnection)
    at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.closeConnection(LocalDataSourceConnectionProvider.java:96)
    at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:474)
    at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:408)
    at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:347)
    at org.hibernate.impl.SessionImpl.close(SessionImpl.java:325)
    at org.springframework.orm.hibernate3.SessionFactoryUtils.closeSession(SessionFactoryUtils.java:791)
    at org.springframework.orm.hibernate3.SessionFactoryUtils.closeSessionOrRegisterDeferredClose(SessionFactoryUtils.java:777)
    at org.springframework.orm.hibernate3.SessionFactoryUtils.releaseSession(SessionFactoryUtils.java:755)

' My stacktrace dump showed that this thread blocked all my other threads, with lock <0x00007fa7286d9728>, so in a while server was completly blocked. I am not sure how long does this thread run, if one thread was blocking all other threads for long time, or if just time consumed by this thread was extremly long, but result was, that my system was completly blocked and extremly slowed. I googled a lot, but I don't know how to solve this problem. I need pool to close connection and finish tread as soon as possible. Should I use some other connection pool? For me it is absolutly necessary that this pool library is 100% save, no deadlocks, lifelocks, starvations, even that it is little bit slower than other libraries.

thanks for any help

Answer 1

You may wish to have a look at BoneCP - http://jolbox.com.

Much better performance than C3P0/DBCP and no reports of any deadlocks so far.

Answer 2

1)What do you mean when say about connection losing in DBCP? Do you use MySQL? I know problem with connection losing with working with MySQL if no activity were during some time. Is it your case?

2)Using Hibernate in high-loaded app isn't very good choice. Hibernate is too bulk and slow especially on complex data and relations (for example it need transaction on every session even we just want to retrieve data)

3)May be reason is too much needed threads and not enough threads in the pool?

I participated in high-loaded project. We use Hibernate for soft data (plenty of requests consisted of several records that had not very complex mapping) and self-written wrapper over JDBC for heavy data (not very much requests of thousands records via SP with hard manual mapping). And we didn't have any problems with DBCP except losing connection to MySQL databases after long inactivity time.