On 4/13/14, 4:21 PM, sebb wrote: > I added some debug to DelegatingStatement and it appears that > isClosed() is sometimes being called from a different thread than the > one used to create the instance. > > I'm not sure why this should be, because the statements are created in > the TestConnectionPool.PoolTest.run() method and as far as I know > should not escape from there. > > The DelegatingStatement class is not thread-safe, but I don't suppose > it is supposed to be. > > [The Javadoc should make it clear either way] > > If a statement instance is being shared between threads, then this > could explain the test failures. > > Note: I checked the thread usage by saving the value of > Thread.currentThread() in the ctor, and then compared it with the > value returned at checkOpen(). About half the time it was the same > thread. > > Out of 8132 calls to checkOpen() 4012 were from a different thread. > This 4012 included 20 calls from the System finalizer > > I've no idea how this thread sharing is happening - but it does not seem > right.
Here is a little better explanation of how the code works. PoolablePreparedStatements are DelegatingPreparedStatements created by PoolingConnections. PoolingConnections are DelegatingConnections that also act as KeyedPooledObjectFactories so that they can maintain statement pools. Different threads that check out PoolingConnections reuse the statements in the GKOP (keyed on SQL) maintained by the PoolingConnection. The close method of a PoolablePreparedStatement just returns it to its pool. The finalizer that was added to DelegatingPreparedStatement as part of the fix for DBCP-180 was intended to call this class' close method so that a GC-collected PPS would get returned to the pool instead of leaking. I think that what is happening is that the DelegatingConnection wrapped by the PPS is getting closed "out from under it" by the finalizer. In terms of thread safety, this *should* be ensured in general by the PooledObject wrappers that PPS instances are managed in. Letting finalizers access these objects directly is indeed a little dicey, but I think the change I suggested in DBCP-415 might fix things. Alternative safe and effective approaches to DBCP-180 are also welcome. Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
