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.

I saw that commons-pool 2.0 has just been released. The interesting part of the announcement is the following:
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
I would be interested in the benchmarks. As Commons-dbcp uses commons-pool for pooling, when we talk about the performance of commons-dbcp, we talk about the performance of commons-pool. With the new release, commons-dbcp might get the chance to have similar benchmark results as other connection pools have, with the advantage of JTA support. I wrote to the apache-commons mailing list and it seems that my guesses were right. Gary Gregory answered the following:
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].
At this time, the developers can choose from the following options (as much as I know):
  • 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.



About Balázs Zsoldos

Balazs Zsoldos is the co-founder of Everit. He is the leader of the development of Everit OpenSource Components. Developing Java based solutions is not only his job but also his passion. He believes in simplicity. That is why he decided to design and build as many simple, but useful goal-oriented modules as he can. As the base of the stack, he chose OSGi. Balazs does not believe in monoholitic frameworks, therefore all of the solutions that was designed by him can be used separately. In the beginning of his career, Balazs was a big fan of JEE and Spring. After a while, he changed his mind and started to try replacing everything with non-magical solutions that do not contain interceptors, weaving, etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: