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

• Key: DBCP-221
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Dain Sundstrom
• Reporter: Bill Liu
• Affects Version/s: 1.2.2
• Fix Version/s: 1.3

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.

Comments

[Phil Steitz]

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.

[Bill Liu]

Thanks Phil.

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

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.

[Roshan Gunasekara]

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.

[Phil Steitz]

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.