commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] Commented: (DBCP-331) SharedPoolDataSource does not handle null keys correctly
Date Sat, 17 Apr 2010 14:38:24 GMT


Phil Steitz commented on DBCP-331:

I am feeling stupid now for having moved this to DBCP.  While there may be DBCP issues exposed
here as well, I concur with Gabor's analysis that GOP, GKOP can fail as follows:

Thread 1:  enters borrowObject, creates a latch and puts it into the allocation queue
Thread 1:  allocate() does not serve the latch, but does set mayCreate() to true
Thread 1:  creates a good new instance, "goodGuy" and assigns it to its latch
Thread 1:  enters validateObject
Thread 2:  returns an invalid instance, "badGuy"
Thread 2:  allocate() serves Thread1's latch with "badGuy"
Thread 1:  finishes validateObject successfully, but its latch now carries "badGuy" which
is returned to the client

Note that this also effectively leaks "goodGuy."

I don't have a test case to demonstrate this yet and I can't fully explain the stack trace
without assuming something else awry in the DBCP code, so the above may be flawed, but it
looks to me like this is a pool bug. 

IIUC what is going on, it is probably best to rely on the latch's monitor in the fix, "closing"
it when it is being served in borrowObject and removing but ignoring it in allocate if it
is closed. 

Gabor:  can you post some more info on the DBCP config - in particular, is testOnReturn false,
 how are maxIdle, minIdle set, is the evictor enabled, and are you using DriverAdaptorCPDS
(looks like yes)?  Thanks!

> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>                 Key: DBCP-331
>                 URL:
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.3, 1.4
>         Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
>            Reporter: Gabor Horvath
>         Attachments:
> GenericKeyedObjectPool.borrowObject does not invalidate object if validateObject fails
(line ~1200). I guess invalidation would be needed for objects which are not newly created
(newlyCreated flag in the code).
> Scenario:
> 1.) DB connection put into pool
> 2.) Attempt to reuse connection (borrowObject)
> 3.) Test on borrow (executing simple SQL query) fails: DB connection closed on jTDS level
but connection remains in the pool
> 4.) Subsequent attempts to reuse the connection causes "java.sql.SQLException: Invalid
state, the Connection object is closed"

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message