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 > > Phil >> Thanks, >> Shawn >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
