Re: [dbcp] aborting abandoned connections

[Phil Steitz <ph...@gmail.com>]

On 7/27/15 1:42 PM, Bernd Eckenfels wrote:
> Hello,
>
> I was investigating the behavior of dbcp in regards to killing
> longrunning/hanging statements (specifically for the Oracle driver).
>
> Oracle driver synchronizes on the physical connection for some things
> like connection.close() or statement.close() or .isClosed() or
> the vendor specific _getPC().
>
> This can cause the abandoned connection close of commons-pool to hang.
> There are some (older) driver specific methods to work around this, and
> there is also a new JDBC method in Java 7:
>
>
> http://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#abort%28java.util.concurrent.Executor%29
>
> If you do not use this method, the hang will look like this:
>
> "commons-pool-EvictionTimer" Id=12 BLOCKED on
> oracle.jdbc.driver.T4CConnection@3cd1f1c8 owned by "Thread-2" Id=14
> 	at
> oracle.jdbc.driver.OracleStatement.close(OracleStatement.java:1343)
> 	-  blocked on oracle.jdbc.driver.T4CConnection@3cd1f1c8
> 	at
> oracle.jdbc.driver.OracleStatementWrapper.close(OracleStatementWrapper.java:100)
> 	at
> oracle.jdbc.driver.OraclePreparedStatementWrapper.close(OraclePreparedStatementWrapper.java:82)
> 	at
> org.apache.commons.dbcp2.DelegatingStatement.close(DelegatingStatement.java:156)
> 	at
> org.apache.commons.dbcp2.DelegatingConnection.passivate(DelegatingConnection.java:631)
> 	at
> org.apache.commons.dbcp2.PoolableConnection.passivate(PoolableConnection.java:127)
> 	at
> org.apache.commons.dbcp2.DelegatingConnection.closeInternal(DelegatingConnection.java:232)
> 	at
> org.apache.commons.dbcp2.PoolableConnection.reallyClose(PoolableConnection.java:243)
>
> I would add an optional policy to close the connection which can do the
> old way (close all statements then the connection) or a JDBC 4.1 way
> (using abort(exe) only) or even some drive specific way (calling
> abort() via relfection).
>
> I wonder if it should be different for killing abandoned and killing
> expired connections, but I think since all of them are terminated, all
> can use the same strict method for purging them,

+1 - I see no reason to treat abandoned connections differently.
>
> Some test code (for Oracle driver) with output is here:
>
> https://gist.github.com/ecki/345ee08ac97820972fe7

This seems like a reasonable enhancement request to me.  We would
definitely want to make it configurable and off by default because
of the security and driver support requirements.  We would also have
to agree on a way to manage Executors and think carefully through
the consequences of moving to async close operations.  If no one has
objections to pursuing this, I will open a JIRA and we can start
exploring for 2.2.

Phil

>
> Gruss
> Bernd
>
>
>  Am
> Mon, 27 Jul 2015 08:47:45 -0700 schrieb Phil Steitz
> <ph...@gmail.com>:
>
>> On 7/27/15 7:18 AM, Bernd wrote:
>>> Hi Phil,
>>>
>>> ah great, I can confirm that it is logging something if I add the
>>> auto flush:
>>>
>>> https://gist.github.com/ecki/345ee08ac97820972fe7#file-result-autoflush4s-txt
>>>
>>> (It even logs the active statements, so I guess it tries to kill
>>> them (but get blocked by my initial problem). What do you think
>>> does it make sense to provide a JDBC compliant abort() variant?)
>> I was thinking about suggesting that on dev@ - would you mind
>> posting there?



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org