JDBC Connection Pools
I heard recently that BoneCP is the connection pool that developers will use in the future. I started to check why this connection pool is so popular. Well, they say that they have very good benchmark results. The first thing I asked: Does BoneCP have a JTA-aware pool as well? I found an answer at StackOverFlow:
If timelines permit and there’s this requirement, I can add JTA support to BoneCP if you want.
Wallace (BoneCP author)
Cool, there is a hope. However, I found another answer written by Wallace at a BoneCP forum thread:
1. The pool does not deal with transactions at all, that’s not the job of the *connection* pool. It’s only job is to give you a connection when you ask for it.
It seems that Wallace has changed his mind. I disagree with him. It is not the job of an object pool to be transaction-aware but if we talk about connection pooling, transaction handling must be implemented. In my opinion, a transaction-aware connection pool must handle connections in the following way:
- If there is a live transaction, newly provided connections should be enlisted
- Connections should be enlisted, until the transaction ends
- If a connection is enlisted, the connection should not be provided to another client that does not participate in the same transaction
- If a client needs a new connection, available connections already enlisted within the same transaction should be preferred
- The pool should wrap the provided PreparedStatement objects and keep them opened, until the connection is physically closed
There might be other rules. Based on the ones I collected, I do not think there is a way to separate connection pooling logic from transaction enlisting.
I know about two vendor-independent connection pools that support JTA: commons-dbcp and XaPool. It seems that the second is not under development anymore.
In our projects, we use commons-dbcp. It has several annoying bugs, so we had to deploy a patched version into our maven repository. These patches are available in the Jira of commons-dbcp. However, I got really sad as I saw that nobody took care of the issues since years, although there were useful contributions. I started to search in the mailing lists to find out if the project is dead.
Version 2 of Apache Commons Pool contains a completely re-written pooling implementation compared to the 1.x series. In addition to significant performance and scalability improvements – particularly under highly concurrent loads
There is no hard schedule. My guess, at least one issue is being addressed for [pool] 2.0.1 maintenance release, after that attention should shift to [dbcp].
- Use vendor dependent connection pool
- Use connection pool provided by the TM (e.g. bitronix has a connection pool)
- Use a patched version of commons-dbcp with JTA
- Use XAPool (it seems, that the project is dead)
- Use BoneCP, C3P0, … without JTA
- Use BoneCP, C3P0, … with JTA and allow 10 times more database connections than threads (as each getConnection() will hold a connection until the transaction ends)
It is funny, that in 2013 we cannot choose a JTA aware, vendor-independent, effective connection pool that “just works”. However, there is a hope, that commons-dbcp 2.0 will do the job.