Locking: Optimistic & Pessimistic

Optimistic locking detects conflicts at commit time using a version column and retries on failure, while pessimistic locking prevents conflicts by acquiring a database row lock upfront and making others wait.

When many concurrent writers target the same row (high contention), pessimistic locking avoids retry storms; when conflicts are rare (low contention), optimistic locking maximizes throughput without holding locks.

@Version adds a WHERE version=? predicate to every UPDATE so that zero rows affected means a concurrent change, and the standard remedy is a bounded retry that reloads the entity in a fresh transaction.

@Lock on a Spring Data repository method sets the LockModeType per query, with PESSIMISTIC_WRITE for exclusive row locks and PESSIMISTIC_READ for shared locks, chosen when contention is high enough that optimistic retries waste more than pessimistic waiting.