Поиск и устранение неисправностей последовательного “SQLException: Блокировка ожидает, тайм-аут превысил”

У меня есть приложение, выполняющее Кварц 1.6.1 w/persistent хранилищ задания с MySQL 5.1 как DB. Это приложение раньше загружалось хорошо в Tomcat6. В какой-то момент это начало выдавать следующее исключение после КАЖДОЙ начальной загрузки:

- 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

Я должен упомянуть, что это приложение также использует JPA w/Hibernate использующий C3P0 для организации пула подключений источника данных. Это исключение всегда выдается непосредственно после того, как JPA заканчивает обновлять мою схему.

Во-первых, я обновил до Кварца 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.

Ни с чем прибывающим после, и веб-приложение, не обслуживающее запросы; они просто зависают неограниченно долго.

Когда я выполняю mysql клиент командной строки с ШОУ СОСТОЯНИЕ INNODB прямо после исключения, оно действительно последовательно показывает две подозрительных транзакции:

----------
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

Я ищу руководство о том, как далее исследовать эту проблему. Возможно, если я мог бы так или иначе идентифицировать владельцев этих двух транзакций, или какие ресурсы они блокируют?

Обновление: Я удалил все строки в qrtz_simple_triggers таблице без проблемы. Я затем пытался сделать, то же на qrtz_triggers таблице и моем клиенте MySQL бросило "Блокировку, ожидают, тайм-аут превысил" ошибку. В этой точке я остановил мой (все еще зависающий) приложение и затем смог удалить все строки qrtz_triggers таблицы. После того как это было сделано, я смог успешно загрузить свое приложение.

Кажется, что я должен зарегистрировать новую Кварцевую ошибку, но я хотел бы смочь дать им больше информации о том, что на самом деле hapenning здесь. Так, согласно исходному вопросу, как я могу диагностировать эти типы проблем?

9
задан Esteban Küber 19 October 2009 в 02:47
поделиться