[Bug 54116] Deadlocks with mysql driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Mark Thomas ma...@apache.org --- Inconsistent locking in the driver is not a JDBC pool issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54116] Deadlocks with mysql driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116 --- Comment #3 from Patric Rufflar pat...@rufflar.com --- The pool cleaner thread periodically - checks for abandoned connections (depending on configuration) - does pool resizing (e.g. dropping connections), if necessary - verifies idle connections (depending on configuration) If this thread gets blocked you'll loose this functionality. It depends on your application if you rely on these features or not. Normally, this will not cause your application to fail (completely). If I were you I would drop a comment at the existing mysql issue and tell them that they use inconsistent locking in their jdbc driver which is causing the problem here. Also mention that Connection.abort() is only available in java 7. If they will not fix the inconsistent locking ask for a java 6 compatible solution. BTW: A workaround which will lower the probability of the deadlock is to disable the jdbc-pool's remove abandoned connections feature. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54116] Deadlocks with mysql driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116 --- Comment #1 from Patric Rufflar pat...@rufflar.com --- Looks like mysql jdbc driver bug because they use inconsistent locking: com.mysql.jdbc.ConnectionImpl.close() locks in the following order: 1. com.mysql.jdbc.JDBC4Connection 2. com.mysql.jdbc.JDBC4ResultSet while com.mysql.jdbc.ResultSetImpl.getString() locks in a reversed order: 1. com.mysql.jdbc.JDBC4ResultSet 2. com.mysql.jdbc.JDBC4Connection Because I see no jdbc pool classes involved in the locking of these objects I doubt that jdbc pool is responsible in this deadlock situation. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54116] Deadlocks with mysql driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=54116 --- Comment #2 from Alfredo Casado casado.alfr...@gmail.com --- Thanks for your response. Please can you answer my second question: ¿if the Pool-Cleaner thread is blocked how this affect the behaviour of the pool?, ¿the pool is no longer clean unused connections?. If this is true the problem is really a big issue in production environments using tomcat+mysql. In the first place i go to mysql driver project issue manager, i found one report of a identical bug and following the recomendations in this issue i'm here contacting with my pool vendor. As you can see now i have two deadlocks: one in my production servers and the second one in this bug resolution. As you can see in the mysql bug they insist that the pool implementation must call abort() instead of close(). I'm not sure what are the implications of this. I'm not an expert in JDBC spec and in driver's or pool's implementations details, i can't judge if the problem is in mysql driver like you say or if the problem is in pool implementations, like the mysql guy say. I have the following options: - go again to mysql issue manager and reopen the bug. - don't use jdbc-pool (i think that others pool implementations call close in the same way, the option is not using a pool at all) - don't use mysql j/connector driver. ¿is there another mysql driver implementation i can use? ¿what do you recomend? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
