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