JDBC Connection Pools, does the world need another?
Thursday, 2. July 2009, 22:24:28
Over the past year or so, I have on occasion been working on a project called NanoPool. It is a JDBC 2 connection pool that exposes itself as a DataSource and is released under the Apache 2 license.
I started writing it after having read Java Concurrency in Practice, because I wanted to experiment with implement something that was both simple, concurrent and lock-free.
This experiment ended up being a JDBC connection pool implementation that is really fast at connection reuse. It is lock-free so internal dead-locks are impossible. It supports hot resizing so you can adjust the pool-size during peak-hours. It has hooks for high contention callbacks so you can be notified if your pool is too small. It has no internal threads so life-cycle management is simpler (and no thread-leaks). It has a feature-full JMX interface so management is theoretically a breeze.
With all these nice things comes a number of caveats. For instance, NanoPool will, per its design, saturate the pool and try to keep all connections open at all times. Most other pools have a maximum and minimum size that bounds how many connections will be kept open at any given time. NanoPool does not do this; it has just a pool size.
Another caveat comes by virtue of not having any internal threads. This means that the only threads that can do pool maintenance work, such as reestablishing aging connections, are the client threads that call into the pool to either claim or release connections. This may be a problem if you worry a lot about latency and standard deviation in response times. That said, I have not really checked if other pools do any better in this respect, so test & check it yourself if this is a concern.
Anyway, the question that is really on my mind is this: NanoPool is almost at 1.0 state, but does it make sense to complete it and ship it? I mean, is it really add something of value and not just noise? I think that people are extremely conservative when picking connection pools so it may be a wasted effort. On the other hand, if I go through and release it then I take on the responsibility of support and maintenance nearly regardless of the user base (although I think there will be less of this work for NanoPool than what I ended up with for Fabric).
In other words: does the world need another connection pool?
I started writing it after having read Java Concurrency in Practice, because I wanted to experiment with implement something that was both simple, concurrent and lock-free.
This experiment ended up being a JDBC connection pool implementation that is really fast at connection reuse. It is lock-free so internal dead-locks are impossible. It supports hot resizing so you can adjust the pool-size during peak-hours. It has hooks for high contention callbacks so you can be notified if your pool is too small. It has no internal threads so life-cycle management is simpler (and no thread-leaks). It has a feature-full JMX interface so management is theoretically a breeze.
With all these nice things comes a number of caveats. For instance, NanoPool will, per its design, saturate the pool and try to keep all connections open at all times. Most other pools have a maximum and minimum size that bounds how many connections will be kept open at any given time. NanoPool does not do this; it has just a pool size.
Another caveat comes by virtue of not having any internal threads. This means that the only threads that can do pool maintenance work, such as reestablishing aging connections, are the client threads that call into the pool to either claim or release connections. This may be a problem if you worry a lot about latency and standard deviation in response times. That said, I have not really checked if other pools do any better in this respect, so test & check it yourself if this is a concern.
Anyway, the question that is really on my mind is this: NanoPool is almost at 1.0 state, but does it make sense to complete it and ship it? I mean, is it really add something of value and not just noise? I think that people are extremely conservative when picking connection pools so it may be a wasted effort. On the other hand, if I go through and release it then I take on the responsibility of support and maintenance nearly regardless of the user base (although I think there will be less of this work for NanoPool than what I ended up with for Fabric).
In other words: does the world need another connection pool?
WIDGETIZE
Anonymous # 2. July 2009, 23:27
It might be more crowded than you think. I have it on good authority that SpringSource will be open sourcing the high concurrency data source currently shipping with tcServer and it may also be packaged with Tomcat 7.
karmazilla # 3. July 2009, 23:08
Anonymous # 19. August 2009, 09:59
I definitely needed this connection pool. I have been using MiniConnectionPoolManager before, and when benchmarking my application, noted that most time is wasted by this Connection pool, especially getting the connections. After switching to NanoPool, I have experienced quite a performance boost. So please keep on developing and releasing it.
karmazilla # 20. August 2009, 08:52
Originally posted by anonymous:
That's interesting. Could you tell me more about your application? One would usually expect that waiting for the database to respond to a query would dominate the time profile.
Anonymous # 20. August 2009, 09:23
Well just replacing the Connection Pool saved my like 50% of the time used for database interaction. The application is getting data from the database, performing computation on it, and then writing it back. Especially the part where it is written back has suffered from the MCPM. Because of the way the data is written back we are talking about several thousand requests for connections in a very short time. And here the NanoPool is really quicker.
Anonymous # 7. September 2009, 20:30
We have a big home grown app server (based on osgi). Recently we started doing performance load tests and we found out that apache dbcp is a serious bottleneck. We also tried c3p0 but it has a terrible configuration api and the project itself looks stagnating (at least no responses to critical bug reports). I also took a look at Tomcat connection pool in trunk (aka Tomcat 7), it looks promising but I have no idea how to get it separate from Tomcat and when are they going to release it.
Nanopool looks like a good alternative and I am going to load test our app server with it. If it outperforms c3p0 I will consider integrating nanopool in out platform. So I hope you will decide to release it =)
karmazilla # 7. September 2009, 21:53
Originally posted by anonymous:
I just reran my own benchmarks and got a bit surprised. I had remembered it to be faster.
Originally posted by anonymous:
I'm interested in hearing the results. I've never gotten around to integrating c3p0 into my own benchmarks because it does not implement DataSource, which means I have to build a wrapper. I really have no idea how it performs.
Anonymous # 17. September 2009, 10:45
c3p0 has ComboPoolDataSource which does indeed implement DataSource
karmazilla # 17. September 2009, 12:01