I need to close the connection, not return it back to the Connection Pool

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

I need to close the connection, not return it back to the Connection Pool

王钦
Hi All:
     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.

Thanks
Qin




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: I need to close the connection, not return it back to the Connection Pool

Shawn Heisey
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.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: I need to close the connection, not return it back to the Connection Pool

Phil Steitz
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: I need to close the connection, not return it back to the Connection Pool

王钦
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

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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: I need to close the connection, not return it back to the Connection Pool

Phil Steitz
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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: I need to close the connection, not return it back to the Connection Pool

王钦
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.

Thanks

Qin


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




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]