commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabor Horvath (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DBCP-331) SharedPoolDataSource does not handle null keys correctly
Date Wed, 21 Apr 2010 12:39:50 GMT

    [ https://issues.apache.org/jira/browse/DBCP-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859322#action_12859322
] 

Gabor Horvath commented on DBCP-331:
------------------------------------

Partially agree with your comment.

At the point the latch is removed from the allocation queue we can be sure client will be
served (assuming validation will be ok):
-if allocation was successful allocated object would be returned
-if allocation failed new object is created

Fairness is broken only in the case if newly created object could not be validated, thus requeueing
is needed - this is really a difference. For the remaining scenarios my code works the same
I think: if allocation is successful the latch is removed from the queue anyway.

My proposal to fix this problem is to define a new Latch member to show if the latch must
be served or not: instead of removing latch from the queue we just set the flag which would
be taken into account by allocate(). Method allocate() also would set this flag accordingly
instead of removing the latch from queue. Latch would be removed only when borrowObject returns.
This way fairness is maintained for the latch lifetime. What do you think?

Thanks for the catch!

> SharedPoolDataSource does not handle null keys correctly
> --------------------------------------------------------
>
>                 Key: DBCP-331
>                 URL: https://issues.apache.org/jira/browse/DBCP-331
>             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.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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message