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, Some test code (for Oracle driver) with output is here: https://gist.github.com/ecki/345ee08ac97820972fe7 Gruss Bernd Am Mon, 27 Jul 2015 08:47:45 -0700 schrieb Phil Steitz <[email protected]>: > 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: [email protected] For additional commands, e-mail: [email protected]
