我们有一个使用Quartz安排某项工作的应用程序。它使用JDBCJobstore来保存与作业相关的元数据。
到目前为止,它一直在使用在quartz.properties中定义的数据源。但根据即将到来的要求,我们计划从quartz.properties中移出数据源,并将其作为SchedulerFactoryBean数据源属性的一部分提供。
org.springframework.scheduling.quartz.SchedulerFactoryBean
根据SchedulerFactoryBean documentation:
使用持久性作业时,强烈建议在Spring管理(或纯JTA)事务中对Scheduler执行所有操作。否则,数据库锁定将无法正常工作,甚至可能会中断
及其数据源属性docs说:
因此强烈建议在Spring管理(或普通JTA)事务中对Scheduler执行所有操作。否则,数据库锁定将无法正常工作,甚至可能会中断
嗯,就我而言,它正在打破。 “在Spring管理(或普通JTA)事务中对调度程序执行所有操作”的文档究竟是什么意思。
我们提供的数据源未在其他任何地方使用。 Quartz.properties看起来像这样:
org.quartz.scheduler.instanceName = JobScheduler
org.quartz.scheduler.instanceId = pcmlScheduler
org.quartz.plugin.shutdownHook.class=org.quartz.plugins.management.ShutdownHookPlugin
org.quartz.plugin.shutdownHook.cleanShutdown = true
org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 2
org.quartz.threadPool.threadPriority = 4
org.quartz.jobStore.misfireThreshold = 5000
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.tablePrefix = QRTZ_
如果我能得到一个上下文究竟是什么交易引用我可以进一步调低数据库锁BreaK:
Failure obtaining db row lock: No row exists in table QRTZ_LOCKS for lock named: TRIGGER_ACCESS [See nested exception: java.sql.SQLException: No row exists in table QRTZ_LOCKS for lock named: TRIGGER_ACCESS]
QRTZ_LOCKS确实没有任何行,但它应该是石英头痛来管理它。它管理得很好,在quartz.properties中提供数据源时工作正常。
更新: 来自quartz forum,得到了这个问题的副本,根据建议,将以下行添加到QRTZ_LOCKS中解决问题。
INSERT INTO QRTZ_LOCKS values('TRIGGER_ACCESS');
INSERT INTO QRTZ_LOCKS values('JOB_ACCESS');
INSERT INTO QRTZ_LOCKS values('CALENDAR_ACCESS');
INSERT INTO QRTZ_LOCKS values('STATE_ACCESS');
INSERT INTO QRTZ_LOCKS values('MISFIRE_ACCESS');
我不是多么可靠,但它确实有效。有趣的观察是,当提供数据源作为部分quary.properties时,它并不期望这些行。但是提供数据源作为part schedulerFactoryBean,它需要这些(可能)。理想情况下,即使需要它,也应该由石英本身照顾。
需要来自石英内部人/用户的一些专家评论。