What is Record Locking?

Understanding Record Locking

Record locking is a concurrency-control mechanism in databases and file systems that restricts access to a specific record (row) while one user or process is modifying it, preventing others from changing the same data simultaneously. It preserves data integrity in multi-user environments by serializing conflicting operations rather than letting them collide.

Locks come in types and scopes. A shared (read) lock lets multiple transactions read a record but blocks writes; an exclusive (write) lock blocks all other access until released. Locking can be pessimistic, acquiring the lock before editing to guarantee exclusivity, or optimistic, allowing concurrent edits but rejecting a commit if the record changed underneath it (often via a version column). Databases manage locks within transactions following ACID properties and may escalate from row-level to page- or table-level locks. Poorly managed locking can cause deadlocks, where two transactions each wait on the other's locked record.

This matters for security and reliability because uncontrolled concurrent writes cause the "lost update" problem and data corruption, where one user's changes silently overwrite another's. In systems handling financial balances, inventory, or access permissions, that can produce incorrect or inconsistent state with real consequences, double-spent funds, oversold stock, or race conditions that bypass intended checks. Record locking, combined with proper transaction isolation, ensures concurrent operations leave the data in a consistent, predictable state.

For example, two agents try to book the last seat on a flight at the same moment. With pessimistic row locking, the database grants the first transaction an exclusive lock on that seat's record; the second transaction waits until the first commits, then sees the seat is taken and is correctly rejected, preventing a double-booking. With optimistic locking, both read the record, but the second commit fails the version check and is retried against the updated state.