Quartz在执行Select for update时被阻塞

Question

我有一个大型应用程序，其中4个节点使用quartz调度作业。

我经常收到来自我们数据库团队的邮件，内容是：

'SELECT * FROM QRTZ_LOCKS WHERE LOCK_NAME='TRIGGER_ACCESS' FOR UPDATE'

这个操作会阻塞15-20分钟，有时甚至几个小时。我发现我的作业也被锁住了，无法执行。

我们正在使用相当老的Quartz 1.8.3版本。以下是我正在使用的Quartz设置。

org.quartz.scheduler.instanceName = DefaultQuartzScheduler
org.quartz.scheduler.instanceId = AUTO
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 25
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

org.quartz.jobStore.misfireThreshold = 60000

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT

org.quartz.jobStore.driverDelegateClass=com.xyx.abc.common.scheduler.impl.CDAJDBCDelegate
org.quartz.jobStore.useProperties=false
org.quartz.jobStore.tablePrefix=QRTZ_
org.quartz.jobStore.isClustered=true
org.quartz.jobStore.clusterCheckinInterval = 20000

# these 3 are required by customSchedulerFactory class
org.quartz.dataSource.myDS.connectionProvider.class=com.xyz.abc.common.scheduler.impl.CustomPoolingConnectionProvider
org.quartz.jobStore.dataSource=myDS
org.quartz.jobStore.nonManagedTXDataSource=myDS

我尝试启用Quartz的调试日志，但是没有得到很多信息。

有人遇到过类似的问题吗？如何确保“Select for update”查询执行快速？

- Javadroider

---

SELECT FOR UPDATE 查询会锁定 QRTZ_LOCKS 表中的行，因此如果在该表中有相同行的并发 SELECT FOR UPDATE 查询，则这些并发查询将等待第一个 SELECT FOR UPDATE 查询在执行之前通过提交或回滚释放这些行上的锁定。 - ivanzg

同意@ivanzg的观点。你的问题不在于Quartz，看起来是数据库锁的问题。 - Andriy Rymar

这个问题解决了吗？ - phoenixSid

Answer 1

你可以忽略这些查询。

很多年前，我曾经处于这个问题的另一面。我是数据库团队中的那个人，发现了一个长时间运行的查询，并要求Java开发人员修复它。我记不清细节了，但我记得有一个很好的解释，说明为什么它以这种方式工作，而且没有任何需要修复的东西。

当我们按GV$SQL.ELAPSED_TIME降序排序时，这些查询总是出现在性能报告中。但仔细检查后，我们发现它们并没有使用任何重要的资源。它们没有使用CPU、I/O或任何其他宝贵的资源。这是ELAPSED_TIME列误导人的罕见时刻之一。

我学会了忽略它们，去关注其他查询。

- Jon Heller