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

2012-02-14 Thread Mark Thomas (Commented) (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




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

2012-02-14 Thread Mark Thomas (Commented) (JIRA)

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

Mark Thomas commented on POOL-209:
--

If you see this issue, please also provide details of the version of commons 
pool that you are using.

> 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




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

2011-12-23 Thread Greg Roberts (Commented) (JIRA)

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

Greg Roberts commented on POOL-209:
---

I've just started getting "Attempted to use PooledConnection after closed() was 
called." errors after moving to jTDS 1.2.5 and dbcp 1.4.

I'm also using Torque 3.3 and java 1.6.

Has there been any resolution to this problem?

Is there a workaround/fix of some kind?

Thanks.

> 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