Hi Daniel,

    What appears to be happening is that the same connection is being returned by getConnection2().  Basically the implementation of the pool is not thread safe.  The NPE is thrown when the statement attempts to access its internal parameter meta data which is nulled out when the underlying physical connection is reset (flagged for reuse).  The conclusion is that the pool implementation is not safely borrowing/returning connections.

    I've had luck using commons-dbcp in conjunction with commons-pool for server side connection pooling when connecting to a derby database server.


On Tue, Mar 4, 2008 at 5:52 PM, Daniel Noll <daniel@nuix.com> wrote:
On Wednesday 05 March 2008 12:43:44 Raymond Kroeker wrote:
> Hi Daniel,
>     Which pool/version are you using?  Also how are you configuring the
> pool?  You want to make sure your library is wrapping the connection  or
> if not; is interfacing with the pooled connection/data source object.

Data source configuration is... (parameters is our own bean for storing this

ClientConnectionPoolDataSource dataSource =
   new ClientConnectionPoolDataSource();

We're using MCPM as the pool manager, it's just a simple connection pool
manager in a single Java class which uses PooledConnection to do the hard

Relevant code is probably:

 private synchronized Connection getConnection2() throws SQLException {
   PooledConnection pconn;
   if (!recycledConnections.empty()) {
     pconn = recycledConnections.pop();
   } else {
     pconn = dataSource.getPooledConnection();
   Connection conn = pconn.getConnection();
   return conn;

As it's going via PooledConnection I was expecting it to be reusable after
closing.  This works in practice for the embedded version anyway.

I've checked the MCPM code and close() is only called during disposeConnection
and certainly not during recycleConnection.


Raymond Kroeker