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