Question

我在群集模式下使用Quartz

由于过度调用导致数据库级别出现行锁定争用：

org.quartz.jobStore.selectWithLockSQL

＆＃34; SELECT * FROM QRTZ_LOCKS WHERE SCHED_NAME =：＆＃34; SYS_B_0＆＃34; AND LOCK_NAME =：1 FOR FORDDATE＆＃34;

我阅读了石英文档，但我仍然不清楚为什么执行上面的查询。

拥有此行锁的目的是什么？

此致

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），基本上通过拥有集群的每个节点来工作共享同一个数据库。负载平衡自动发生群集的每个节点都尽可能快地触发作业。 当a 触发器的触发时间发生，第一个节点获取它（通过放置它上面的锁是一个会触发它的节点。

Answer 2

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

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

为了解决这个问题，我使用了石英的这个属性，一旦使用了这个属性，问题就消失了。默认情况下，敌人更新部分将在查询结束时出现，但由于默认查询被我在属性文件中编写的查询替换，因此更新部分消失了，现在没有锁出现，一切似乎都在工作顺利。

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

Quartz org.quartz.jobStore.selectWithLockSQL行锁

2 个答案: