On 12/22/16 7:22 PM, 王钦 wrote: > Hi Shawn & Phil: > > Thank you for your help. > > The scenario I faced is like this: > > In the usual work time, there will be plenty of connections to > the Impala Database. So I need a Connection Pool to manage them. > > When a query is executed for a long time and the client wants > to cancel it manually, closing the connection for this query > really is one solution (or maybe a poor solution.)
OK, so the best solution would be to find a way to kill or set a timeout on the query, but I understand that may not be possible, so you want to be more brutal and kill the connection. The best here would be to upgrade to DBCP 2.2 and use the invalidate method that was added for this kind of use case. Upgrading to DBCP2/Pool2 has other benefits as well. Phil > > And thank you for your help again. > > > Best Wishes > > Qin > > > > On 2016年12月23日 04:47, Phil Steitz wrote: >> On 12/22/16 9:34 AM, Shawn Heisey wrote: >>> On 12/22/2016 4:49 AM, 王钦 wrote: >>>> When I use DBCP-1.4 in my work, I need to close the >>>> connection >>>> which is generated by BasicDataSource. How can I do it? Close the >>>> connection, while not returning it back to the Connection Pool. >>> The PoolableConnection class (which I believe is the actual type of >>> object you will receive from the data source) has a >>> "reallyClose()" method. >>> >>> http://commons.apache.org/proper/commons-dbcp/api-1.4/org/apache/commons/dbcp/PoolableConnection.html#reallyClose() >>> >>> >>> I'm no expert, but I think you might be able to cast the connection >>> received from BasicDataSource to the Poolable variety. >>> >>> If you intend to "reallyClose()" every connection (rather than >>> just some >>> of them), I do have to wonder why you're using DBCP at all. >>> Obtaining >>> connections from JDBC directly and closing them normally would >>> accomplish the same thing without a code dependency and slightly >>> less >>> overhead. >> I agree with your statement about defeating the purpose of the pool >> if you do this every time. If done only when the client knows the >> connection is bad, the solution above will unfortunately leak pool >> capacity (reallyClose doesn't inform the pool that the checked out >> connection is never coming back). A sort of ugly workaround for >> that would be to enable abandoned connection cleanup, which would >> eventually clean these up. >> >> What you need to do to do this cleanly is to get the underlying >> GenericObjectPool to invalidate the PoolableConnection so its >> accounting is correctly updated. If you are willing to upgrade to >> DBCP 2, BasicDataSource now has an invalidateConnection method that >> handles this. If not, the only way to do this without leaking >> capacity is to do what the source for that method does, which >> requires that you get a reference to the underlying object pool. >> BasicDatasource does not expose that, so if you want to go this >> route, you need to manually create the GOP and use a >> PoolingDatasource. >> >> Phil >>> Thanks, >>> Shawn >>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>> For additional commands, e-mail: user-h...@commons.apache.org >>> >>> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
