[jira] [Commented] (POOL-209) SharedPoolDataSource does not handle null keys correctly

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (POOL-209) SharedPoolDataSource does not handle null keys correctly

ASF GitHub Bot (Jira)

    [ https://issues.apache.org/jira/browse/POOL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207997#comment-13207997 ]

Mark Thomas commented on POOL-209:
----------------------------------

I have been reviewing the 1.5.4 and 1.5.x pool code against the 3 issues identified above:

1.) Creating new object for latch is not synchronized, so there is a probability that other thread overrides the latch pair (GenericKeyedObjectPool:1177)
2.) Allocate() method does not care if the latch pair is already assigned in 1.) (~1245).
3.) I guess latch accesses should be synchronized to avoid latch changes between lines.

re 3: I intend to ignore as per my previous comments until such time as it is substantiated with an explanation of how a problem may occur.

re 1: I disagree with the analysis. Setting mayCreate on the latch is performed inside a sync block on the keyed pool. At the same time as mayCreate is set, the latch is removed from the allocation queue. Therefore, another thread cannot provide an object for that latch. Object creation is performed in the borrowObject() method and the latch is a local variable and is therefore only visible to a single thread. I do not see a sequence of events that could result in two threads creating an object for the same latch.

re 2: Same argument as 1.

All the latch getters and setters are synchronized therefore any attempt to read latch attributes will see the latest values even if the write and read are in separate threads.


So far there have been several explanations of how this issue may occur but, as yet, none of them have stood up to scrutiny (assuming my analysis is correct - not always a valid assumption). I wouldn't be surprised if there was a pool bug here somewhere - the code is somewhat complex - but I'm going to need either a test case that demonstrates the issue or an explanation of how the problem occurs before I start changing any code.

There have been a few fixes (although none that look relevant to this issue) since 1.5.4 so it would be good to update to the latest 1.5.x (or 1.6.x if you want generics) and repeat the tests.
               

> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
>                 Key: POOL-209
>                 URL: https://issues.apache.org/jira/browse/POOL-209
>             Project: Commons Pool
>          Issue Type: Bug
>         Environment: Windows, java version "1.6.0_06", Torque 3.3 (DBCP 1.4, jTDS 1.2.5)
>            Reporter: Gabor Horvath
>         Attachments: GenericKeyedObjectPool.java
>
>
> 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, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira