Concurrency Control Techniques: Meaning, Goals, and Core Methods

Concurrency control techniques are strategies used in transaction processing systems to ensure that when multiple transactions run at the same time, the database remains correct—typically meaning the final outcome is equivalent to some serial execution (usually serializability). This is necessary because interleaving operations from different transactions can produce anomalies such as lost updates, dirty reads, non-repeatable reads, and phantoms.

At a high level, concurrency control addresses three questions:

1. What correctness notion? (e.g., conflict/view serializability)
2. What information is available at runtime? (read/write tracking, timestamps, lock states)
3. What mechanism enforces the correctness? (locking, timestamps, optimistic validation, or hybrids)

The canonical “families” of techniques are:

• Lock-based concurrency control
• Timestamp ordering concurrency control
• Optimistic concurrency control
• [Multiversion concurrency control (MVCC)]{def="Stores multiple versions so readers don’t block writers}

A typical way to visualize the relationship is: concurrency control mechanisms try to restrict the schedule so that only serializable histories (or an even stronger property) can occur, while still supporting performance goals such as throughput and reduced waiting.

Note: In practice, systems may implement stricter or different guarantees (e.g., snapshot isolation), but the underlying meaning of “concurrency control techniques” is always about preventing harmful interleavings and preserving correctness guarantees.

Key concepts you must know first (so “concurrency control” is precise)

Transaction schedules represent the actual interleavings produced at runtime. Concurrency control techniques are then designed so that the schedule avoids problematic patterns and conforms to a defined correctness criterion like serializability.

1) Correctness target: serializability

A schedule is conflict-serializable if its conflicting operations can be rearranged into a serial order without changing the effect. This is often operationalized via conflict graphs derived from reads/writes.

2) Conflicts: where concurrency breaks correctness

Conflicts arise specifically around operations on the same data items:

• R/W conflicts: one transaction reads a value another transaction writes
• W/W conflicts: two writes on the same item, where ordering affects the final value
• W/R conflicts: symmetric cases of R/W ordering

Concurrency control “techniques” are, in essence, systematic policies to prevent or detect the existence of these harmful interleavings.

Representative technique families (what they mean, and what they do)

Lock-based techniques

Locking restricts concurrent execution by forcing transactions to acquire locks on data items. The primary correctness idea is that conflicts are serialized through lock ownership.

Common variants include:

• Two-phase locking and its stronger forms
• Deadlock handling via detection/prevention policies

Timestamp-based techniques

Timestamp ordering assigns each transaction a timestamp. Reads/writes are then allowed only if they respect the timestamp order; otherwise operations are rejected or transactions are restarted.

This turns concurrency control into an ordering problem: the system maintains which transaction is “allowed” to affect a particular data item based on timestamps.

Optimistic concurrency control (OCC)

Optimistic concurrency control assumes conflicts are rare. Transactions proceed without strict blocking, and at commit time the system checks whether the interleaving produced a conflict. If validation fails, the transaction aborts.

Typical OCC includes:

• A read phase and write phase where reads/writes are recorded
• A validation phase that checks whether the observed dependencies are still consistent with a serializable order

MVCC (multiversion concurrency control)

Multiversion concurrency control (MVCC) allows readers to view stable versions while writers proceed. This reduces read-write blocking and can improve throughput, especially for read-heavy workloads.

Conceptually, MVCC implements a form of “concurrency via versioning,” not by blocking. The system still provides a defined isolation guarantee (often snapshot-like behavior).