Commons Dbcp
  1. Commons Dbcp
  2. DBCP-221

How to close the connection pool without shutting down the JVM while there are connections being used?

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.2
    • Fix Version/s: 1.3
    • Labels:
      None

      Description

      Suppose there are several connections being used now by different servlets. calling the basicDataSource,close() does not have any impact on the connection pool. I expect that after these servlet return the connections the pool should be shut down immediately. I also expect that any more requests to borrow connections from the pool should not be fulfilled. However, my experiment does not seem to support my expectations. Calling basicDataSource.close() seems to be ignored while there are connections being used.

        Activity

        Hide
        metatech added a comment -

        The "lock" problem happens because the cancel() must first be called on java.sql.Statement being executed (which is allowed to be called from another thread).

        Show
        metatech added a comment - The "lock" problem happens because the cancel() must first be called on java.sql.Statement being executed (which is allowed to be called from another thread).
        Hide
        metatech added a comment -

        If you wish to terminate active connections as well, you can try the following code.
        Note : the BasicDataSource must be created with the property "removeAbandoned" set to true.

        ds.setRemoveAbandonedTimeout(1);
        ds.setMaxActive(1);
        Connection conn = ds.getConnection();
        ds.close();
        conn.close();
        

        However, with the Oracle JDBC driver, the code can fail when the active connection waits for a database lock, because of a Java lock in the JDBC driver.

        Show
        metatech added a comment - If you wish to terminate active connections as well, you can try the following code. Note : the BasicDataSource must be created with the property "removeAbandoned" set to true. ds.setRemoveAbandonedTimeout(1); ds.setMaxActive(1); Connection conn = ds.getConnection(); ds.close(); conn.close(); However, with the Oracle JDBC driver, the code can fail when the active connection waits for a database lock, because of a Java lock in the JDBC driver.
        Hide
        Phil Steitz added a comment -

        The problem with supporting restart is that you either have to force close the connections that are checked out to clients (not generally a happy scenario) or you no longer have a uniform pool of connections. Deciding how to handle the latter problem from the pool's perspective is probably what stalled the implementation of "restart". If you have ideas about how to implement this without adding too much complexity for the user or dbcp iteslf, we should discuss them on the dev list.

        Show
        Phil Steitz added a comment - The problem with supporting restart is that you either have to force close the connections that are checked out to clients (not generally a happy scenario) or you no longer have a uniform pool of connections. Deciding how to handle the latter problem from the pool's perspective is probably what stalled the implementation of "restart". If you have ideas about how to implement this without adding too much complexity for the user or dbcp iteslf, we should discuss them on the dev list.
        Hide
        Roshan Gunasekara added a comment -

        I agree with the change of behaviour of close() so that its permanently closed.

        However we relied on the current behaviour as a way of restarting the Connection Pool after changing its properties without a full JVM restart. (e.g. change the Database URL). I agree this is a hack and there is no guarantee it will continue to work.

        But I think you might agree, is a useful feature to have. Looking at the source code, I spotted a restart() method which is currently private and not used, which just calls close().

        Will it make sense to expose this method and have an overloaded method close(boolean permanent) which controls if its a permanent close or not.

        If you agree, I am happy to submit a patch.

        Show
        Roshan Gunasekara added a comment - I agree with the change of behaviour of close() so that its permanently closed. However we relied on the current behaviour as a way of restarting the Connection Pool after changing its properties without a full JVM restart. (e.g. change the Database URL). I agree this is a hack and there is no guarantee it will continue to work. But I think you might agree, is a useful feature to have. Looking at the source code, I spotted a restart() method which is currently private and not used, which just calls close(). Will it make sense to expose this method and have an overloaded method close(boolean permanent) which controls if its a permanent close or not. If you agree, I am happy to submit a patch.
        Hide
        Dain Sundstrom added a comment -

        BasicDataSource.close() now permanently marks the data source as closed. No new connections can be obtained from a closed data source. At close all idle connections are destroyed and the method returns. As existing active connections are closed, they are destroyed.

        Show
        Dain Sundstrom added a comment - BasicDataSource.close() now permanently marks the data source as closed. No new connections can be obtained from a closed data source. At close all idle connections are destroyed and the method returns. As existing active connections are closed, they are destroyed.
        Hide
        Bill Liu added a comment -

        Thanks Phil.

        So what is the appropriate way to shut down (forcefully) a connection pool, assuming we have a serious db issue?

        Show
        Bill Liu added a comment - Thanks Phil. So what is the appropriate way to shut down (forcefully) a connection pool, assuming we have a serious db issue?
        Hide
        Phil Steitz added a comment -

        Behavior here is determined by the underlying pool. In the case of commons pool's GenericObjectPool, which BasicDataSource uses, the close method only closes idle connections in the pool. The BasicDataSource Javadoc should be improved to make it clear that only idle connections are closed when close is invoked on the BasicDataSource.

        Show
        Phil Steitz added a comment - Behavior here is determined by the underlying pool. In the case of commons pool's GenericObjectPool, which BasicDataSource uses, the close method only closes idle connections in the pool. The BasicDataSource Javadoc should be improved to make it clear that only idle connections are closed when close is invoked on the BasicDataSource.

          People

          • Assignee:
            Dain Sundstrom
            Reporter:
            Bill Liu
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development