Почему мой пессимистический Блокировка в JPA с Oracle не работает

Я пытаюсь реализовать какие-то семафоры для заданий cron, которые работают в разных узлах JBoss. Я пытаюсь использовать базу данных (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? Спасибо заранее.

Ответ 1

Наконец, мне удалось заставить его работать, но с некоторыми модификациями. Идея заключается в использовании LockModeType.PESSIMISTIC_FORCE_INCREMENT вместо PESSIMISTIC_WRITE. Используя этот режим блокировки, Cron Jobs ведут себя следующим образом:

Когда первое задание делает выбор для обновления, все идет так, как ожидалось, но изменяется версия на объекте.
Если другое задание пытается сделать тот же самый выбор, пока первый все еще находится в транзакции, JPA запускает исключение OptimisticLockException, поэтому, если вы поймаете это исключение, вы можете быть уверены, что оно было брошено для блокировки чтения.

Это решение имеет разные копии:

SynchronizedCronJobTask должен иметь поле версии и находиться под управлением версии с помощью @Version
Вам нужно обработать исключение OptimisticLockException, и оно должно быть уловлено вне метода транзакционной службы, чтобы выполнить откат при блокировке.
IMHO - это не элегантное решение, намного хуже, чем просто блокировка, где Cron Jobs ждут завершения предыдущих Рабочих дней.

Ответ 2

Установите режим блокировки на PESSIMISTIC_READ, потому что вам нужен, чтобы второй сервер знал об изменениях первого сервера перед изменением данных.