问题
I have read the article Locking and Concurrency in Java Persistence 2.0, and run the sample application. But i still cant 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".
回答1:
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
回答2:
One is a read lock and the other is a write lock, or during a read or an update, respectively.
FTA:
PESSIMISTIC_READ. The entity manager locks the entity as soon as a transaction reads it. The lock is held until the transaction completes. This lock mode is used when you want to query data using repeatable-read semantics. In other words, you want to ensure that the data is not updated between successive reads. This lock mode does not block other transactions from reading the data.
PESSIMISTIC_WRITE. The entity manager locks the entity as soon as a transaction updates it. This lock mode forces serialization among transactions attempting to update the entity data. This lock mode is often used when there is a high likelihood of update failure among concurrent updating transactions.
回答3:
The PESSIMISTIC_READ acquires a shared (read) lock on the associated table row record, while the PESSIMISTIC_WRITE acquires an exclusive (write) lock.
The shared lock blocks any other concurrent exclusive lock requests, but it allows other shared lock requests to proceed.
The exclusive lock blocks both shared and exclusive lock requests.
What's worth mentioning is that, for Hibernate, if the database does not support shared locks (e.g. Oracle), then a shared lock request (PESSIMISTIC_READ) will simply acquire an exclusive lock request (PESSIMISTIC_WRITE).
For more details, check out this article about locks and this article about JPA pessimistic lock types.
回答4:
The Spec allows for the JPA implementation to use a different type of database lock for each. Most databases only have one type of declarative lock, so in most implementations the two are identical (there is no difference).
来源：https://stackoverflow.com/questions/1657124/whats-the-difference-between-pessimistic-read-and-pessimistic-write-in-jpa