Hello,
I encountered multiple times a deadlock in realClose of ServerPreparedStatement using MySQL-connector-j-3.1.14.
I'm running on Tomcat 6.0.20 with dbcp 1.2.1.
That problem occurs more and more since I'm using BIRT (reporting tool) but I can't understand why Mysql driver is dead-locking. Is it possible that the way an application is implemented could cause a deadlock in MySQL connector??
Java stack information for the threads listed above:
===================================================
"http-80-108":
at org.apache.commons.dbcp.BasicDataSource.getNumActive(BasicDataSource.java:375)
- waiting to lock <0x558a25e0> (a org.apache.commons.dbcp.BasicDataSource)
at system.CheckConnections.doGet(CheckConnections.java:34)
...
"http-80-1":
at org.apache.commons.pool.impl.GenericObjectPool.getNumActive(GenericObjectPool.java:906)
- waiting to lock <0x55aa3af8> (a org.apache.commons.dbcp.AbandonedObjectPool)
at org.apache.commons.dbcp.BasicDataSource.getNumActive(BasicDataSource.java:376)
- locked <0x558a25e0> (a org.apache.commons.dbcp.BasicDataSource)
...
"http-443-49":
at com.mysql.jdbc.ServerPreparedStatement.realClose(ServerPreparedStatement.java:859)
- waiting to lock <0x593e3638> (a com.mysql.jdbc.ServerPreparedStatement)
at com.mysql.jdbc.Connection.closeAllOpenStatements(Connection.java:2128)
...
"http-443-53":
at com.mysql.jdbc.ServerPreparedStatement.realClose(ServerPreparedStatement.java:870)
- waiting to lock <0x590b6758> (a com.mysql.jdbc.Connection)
- locked <0x593e3638> (a com.mysql.jdbc.ServerPreparedStatement)
at com.mysql.jdbc.ServerPreparedStatement.close(ServerPreparedStatement.java:463)
at org.apache.commons.dbcp.DelegatingStatement.close(DelegatingStatement.java:165)
...
I encountered multiple times a deadlock in realClose of ServerPreparedStatement using MySQL-connector-j-3.1.14.
I'm running on Tomcat 6.0.20 with dbcp 1.2.1.
That problem occurs more and more since I'm using BIRT (reporting tool) but I can't understand why Mysql driver is dead-locking. Is it possible that the way an application is implemented could cause a deadlock in MySQL connector??
Java stack information for the threads listed above:
===================================================
"http-80-108":
at org.apache.commons.dbcp.BasicDataSource.getNumActive(BasicDataSource.java:375)
- waiting to lock <0x558a25e0> (a org.apache.commons.dbcp.BasicDataSource)
at system.CheckConnections.doGet(CheckConnections.java:34)
...
"http-80-1":
at org.apache.commons.pool.impl.GenericObjectPool.getNumActive(GenericObjectPool.java:906)
- waiting to lock <0x55aa3af8> (a org.apache.commons.dbcp.AbandonedObjectPool)
at org.apache.commons.dbcp.BasicDataSource.getNumActive(BasicDataSource.java:376)
- locked <0x558a25e0> (a org.apache.commons.dbcp.BasicDataSource)
...
"http-443-49":
at com.mysql.jdbc.ServerPreparedStatement.realClose(ServerPreparedStatement.java:859)
- waiting to lock <0x593e3638> (a com.mysql.jdbc.ServerPreparedStatement)
at com.mysql.jdbc.Connection.closeAllOpenStatements(Connection.java:2128)
...
"http-443-53":
at com.mysql.jdbc.ServerPreparedStatement.realClose(ServerPreparedStatement.java:870)
- waiting to lock <0x590b6758> (a com.mysql.jdbc.Connection)
- locked <0x593e3638> (a com.mysql.jdbc.ServerPreparedStatement)
at com.mysql.jdbc.ServerPreparedStatement.close(ServerPreparedStatement.java:463)
at org.apache.commons.dbcp.DelegatingStatement.close(DelegatingStatement.java:165)
...