[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
