Я прочитал статью Locking и Concurrency в Java Persistence 2.0 и запустил образец приложения. Но я все еще не могу понять разницу между PESSIMISTIC_READ и PESSIMISTIC_WRITE. Я попытался изменить код и где код с использованием PESSIMISTIC_READ и PESSIMISTIC_WRITE будет иметь тот же результат, что и sql будет вызываться с помощью "для обновления".
Какая разница между PESSIMISTIC_READ и PESSIMISTIC_WRITE в JPA?
Ответ 1
Разница заключается в механизме блокировки.
PESSIMISTIC_READ Блокировка означает, что грязные чтения и неповторяющиеся чтения невозможны, когда у вас есть такая блокировка. Если данные должны быть изменены, требуется получить PESSIMISTIC_WRITE lock
PESSIMISTIC_WRITE гарантирует, что, кроме грязных и не повторяющихся считываний, невозможно обновить данные, не получая дополнительных блокировок (и возможно deadlocks в ожидании исключительной блокировки).
╔══════════════════════╦══════════════════════════╦══════════════════════════╗
║ LockModeType ║ PESSIMISTIC_READ ║ PESSIMISTIC_WRITE ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ type ║ SHARED LOCK ║ EXCLUSIVE LOCK ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ isReadOnly without ║ ║ ║
║ additional locks ║ YES ║ NO ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ dirty reads ║ NO ║ NO ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ non-repeatable reads ║ NO ║ NO ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ how to update data ║ obtain PESSIMISTIC_WRITE ║ ALLOWED ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ ║ no one holds ║ no one holds ║
║ how to obtain lock ║ PESSIMISTIC_WRITE ║ PESSIMISTIC_READ or ║
║ ║ ║ PESSIMISTIC_WRITE ║
╠══════════════════════╬══════════════════════════╬══════════════════════════╣
║ ║ ║ when there is a high ║
║ ║ you want to ensure no ║ likelihood of deadlock or║
║ when to use ║ dirty or non-repeatable ║ update failure among ║
║ ║ reads are possible ║ concurrent updating ║
║ ║ ║ transactions ║
╚══════════════════════╩══════════════════════════╩══════════════════════════╝
Ресурсы
Ответ 2
Один - это блокировка чтения, а другая - блокировка записи или во время чтения или обновления соответственно.
FTA:
-
PESSIMISTIC_READ. Менеджер сущности блокирует объект, как только транзакция читает его. Блокировка пока транзакция не завершится. Этот режим блокировки используется, когда вы хотите запрашивать данные с помощью считывания с возможностью повторного чтения семантика. Другими словами, вы хотите чтобы данные не были обновляется между последовательными чтениями. Этот режим блокировки не блокирует другие транзакции от чтения данных.
PESSIMISTIC_WRITE. Менеджер сущности блокирует объект, как только транзакция обновляет его. Этот замок режим заставляет сериализовать транзакции, пытающиеся обновить данные сущности. Этот режим блокировки часто используется, когда существует высокая вероятность ошибки обновления при одновременном обновление транзакций.
Ответ 3
Спецификация позволяет реализации JPA использовать для каждого типа блокировки базы данных другого типа. Большинство баз данных имеют только один тип декларативной блокировки, поэтому в большинстве реализаций два идентичны (нет разницы).
Ответ 4
PESSIMISTIC_READ получает общую (прочитанную) блокировку в соответствующей записи строки таблицы, в то время как PESSIMISTIC_WRITE получает блокировку (запись).
Общая блокировка блокирует любые другие одновременные исключительные запросы блокировки, но позволяет выполнять другие общие запросы блокировки.
Исключительная блокировка блокирует как общие, так и эксклюзивные запросы блокировки.
Следует отметить, что для Hibernate, если база данных не поддерживает общие блокировки (например, Oracle), тогда общий запрос блокировки (PESSIMISTIC_READ) просто получит эксклюзивный запрос блокировки (PESSIMISTIC_WRITE).
Для получения дополнительной информации ознакомьтесь с этой статьей о блокировках и в этой статье о пессимистичных типах блокировки JPA.