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: [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]
---------------------------------------------------------------------
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]
