Физическая блокировка строк БД, полученная из блокировки JPA PESSIMISTIC

Согласно спецификации JPA 2.1...

Режимы блокировки PESSIMISTIC_READ, PESSIMISTIC_WRITE и PESSIMISTIC_FORCE_INCREMENT используются для немедленного получения долгосрочных блокировок базы данных.

Я предполагаю, что пессимистическая блокировка всегда будет запускать SELECT ... FOR UPDATE SQL в базе данных, независимо от того, какой режим блокировки используется. Теперь три вопроса по этому поводу:

  1. Верно ли предположение или есть исключения из этого правила, если оно верно?
  2. Учитывая SELECT ... FOR UPDATE, заблокированы строки. Заблокированные строки не могут быть обновлены какой-либо другой транзакцией, кроме транзакции, которая их заблокировала?
  3. Блокировку можно снять, выполнив фиксацию или откат транзакции. Что произойдет с блокировкой, если приложение (и транзакция, которая заблокировала строки) внезапно завершится без фиксации или отката транзакции?

mysql postgresql concurrency jpa pessimistic-locking
person mika    schedule 05.01.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Для вопросов 1 и 2 ваши предположения верны:

  1. Да — пессимистическая блокировка обычно использует SELECT ... FOR UPDATE, так как большинство баз данных и реализаций JPA поддерживают только этот тип блокировки. В этом случае нет никакой разницы между блоками READ и WRITE, и спецификация JPA разрешает это до тех пор, пока оба ведут себя как блокировки WRITE.

  2. Да — заблокированные строки не могут быть изменены какой-либо другой транзакцией. В случае блокировки WRITE (и в большинстве случаев также для блокировки READ - ответ для 1), заблокированные строки также не могут быть прочитаны до тех пор, пока блокировка не будет снята. Обратите внимание, что другие разблокированные строки в той же таблице можно свободно читать и изменять.

Чтобы ответить также на вопрос 3:

  1. Да — блокировки снимаются в случае фиксации или отката. Однако откат также происходит автоматически, когда происходит ошибка, разрыв соединения или транзакция занимает слишком много времени. Таким образом, когда приложение умирает, немедленно срабатывает откат. Если нет, он откатывается через некоторое время (обычно 5 минут).
person OndroMih    schedule 06.01.2016
comment
Спасибо! Что касается третьего ответа, я полагаю, что откат блокировки является функцией базовой СУБД? Можем ли мы положиться на него для всех СУБД (больших, mysql, postgres, orcale, db2..)? - person mika; 06.01.2016
comment
Да, откат запускается СУБД при разрыве соединения. Я думаю, что это довольно стандартное поведение при обработке ошибок, иначе транзакция останется открытой навсегда. Я бы положился на это, хотя я бы сделал несколько простых тестов, чтобы убедиться в этом, так как может быть проблема/ошибка в конкретной СУБД. - person OndroMih; 06.01.2016
comment
Я хочу знать, что после получения ответа я также не хотел снимать блокировку в течение следующих 10 минут (некоторые бизнес-требования). Можно ли каким-либо образом использовать эту персимистическую блокировку? - person Neha Gour; 02.02.2020
comment
Пессимистическая блокировка существует для предотвращения конфликтного доступа к БД. Как только транзакция фиксируется, блокировка снимается. JPA не предоставляет ничего сверх этого. Возможно, ваша база данных поддерживает SQL, который создаст блокировку, которая будет снята через 10 минут, но это не поддерживается в JPA. - person OndroMih; 07.02.2020