You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Phil Steitz (JIRA)" <ji...@apache.org> on 2007/04/12 08:07:32 UTC

[jira] Commented: (DBCP-215) DBCP's initialSize doesn't work as expected

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

Phil Steitz commented on DBCP-215:
----------------------------------

I agree that the BasicDataSourceFactory should return an initialized pool, based on the properties set and I don't understand why it was not implemented to do that.  I will do some research in the archives to see if this was discussed when the the initialSize parameter was introduced.  Anyone who can give a reason why this should not be done, please chime in here.  By just calling getConnection, or even getLoginTimeout or getLogWriter at the end of the method, the factory's creatDataSource impl could be made to initialize the pool.  Patches welcome.

> DBCP's initialSize doesn't work as expected
> -------------------------------------------
>
>                 Key: DBCP-215
>                 URL: https://issues.apache.org/jira/browse/DBCP-215
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.2.2
>         Environment: Windows XP, jsdk1.4.2_07, Tomcat 5.0.28, commons-dbcp-1.2.2, commons-pool-1.3, hibernate 2.1.7c, mysql-connector-java-5.0.5, MySQL 5.1.11 
>            Reporter: Rafael Leite
>            Priority: Minor
>             Fix For: 1.3
>
>
> I've configured a datasource on Tomcat 5.0.28 using DBCP.
> Reading it's documentation i found out a parameter to specify the datasource's initial number of connections, the "initialSize" parameter. We want this configured so the first users of our system don't have to wait for the datasource to open the first connections to the database.
> When put it to work, it didn't initialize the connections as defined on the "initialSize" parameter.
> I've made a lot of tests using the "minIdle" parameter as well, but the connections are created only when the first user hits the application.
> The BasicDataSourceFactory class initializes the datasources parameters and the BasicDataSource class just create the initial connections when called according to the DataSource interface (most likely on the getConnection() method). IMHO, this way the initialSize parameter doesn't work as expected.
> The DBCP-147 issue changed the BasicDataSource class to include the loop that create the initial connections, but the patch don't really create the connections when the datasource is created, only when it is called.
> My suggestion is: before the BasicDataSourceFactory.createDataSource() method returns it should ask the datasource to connect to create the initial connections according to the initialSize parameter.
> #1 One way could be to make the BasicDataSource.createDataSource() method public and, if the initialSize parameter is higher than zero, call it at the end of the BasicDataSourceFactory.createDataSource() method.
> #2 Another possibility could be to create a initialize() method on BasicDataSource. According to its parameters it could create the initial connections to the database.
> #3 To avoid changes to BasicDataSource, one could create a subclass of BasicDataSource (lets call it X) with a constructor that receives an instance of the superclass. On this constructor X'd copy all the attributes from the superclass to it and call the inherited createDataSource() method. At the end of the BasicDataSourceFactory.createDataSource() method, if the initialSize parameter is higher than zero the factory would return a new instance of X passing as parameter the BasicDataSource instance that was initialized with the datasource's parameters.
> I've created as a bug since the "initialSize" parameter doesn't work as expected.
> What do you guys think of this issue?
> Thanks in advance for your time!

-- 
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