为什么我对使用Oracle的JPA中的悲观锁定无法正常工作

Question

我正在尝试为在不同JBoss节点中运行的cron作业实现某种信号量.我正在尝试使用数据库(Oracle 11g)作为锁定机制,使用一个表来同步不同节点中的cron作业.表非常简单:

CREATE TABLE SYNCHRONIZED_CRON_JOB_TASK
(
   ID            NUMBER(10)           NOT NULL,
   CRONJOBTYPE   VARCHAR2(255 Byte),
   CREATIONDATE  TIMESTAMP(6)         NOT NULL,
   RUNNING       NUMBER(1)
);

ALTER TABLE SYNCHRONIZED_CRON_JOB_TASK
   ADD CONSTRAINT PK_SYNCHRONIZED_CRON_JOB_TASK
   PRIMARY KEY (ID); 

因此,当作业启动时,它会在表中搜索其cronjobtype的条目,并检查它是否已在运行.如果不是,则将条目设置运行标志更新为true.第一个选择是使用JPA CriteriaApi使用Hibernate和Pessimistic Lock进行的.

query.setLockMode(javax.persistence.LockModeType.PESSIMISTIC_WRITE);

所有这些操作都是在一次交易中完成的.

当一个进程运行时,它所做的查询如下:

[Server:server-two] 10:38:00,049 INFO  [stdout] (scheduler-2) 2015-04-30 10:38:00,048 WARN  (Loader.java:264) - HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
[Server:server-two] 10:38:00,049 INFO  [stdout] (scheduler-2) Hibernate: select * from ( select distinct synchroniz0_.id as id1_127_, synchroniz0_.creationDate as creation2_127_, synchroniz0_.running as running3_127_, synchroniz0_.CRONJOBTYPE as CRONJOBT4_127_ from SYNCHRONIZED_CRON_JOB_TASK synchroniz0_ where synchroniz0_.CRONJOBTYPE=? ) where rownum <= ?
[Server:server-two] 10:38:00,053 INFO  [stdout] (scheduler-2) Hibernate: select id from SYNCHRONIZED_CRON_JOB_TASK where id =? for update
[Server:server-two] 10:38:00,056 INFO  [stdout] (scheduler-2) Hibernate: update SYNCHRONIZED_CRON_JOB_TASK set creationDate=?, running=?, CRONJOBTYPE=? where id=?

此警告没有问题,您可以看到第一个选择然后选择更新,因此Oracle应该阻止此行上的其他选择操作.但这就是重点,查询不会被阻止,因此两个作业可以进入并进行选择和更新而不会出现问题.锁不起作用,如果我们同时运行两个cron作业,我们可以看到它:

[Server:server-one] 10:38:00,008 INFO  [stdout] (scheduler-3) 2015-04-30 10:38:00,008 WARN  (Loader.java:264) - HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
[Server:server-two] 10:38:00,008 INFO  [stdout] (scheduler-2) 2015-04-30 10:38:00,008 WARN  (Loader.java:264) - HHH000444: Encountered request for locking however dialect reports that database prefers locking be done in a separate select (follow-on locking); results will be locked after initial query executes
[Server:server-two] 10:38:00,009 INFO  [stdout] (scheduler-2) Hibernate: select * from ( select distinct synchroniz0_.id as id1_127_, synchroniz0_.creationDate as creation2_127_, synchroniz0_.running as running3_127_, synchroniz0_.CRONJOBTYPE as CRONJOBT4_127_ from SYNCHRONIZED_CRON_JOB_TASK synchroniz0_ where synchroniz0_.CRONJOBTYPE=? ) where rownum <= ?
[Server:server-one] 10:38:00,009 INFO  [stdout] (scheduler-3) Hibernate: select * from ( select distinct synchroniz0_.id as id1_127_, synchroniz0_.creationDate as creation2_127_, synchroniz0_.running as running3_127_, synchroniz0_.CRONJOBTYPE as CRONJOBT4_127_ from SYNCHRONIZED_CRON_JOB_TASK synchroniz0_ where synchroniz0_.CRONJOBTYPE=? ) where rownum <= ?
[Server:server-two] 10:38:00,013 INFO  [stdout] (scheduler-2) Hibernate: select id from SYNCHRONIZED_CRON_JOB_TASK where id =? for update
[Server:server-one] 10:38:00,014 INFO  [stdout] (scheduler-3) Hibernate: select id from SYNCHRONIZED_CRON_JOB_TASK where id =? for update
[Server:server-two] 10:38:00,016 INFO  [stdout] (scheduler-2) 2015-04-30 10:38:00,015 DEBUG (SynchronizedCronJobService.java:65) - Task read SynchronizedCronJobTask [id=185, type=AlertMailTaskExecutor, creationDate=2015-04-25 07:11:33.0, running=false]
[Server:server-two] 10:38:00,018 INFO  [stdout] (scheduler-2) Hibernate: update SYNCHRONIZED_CRON_JOB_TASK set creationDate=?, running=?, CRONJOBTYPE=? where id=?
[Server:server-one] 10:38:00,022 INFO  [stdout] (scheduler-3) 2015-04-30 10:38:00,022 DEBUG (SynchronizedCronJobService.java:65) - Task read SynchronizedCronJobTask [id=185, type=AlertMailTaskExecutor, creationDate=2015-04-25 07:11:33.0, running=false]
[Server:server-one] 10:38:00,024 INFO  [stdout] (scheduler-3) Hibernate: update SYNCHRONIZED_CRON_JOB_TASK set creationDate=?, running=?, CRONJOBTYPE=? where id=?

我试图通过两个连接在SQL工具(SQLWorkbenchJ)上进行此选择以进行更新,并且此工具中的bloking工作正常.但是如果我在SQL工具上选择更新并启动cron作业,那么它们就不会运行并且运行没有问题.

我认为问题来自JPA,Hibernate或Oracle驱动程序,但我不确定.有什么问题在哪里？我应该使用anotehr策略吗？提前致谢.

Answer 1

最后我设法让它工作，但做了一些修改。这个想法是使用 LockModeType.PESSIMISTIC_FORCE_INCRMENT 而不是 PESSIMISTIC_WRITE。使用此锁定模式，Cron 作业的行为如下：

1. 当第一个作业选择更新时，一切都会按预期进行，但对象的版本会发生变化。
2. 如果另一个作业尝试在第一个作业仍在其事务中时进行相同的选择，JPA 将启动 OptimisticLockException，因此如果您捕获该异常，则可以确定它是因读锁定而引发的。

该解决方案有多种对应方案：

1. SynchronizedCronJobTask 必须有版本字段并受@Version 的版本控制
2. 您需要处理 OptimisticLockException，并且应该在事务服务方法之外捕获它，以便在发生解锁时进行回滚。
3. 恕我直言，这是一个不优雅的解决方案，比简单的 Cron 作业等待先前作业完成的锁更糟糕。