Pessimistic concurrency
A concurrency strategy that assumes conflicts are likely and therefore locks data up front (e.g. SELECT ... FOR UPDATE), making other transactions wait. "Lock first, work later" — the opposite of optimistic concurrency.
Mechanic: before a transaction changes data, it takes a lock on the rows; others wanting to touch the same rows are blocked until the lock is released (at commit/rollback). Win: it guarantees no one else changes the data while you work → no surprises, no "lost update", predictable. Price: lower concurrency (waiting), risk of deadlocks, and a poor fit when conflicts are actually rare (then you waste locks). Best when conflicts are common and it's expensive to redo work (e.g. a bank balance with high contention). The opposite — optimistic concurrency — lets everyone run freely and detects conflict only at commit (version checking / serialization failure), better when conflicts are rare. The choice depends on the conflict rate. Related to deadlock detection and serialization failure.