What is pessimistic locking in JPA and when would you use it instead of Serializable isolation?

Pessimistic locking in JPA is a strategy to prevent concurrent modifications to data by acquiring a lock on an entity before performing an operation. It ensures data consistency in highly concurrent environments by making sure that only one transaction can modify a piece of data at a time, or read it with the intent to modify, reflecting a "fail-fast" approach to concurrency.

What is Pessimistic Locking?

Pessimistic locking is a concurrency control mechanism where a lock is obtained on a resource (e.g., a database row) at the beginning of a transaction or operation. This lock prevents other transactions from accessing or modifying the resource until the current transaction releases the lock. The name 'pessimistic' comes from the assumption that conflicts are likely to occur, so it's better to prevent them upfront.

In JPA, pessimistic locks are managed using LockModeType. The primary modes are PESSIMISTIC_READ and PESSIMISTIC_WRITE. PESSIMISTIC_READ acquires a shared lock, allowing other transactions to read the data concurrently but preventing them from writing. PESSIMISTIC_WRITE acquires an exclusive lock, preventing both reads and writes by other transactions until the lock is released.

These locks are typically implemented by the underlying database using row-level locks. For example, a PESSIMISTIC_WRITE lock often translates to a SELECT ... FOR UPDATE SQL statement, which locks the selected rows for the duration of the transaction.

When to Use Pessimistic Locking

Pessimistic locking is best suited for scenarios where data consistency is absolutely critical, and the likelihood of concurrent modification (contention) on specific data is high. It's preferred when potential conflicts are frequent and must be prevented proactively, rather than detected and resolved retroactively (as with optimistic locking).

• High contention on specific entities or rows, such as inventory counts, financial balances, or unique identifiers.
• Preventing 'lost updates' and 'dirty reads' at a fine-grained, application-managed level.
• Critical business transactions where even temporary inconsistencies are unacceptable (e.g., withdrawing money, reserving a seat).
• When an optimistic locking failure (e.g., OptimisticLockException) and subsequent retries are not a viable or acceptable strategy due to business logic complexity or user experience.

Pessimistic Locking vs. Serializable Isolation

Serializable is the highest isolation level in transactional databases, guaranteeing that concurrent transactions produce the same results as if they were executed sequentially. It prevents all concurrency anomalies, including dirty reads, non-repeatable reads, phantom reads, and lost updates, by enforcing strict locking or versioning at the database level across the entire transaction.

You would choose pessimistic locking when you need precise control over concurrency for specific entities within your application, and you want to avoid the performance overhead of a global Serializable isolation level across your entire database transaction. Serializable isolation is generally reserved for the most stringent consistency requirements where the performance cost is acceptable, or the architectural complexity of fine-grained application-level locking is too high.

JPA Example

import jakarta.persistence.EntityManager;
import jakarta.persistence.LockModeType;
import jakarta.persistence.PersistenceContext;
import jakarta.transaction.Transactional;

public class ProductService {

    @PersistenceContext
    private EntityManager em;

    @Transactional
    public void decreaseProductStock(Long productId, int quantity) {
        // Acquire a PESSIMISTIC_WRITE lock on the product row
        // Other transactions attempting to write or read this row will be blocked.
        Product product = em.find(Product.class, productId, LockModeType.PESSIMISTIC_WRITE);

        if (product == null) {
            throw new IllegalArgumentException("Product not found.");
        }

        if (product.getStock() < quantity) {
            throw new IllegalStateException("Insufficient stock for product " + productId);
        }

        product.setStock(product.getStock() - quantity);
        // Changes will be flushed to the database and the lock released upon transaction commit.
    }
}