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. Phil > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
