Quartz org.quartz.jobStore.selectWithLockSQL行锁

Question

我在集群模式下使用Quartz

我有一些DB级别的行锁争用，这是由于对以下内容的过多调用引起的：

org.quartz.jobStore.selectWithLockSQL

"SELECT * FROM QRTZ_LOCKS WHERE SCHED_NAME = :"SYS_B_0“和LOCK_NAME = :1用于更新”

我阅读了quartz文档，仍然不是很清楚为什么要执行上面的查询。

使用这个行锁的目的是什么？

问候

Answer 1

当在集群模式下部署时，quartz使用locks表来协调多个调度器。在集群中，只有一个节点应该触发触发器，因此使用锁来避免多个节点获取相同的触发器。

从文档(http://quartz-scheduler.org/generated/2.2.1/html/qs-all/#page/Quartz_Scheduler_Documentation_Set%2Fre-cls_cluster_configuration.html%23)的集群部分：

集群目前只能与JDBC-Jobstore (JobStoreTX或JobStoreCMT)一起使用，基本上是通过让集群中的每个节点共享同一数据库来实现的。负载平衡会自动发生，群集中的每个节点都会尽可能快地触发作业。当触发器的触发时间发生时，获取它的第一个节点(通过在它上放置一个锁)是将触发它的节点。

Answer 2

在我的例子中，我遇到了类似的问题。我使用的是quartz fir运行的作业，这些作业的逻辑涉及从外部数据库获取数据。每当应用程序数据库和外部数据库之间的连接由于某种原因而停止，并且连接恢复时，锁的问题就会浮出水面，我们过去常常在数据库日志中得到这样的消息

2021-01-14 12:06:17.935 KST [46836] STATEMENT:  
SELECT * FROM HVACQRTZ_LOCKS WHERE SCHED_NAME = 'schedulerFactoryBean' AND LOCK_NAME = $1 FOR UPDATE
2021-01-14 12:06:18.937 KST [46836] ERROR:  current transaction is aborted, commands ignored until end of transaction block

为了解决这个问题，我使用了quartz的这个属性，一旦使用了这个属性，这个问题就消失了。默认情况下，foe update部分将出现在查询的末尾，但由于默认查询被我在属性文件中编写的查询替换，for update部分已经消失，现在也没有锁出现，一切似乎都很顺利。

selectWithLockSQL: SELECT * FROM {0}LOCKS  WHERE LOCK_NAME = ?