[jira] Created: (DBCP-300) remove synchronize access of createDataSource

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (DBCP-300) remove synchronize access of createDataSource

ASF GitHub Bot (Jira)
remove synchronize access of createDataSource
---------------------------------------------

                 Key: DBCP-300
                 URL: https://issues.apache.org/jira/browse/DBCP-300
             Project: Commons Dbcp
          Issue Type: Improvement
    Affects Versions: 1.2.2
         Environment: RHEL, jdk1.5.0_12, commons-dbcp 1.2.2
            Reporter: Nikhil Singh


For JDK1.5 onwards we can make the DataSource volatile and start using "double checked locking" idiom. In my performance testing I have already started seeing wait time on this lock.


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

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (DBCP-300) remove synchronize access of createDataSource

ASF GitHub Bot (Jira)

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

Mark Thomas commented on DBCP-300:
----------------------------------

Which version of commons-pool?
Which lock do you see contention on?

Locking is mostly a POOL rather than DBCP issue. A move to jdk 1.5 would allow the use of j.u.concurrent which will would be a significant change to the locking implementation.

> remove synchronize access of createDataSource
> ---------------------------------------------
>
>                 Key: DBCP-300
>                 URL: https://issues.apache.org/jira/browse/DBCP-300
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2.2
>         Environment: RHEL, jdk1.5.0_12, commons-dbcp 1.2.2
>            Reporter: Nikhil Singh
>
> For JDK1.5 onwards we can make the DataSource volatile and start using "double checked locking" idiom. In my performance testing I have already started seeing wait time on this lock.

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

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (DBCP-300) remove synchronize access of createDataSource

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

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

Phil Steitz commented on DBCP-300:
----------------------------------

In this case, the locking is in DBCP itself:

 public Connection getConnection() throws SQLException {
        return createDataSource().getConnection();
    }

and createDataSource is synchronized.


> remove synchronize access of createDataSource
> ---------------------------------------------
>
>                 Key: DBCP-300
>                 URL: https://issues.apache.org/jira/browse/DBCP-300
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2.2
>         Environment: RHEL, jdk1.5.0_12, commons-dbcp 1.2.2
>            Reporter: Nikhil Singh
>
> For JDK1.5 onwards we can make the DataSource volatile and start using "double checked locking" idiom. In my performance testing I have already started seeing wait time on this lock.

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

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (DBCP-300) remove synchronize access of createDataSource

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

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

Phil Steitz commented on DBCP-300:
----------------------------------

A workaround is to "manually" construct a PoolingDataSource as in the ManualPoolingDataSourceExample linked under Examples on the dbcp home page.  

This issue will be a little tricky to "fix" given the lazy initialization and (supposed) property mutability of BasicDataSource.  One thing we should consider is deprecating BasicDataSource and replacing it with a class whose properties (other than closed) are immutable.

> remove synchronize access of createDataSource
> ---------------------------------------------
>
>                 Key: DBCP-300
>                 URL: https://issues.apache.org/jira/browse/DBCP-300
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2.2
>         Environment: RHEL, jdk1.5.0_12, commons-dbcp 1.2.2
>            Reporter: Nikhil Singh
>
> For JDK1.5 onwards we can make the DataSource volatile and start using "double checked locking" idiom. In my performance testing I have already started seeing wait time on this lock.

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

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (DBCP-300) remove synchronize access of createDataSource

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/DBCP-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Thomas updated DBCP-300:
-----------------------------

    Fix Version/s: 2.0

API change -> bump to 2.0

> remove synchronize access of createDataSource
> ---------------------------------------------
>
>                 Key: DBCP-300
>                 URL: https://issues.apache.org/jira/browse/DBCP-300
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2.2
>         Environment: RHEL, jdk1.5.0_12, commons-dbcp 1.2.2
>            Reporter: Nikhil Singh
>             Fix For: 2.0
>
>
> For JDK1.5 onwards we can make the DataSource volatile and start using "double checked locking" idiom. In my performance testing I have already started seeing wait time on this lock.

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

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (DBCP-300) remove synchronize access of createDataSource

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

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

Dapper Dano commented on DBCP-300:
----------------------------------

Is there going to be any focus on this issue soon?  This can cause quite a few blocked threads if a datasource is timing out, as the first thread will block all others while attempting to connect (21 seconds by default).  After the first times out, the next one attempts to connect while the remaining wait and so on.  This can cause quite a back up.

In the mean time, has anyone found a workaround or alternative substitution for pools in the tomcat application context?

> remove synchronize access of createDataSource
> ---------------------------------------------
>
>                 Key: DBCP-300
>                 URL: https://issues.apache.org/jira/browse/DBCP-300
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2.2
>         Environment: RHEL, jdk1.5.0_12, commons-dbcp 1.2.2
>            Reporter: Nikhil Singh
>             Fix For: 2.0
>
>
> For JDK1.5 onwards we can make the DataSource volatile and start using "double checked locking" idiom. In my performance testing I have already started seeing wait time on this lock.

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