How is the mechanism of Optimistic Locking implemented and how does it fundamentally differ from other types of locking?

Optimistic Locking is a concurrency control mechanism where no lock is placed in advance. Instead, the system assumes conflicts are rare and allows multiple transactions to work in parallel. Before saving changes, it checks whether the data has been modified since it was read.

How it works:

1. When data is read, a version or checksum (e.g., a version field) is stored.
2. When updating, it checks if the current database version matches the stored one.
3. If versions match, the update proceeds with an increment of the version.
4. If versions differ, it means the data was modified concurrently, and the operation is rolled back or retried.

Differences from other locking types:

• Unlike Pessimistic Locking, which locks data during a transaction, Optimistic Locking does not lock data, increasing concurrency.
• Suitable for systems with low contention, where conflicts are rare.

Example in Java with a version field:

@Entity
public class Product {
    @Id
    private Long id;

    @Version
    private Integer version;

    private String name;
    // getters and setters
}

JPA automatically checks the version during updates and throws an exception if data was changed by another transaction.