Locking

Locking ensures data consistency when multiple transactions or users access the same database row or entity at the same time. It prevents lost updates, dirty reads, and non-repeatable reads, which are critical in high-concurrency applications.

What is Locking?

Locking is a mechanism used in databases and ORM frameworks like Hibernate / JPA to control concurrent access to data.

When multiple transactions or users try to read or modify the same data at the same time, locking ensures that:

• Data consistency is maintained
• Lost updates are prevented
• Dirty reads and non-repeatable reads are avoided

In simple words:

Locking ensures that only authorized transactions can modify or read data at a time, preventing conflicts and maintaining integrity in a multi-user environment.

Example Scenario

Two users try to update a product stock:

• Optimistic Locking → One transaction fails with an exception; it can retry
• Pessimistic Locking → Second transaction waits until the first transaction completes

Locking ensures that only one update succeeds, or conflicts are handled gracefully.

Why Locking Is Important

• Prevents lost updates when multiple transactions update the same entity
• Ensures data consistency and integrity
• Avoids dirty reads and non-repeatable reads
• Critical for multi-user or high-concurrency applications

Types of Locking

Hibernate and JPA support two main types of locking:

1. Optimistic Locking

• Assumes conflicts are rare
• Does not lock rows in the database
• Uses a version field (@Version) or timestamp to detect conflicts
• If a conflict occurs, Hibernate/JPA throws an OptimisticLockException / StaleObjectStateException

How It Works:

• Each entity has a version column
• Before committing, the version is checked
• If the version in DB differs → transaction fails

Example:

@Entity
publicclassProduct {

@Id
@GeneratedValue
private Long id;

private String name;
privateint stock;

@Version
privateint version;
}

• Optimistic locking is ideal for read-heavy applications
• One transaction failing due to a version mismatch can retry safely

2. Pessimistic Locking

• Assumes conflicts are likely
• Locks the database row immediately during read or update
• Prevents other transactions from modifying the entity until the lock is released

Lock Modes in Hibernate / JPA:

Hibernate Example

Productproduct= session.get(Product.class,1L, LockMode.PESSIMISTIC_WRITE);

• Acquires an exclusive lock on the product row.
• Other transactions cannot read or write this row until the lock is released.

Spring Data JPA Example

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

• Locks the entity at the database level during the query execution.
• Ensures critical updates are not conflicted by other transactions.

Optimistic Locking vs Pessimistic Locking

Best Practices

• Use optimistic locking by default (less blocking, better concurrency)
• Use pessimistic locking when updates are frequent or conflicts are likely
• Always handle OptimisticLockException / StaleObjectStateException gracefully
• Keep transactions short-lived to avoid blocking other users
• Monitor for deadlocks when using pessimistic locks

Conclusion

Locking in Hibernate and Spring Data JPA is essential for safe concurrent access and data integrity:

• Optimistic locking → Best for read-heavy apps, avoids unnecessary DB locks
• Pessimistic locking → Ensures strict consistency in write-heavy or critical scenarios