DBとしてMySQL 5.1を使用するQuartz 1.6.1 w/persistentジョブストアを実行するアプリケーションがあります。このアプリケーションは、Tomcat6で正常に起動するために使用されました。一貫性のあるトラブルシューティング "SQLException：ロック待ちタイムアウトを超えました"
- MisfireHandler: Error handling misfires: Failure obtaining db row lock: Lock wait timeout exceeded; try restarting transaction
org.quartz.impl.jdbcjobstore.LockException: Failure obtaining db row lock: Lock wait timeout exceeded; try restarting transaction [See nested exception: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction]
at org.quartz.impl.jdbcjobstore.StdRowLockSemaphore.executeSQL(StdRowLockSemaphore.java:112)
at org.quartz.impl.jdbcjobstore.DBSemaphore.obtainLock(DBSemaphore.java:112)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.doRecoverMisfires(JobStoreSupport.java:3075)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:3838)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:3858)
Caused by: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1055)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3491)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1885)
at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:76)
at org.quartz.impl.jdbcjobstore.StdRowLockSemaphore.executeSQL(StdRowLockSemaphore.java:92)
... 4 more
私は、このアプリケーションはまた、Hibernateは、データソース接続プーリングのためにC3P0を使用してのw/JPAを利用言及する必要があります：いくつかの時点では、起動のたびに、次の例外をスローし始めました。この例外は、JPAがスキーマの更新を終了した直後に常にスローされます。
まず、私はQuartz 1.6.5にアップグレードしましたが、例外はなくなりましたが、アプリケーションはフリーズしています。ログ内の最後のもの - 例外がどこにあったか：
...hbm2ddl stuff...
2969 [Thread-1] INFO org.hibernate.tool.hbm2ddl.SchemaUpdate - schema update complete
- Handling 6 trigger(s) that missed their scheduled fire-time.
何も来ておらず、Webアプリケーションではリクエストを処理していません。彼らは無期限にハングアップします。
私はのSHOW INNODBステータスでのmysqlコマンドラインクライアントを実行すると、右例外の後、それは一貫して2つの疑わしい取引を示してい：
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 49, signal count 49
Mutex spin waits 0, rounds 2100, OS waits 0
RW-shared spins 115, OS waits 49; RW-excl spins 0, OS waits 0
------------
TRANSACTIONS
------------
Trx id counter 0 165688
Purge done for trx's n:o < 0 165685 undo n:o < 0 0
History list length 12
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 0, not started, OS thread id 5012
MySQL thread id 8, query id 1798 localhost 127.0.0.1 root
SHOW INNODB STATUS
---TRANSACTION 0 165687, ACTIVE 300 sec, OS thread id 3772
2 lock struct(s), heap size 320, 1 row lock(s)
MySQL thread id 30, query id 1795 localhost 127.0.0.1 my_app
---TRANSACTION 0 165685, ACTIVE 360 sec, OS thread id 5460
2 lock struct(s), heap size 320, 1 row lock(s), undo log entries 1
MySQL thread id 34, query id 1680 localhost 127.0.0.1 my_app
を、私はどのようにさらにへの指導を探していますこの問題を調査してください。おそらく、もし私が何らかの形でこれら2つの取引の所有者、または彼らがロックしている資源を特定できれば？
アップデート：私は問題なくqrtz_simple_triggersテーブル内のすべての行を削除しました。私はそれからqrtz_triggersテーブルで同じことを試みました。そして、私のMySQLクライアントは "ロック待ちタイムアウトを超えました"というエラーを投げました。この時点で私は自分のアプリケーションを止めて、qrtz_triggersテーブルのすべての行を削除することができました。これが完了すると、私はアプリケーションを正常に起動することができました。
私は新しいQuartzのバグを記録する必要がありますが、ここに実際に何が起こっているのかについての詳しい情報を提供したいと思います。したがって、元の質問ごとに、これらのタイプの問題をどのようにトラブルシューティングできますか？