[
https://issues.apache.org/jira/browse/DBCP-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz closed DBCP-339.
----------------------------
Resolution: Duplicate
Closing as duplicate of DBCP-342. Technically, it is the other way around
(this issue was raised earlier), but DBCP-342 has fuller discussion and patch.
> orphaned connectionPools created on Exception within createDataSource method
> ----------------------------------------------------------------------------
>
> Key: DBCP-339
> URL: https://issues.apache.org/jira/browse/DBCP-339
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2.2, 1.3, 1.4
> Environment: Linux
> MySQL 5.1.47
> JDK 1.6
> commonsPool 1.5.4
> Reporter: Mike Bartlett
> Fix For: 1.3.1, 1.4.1
>
> Attachments: DBCP-339.patch
>
>
> When an Exception is thrown in the BasicDataSource.createDataSource after the
> connectionPool instance variable has been set the connectionPool is not
> closed.
> If the timeBetweenEvictionRunsMillis is greater than zero a TaskTimer evictor
> is created in the GenericObjectPool. This TaskTimer keeps running even though
> the DataSource was not successfully created. The evictor when it runs will
> attempt to create connections for this orphaned connectionPool up to the min
> connections (minIdle).
> If the database is down when the createDataSource is called an Exception will
> be thrown and an orphaned connectionPool will be created. If serveral retries
> are attempted while the database is down several orphaned connectionPools are
> created. Once the database is back up, all these orphaned connectionPool's
> evitor threads will attempt to created minIdle connections to the database.
> This exhausts the max num connections on the database.
> One solution to to close the connectionPool when an Exception is thrown
> within the createDataSource method.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
