J'ai une application qui exécute Quartz 1.6.1 w/persistant magasin de travail, avec MySQL 5.1 en tant que DB. Cette application utilisée pour démarrer correctement dans Tomcat6. À un certain moment, il a commencé à jeter l'exception suivante à chaque démarrage:Dépannage cohérent "SQLException: délai d'attente de verrouillage dépassé"
- 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
Je dois mentionner cette application utilise également JPA w/Mise en veille prolongée à l'aide C3P0 pour la mise en commun de connexion à la source de données. Cette exception est toujours lancée directement après la fin de la mise à jour de mon schéma par JPA. Tout d'abord, j'ai mis à niveau vers Quartz 1.6.5 et l'exception a disparu, mais l'application semble figée. La dernière chose dans les journaux - où l'exception utilisé pour être - est:
...hbm2ddl stuff...
2969 [Thread-1] INFO org.hibernate.tool.hbm2ddl.SchemaUpdate - schema update complete
- Handling 6 trigger(s) that missed their scheduled fire-time.
Avec rien venir après, et la webapp ne demande le service; ils pendent indéfiniment.
Quand je lance mysql client en ligne de commande avec MONTRER INNODB STATUT juste après l'exception, il ne montre toujours deux transactions suspectes:
----------
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
Je cherche des conseils sur la façon de plus étudier ce problème. Peut-être pourrais-je identifier les propriétaires de ces deux transactions ou les ressources qu'ils verrouillent?
Mise à jour: J'ai supprimé toutes les lignes de la table qrtz_simple_triggers sans problème. J'ai ensuite essayé de faire la même chose sur la table qrtz_triggers et mon client MySQL a lancé une erreur "Lock wait timeout exceeded". À ce stade, j'ai arrêté mon application (toujours suspendu) et a ensuite été en mesure de supprimer toutes les lignes de la table qrtz_triggers. Une fois cela fait, j'ai réussi à démarrer mon application.
Il semble que je doive enregistrer un nouveau bug Quartz, mais j'aimerais pouvoir leur donner plus d'informations sur ce qui se passe réellement ici. Ainsi, selon la question originale, comment puis-je résoudre ces types de problèmes?