Menu
I have read the article Locking and Concurrency in Java Persistence 2.0, and run the sample application. But I still can't realize the difference between PESSIMISTIC_READ and PESSIMISTIC_WRITE. I tried to modify the code, and where the code using PESSIMISTIC_READ and PESSIMISTIC_WRITE will have the same result that the SQL will invoked with for update.
998
A lock with LockModeType. PESSIMISTIC_WRITE can be used when querying data and there is a high likelihood of deadlock or update failure among concurrent updating transactions. The persistence implementation must support use of locks of type LockModeType.
Optimistic locking , where a record is locked only when changes are committed to the database. Pessimistic locking , where a record is locked while it is edited.
Pessimistic. Pessimistic locking assumes that concurrent transactions will conflict with each other, and requires resources to be locked after they are read and only unlocked after the application has finished using the data. Hibernate provides mechanisms for implementing both types of locking in your applications.
The difference lies in locking mechanism.
PESSIMISTIC_READ lock means that dirty reads and non-repeatable reads are impossible when you have such a lock. If data should be changed it's required to obtain PESSIMISTIC_WRITE lock
PESSIMISTIC_WRITE lock guarantees that besides dirty and non-repeatable reads are impossible you can update data without obtaining additional locks(and possible deadlocks while waiting for exclusive lock).
╔══════════════════════╦══════════════════════════╦══════════════════════════╗ ║ 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 ║ ╚══════════════════════╩══════════════════════════╩══════════════════════════╝ Resources:
JPA 2.1
61
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
