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 Mon, 22 Jan 2018 16:40:53 GMT
On 1/12/18 8:27 AM, Phil Steitz wrote:
> 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.

One more thing to check:  are you sure that in your test where you
check isClosed after the exception you aren't checking after a
finally that closes it? 

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

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

View raw message