commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 王钦 <>
Subject Re: I need to close the connection, not return it back to the Connection Pool
Date Fri, 23 Dec 2016 02:22:53 GMT
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.)

     And thank you for your help again.

Best Wishes


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.
>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message