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 Mon, 26 Dec 2016 06:03:47 GMT
Hi Phil:

     Thanks for you advice. I have tried to use DBCP 2.2, but its driver 
manager could not support org.apache.hive.jdbc.HiveDriver.



On 2016年12月24日 03:17, Phil Steitz wrote:
> 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.
>>>> 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:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message