Lock wait timeout: Could not commit JPA transaction

Question

We are using MySQL v5.1.67 under Solaris (SmartOS) in a zone. We are using Java EE and Jetty as our servlet container (Hibernate, Ehcache). Sometimes we get: "Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Error while commiting the transaction" and then "Lock wait timeout exceeded; try restarting transaction". We have the database as one file instead of one file per table. The file is large about 20 GB. There are millions of rows in many tables. One table has 30 million rows. Some table has varchar(255)s. Some others have texts. It seems like cells in the database has been broken. Because if you try to update the same entry in the DB you get a "Lock wait timeout exceeded; try restarting transaction", just by issuing a MySQL query. The problem persists until you restart the DB server. Sometimes they start appearing again after a while. Now they seem to come more and more often. There are a lot of threads in the Java EE .war application. We send more and more JMS messages. There is also PHP-code accessing the database. How do we stop this problem from occuring?

Answer 1

I don't think it's threads deadlocking. I've seen this problem many times before and I've always been able to fix it by restarting the MySQL-server. Then it executes normally day after day. Then something special happens and then it fails every day until I restart mysql. I've also encountered the same problem using the test database I have on my local machine. Only one job executes, the one I'm testing. First it works every run. Something special happens usually triggered by errant code. I fix the error. The job continues to fail with the same message "Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Error while commiting the transaction". If try to do a simple UPDATE SQL query accessing exactly the row that's been corrupted, I get a lock wait timeout. But if I restart the database it starts working again. The update works and the Java job works both locally and on the server. But now a special job has experienced more severe problems of this nature. I restart mysql and the job works when triggered manually but not when triggered chronologically on schedule. Actually all failed first and then a few worked but most failed. It's the same job executing multiple times.