https://issues.apache.org/bugzilla/show_bug.cgi?id=54116
Priority: P2
Bug ID: 54116
Assignee: dev@tomcat.apache.org
Summary: Deadlocks with mysql driver
Severity: critical
Classification: Unclassified
OS: Linux
Reporter: casado.alfr...@gmail.com
Hardware: PC
Status: NEW
Version: unspecified
Component: jdbc-pool
Product: Tomcat Modules
Created attachment 29567
--> https://issues.apache.org/bugzilla/attachment.cgi?id=29567&action=edit
stack information with the blockeds threads
The problem is very well detailed in the following mysql bug:
http://bugs.mysql.com/bug.php?id=64954
I found exactly the same situation related in this mysql bug. The answer from
mysql guys is:
"This is precisely the reason the JDBC-4.0 spec added the abort() method. There
is no foolproof way to implement the semantics of Connection.close() *and*
never have deadlocks.
The abort() method is designed to be used in these cases (it takes no locks,
but doesn't attempt to clean up currently open statements, etc).
Have you asked your connection pool vendor why they're not using the abort()
method?"
And the bug's is market with "won't fix". My question is, ¿is jdbc-pool using
this abort method instead of close?, ¿if the "Pool-Cleaner" is one of the
threads involved in the blocking this can cause connections not removed from
the pool?. I attach to this bug the stack trace information, yo can see that
this thread is blocked. I can reproduce this error via load/stress testing the
application, in production this error occurs randomly between 3 or 4 days
running.
For more information i'm using grails with the grails tomcat jdbc plugin
(http://grails.org/plugin/jdbc-pool).
--
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
