commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DBCP-216) Improvement of error recovery in KeyedCPDSConnectionFactory
Date Wed, 20 Jun 2007 18:27:26 GMT

    [ https://issues.apache.org/jira/browse/DBCP-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506620
] 

Phil Steitz commented on DBCP-216:
----------------------------------

Patch looks correct and appropriate to me, subject to the comments below.  Similar changes
should probably be made to CPDSConnectionFactory.   

Regarding 2., with current backing pool (o.a.c.pool.GenericKeyedObjectPool), the destroy ->
invalidate change (2.) will only work for *active* (i.e., checked out) connections and in
this case it is necessary, but not to "remove from the pool," but to maintain integrity of
the active count.  Unfortunately, the contract of the pool's invalidate method only applies
to objects that have been borrowed from the pool, so if the (exception-generating) connectionClosed
event originates from from an idle connection, this will not work.  This should not happen
in general though, since these events should come from handles from checked out connections.
 

Test cases illustrating the problem in this ticket should be added before committing the patch.

> Improvement of error recovery in KeyedCPDSConnectionFactory
> -----------------------------------------------------------
>
>                 Key: DBCP-216
>                 URL: https://issues.apache.org/jira/browse/DBCP-216
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2.2
>         Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, jConnect 6.0.5
EBF 13862, Commons Pool 1.3
>            Reporter: Marcos Sanz
>             Fix For: 1.3
>
>         Attachments: KeyedCPDSConnectionFactory.java.diff
>
>
> Attached you'll find a patch that improves the recovery of the class in different error
situations.
> 1. The addition of removeConnectionEventListener() in destroyObject() ensures that the
listener is removed, which is not guaranteed to have happened upon call of destroyObject().
We are for sure not interested any more in events, since we are about to destroy.
> 2. The same addition is made to connectionClosed(). Additionally, we have substituted
there the call to destroyObject() with a call to pool.invalidateObject(). This is necessary
because otherwise the object is destroyed but not removed from the pool.
> 3. The same substitution is made in connectionErrorOccurred(), otherwise the object might
remain in the pool.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message