Commons Dbcp
  1. Commons Dbcp
  2. DBCP-300

remove synchronize access of createDataSource

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.2, 1.3, 1.4
    • Fix Version/s: 2.0
    • Labels:
      None
    • Environment:

      RHEL, jdk1.5.0_12, commons-dbcp 1.2.2

      Description

      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.

        Activity

        Hide
        Mark Thomas added a comment -

        This has been fixed for DBCP 2.x onwards.

        Earlier versions can't be fixed since double-checked locking requires Java 1.5+ to work correctly.

        Show
        Mark Thomas added a comment - This has been fixed for DBCP 2.x onwards. Earlier versions can't be fixed since double-checked locking requires Java 1.5+ to work correctly.
        Hide
        Dapper Dano added a comment -

        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?

        Show
        Dapper Dano added a comment - 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?
        Hide
        Mark Thomas added a comment -

        API change -> bump to 2.0

        Show
        Mark Thomas added a comment - API change -> bump to 2.0
        Hide
        Phil Steitz added a comment -

        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.

        Show
        Phil Steitz added a comment - 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.
        Hide
        Phil Steitz added a comment -

        In this case, the locking is in DBCP itself:

        public Connection getConnection() throws SQLException

        { return createDataSource().getConnection(); }

        and createDataSource is synchronized.

        Show
        Phil Steitz added a comment - In this case, the locking is in DBCP itself: public Connection getConnection() throws SQLException { return createDataSource().getConnection(); } and createDataSource is synchronized.
        Hide
        Mark Thomas added a comment -

        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.

        Show
        Mark Thomas added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Nikhil Singh
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development