commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [DBCP] Connection just obtained from datasource is invalid
Date Fri, 12 Jan 2018 15:27:40 GMT
On 1/9/18 5:09 PM, Shawn Heisey wrote:
> On 1/9/2018 11:50 AM, Phil Steitz wrote:
>> thread 1: checkOpen - sees true
>> thread 2: close the DelegatingConnection  (there is no sync to
>> prevent this)
>> thread1 : createStatement - bang!
>> thread1 : isClosed() returns true
>> DBCP is not really safe to use that way - i.e., really the intended
>> setup is that individual connection handles are not concurrently
>> accessed by multiple threads.  Is it possible something like this is
>> going on?  Note that what I am talking about here is two different
>> threads holding references to the same connection handle - i.e., no
>> trips back through the pool.
> I am about 99 percent sure that I never pass Connection objects between
> threads.  What code I've looked at borrows, uses, and closes the
> Connection with a single thread.  I have some helper methods that take a
> connection, but in all the code I've looked at so far, it's all running
> in the same thread that borrowed the Connection in the first place.
> I can tell you for sure that my *intent* when I wrote the code was to
> always handle a Connection lifecycle in one single thread.  I wasn't
> absolutely sure that sharing the object between threads would cause
> problems, but doing so seemed like a bad idea.

The other possibility here is a pool bug causing the same connection
to be handed out to two different clients.  The DefaultPooledObject
machinery and other guards in [pool] make that unlikely.  There are
tests in [pool] that verify that this does not happen. 
Specifically, the unit test named testNoInstanceOverlap is set up to
detect "instance sharing."  I modified it to have a setup similar to
yours (lots of concurrent eviction, maxIdle < maxTotal, etc.) and
soaked it with a range of different configs and could not get
"overlap" to happen.  Feel free to play with that test and see if
you can get a failure.  I can't see how this can happen, honestly;
thoug.  If your code can't be sharing across threads, I don't see
how the combination of the stack trace posted and isClosed returning
true immediately after could happen.

> Thanks,
> Shawn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message