Pessimistic locking acquires an actual database-level lock on a row at the moment it's read (via `LockModeType.PESSIMISTIC_READ` or `PESSIMISTIC_WRITE`), preventing other transactions from reading (for WRITE locks) or modifying the same row until the lock is released at transaction end — guaranteeing no conflicting concurrent update can happen at all, at the cost of reduced concurrency since competing transactions must wait. It's preferred when conflicts are expected to be frequent, or when the cost of a failed/retried optimistic update is unacceptable (e.g., a financial balance deduction where a lost-update retry is operationally awkward).

Advanced7 min

AmazonGoogleMicrosoftFlipkartOracleAdobe

#Pessimistic Locking#LockModeType

What is pessimistic locking, and when would you choose it over optimistic locking?

Pessimistic Locks Held Too Long Are a Classic Source of Deadlocks and Throughput Collapse

Because a pessimistic lock is held for the entire duration of the transaction, a slow transaction (one making an external API call, or simply poorly structured with a lock acquired early and released late) can cause every other transaction wanting that same row to queue up and wait — under real load, this can cascade into severe throughput degradation or even deadlocks if multiple transactions acquire locks on different rows in inconsistent orders.

Pessimistic Locking Query

java

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT p FROM Product p WHERE p.id = :id")
Product findByIdForUpdate(@Param("id") Long id);