Does serializable mean one transaction runs at a time?

No. Operations can overlap while the committed outcome remains equivalent to a serial execution.

Does two-phase commit solve all concurrency conflicts?

No. It coordinates the commit or abort outcome across participants. Appropriate isolation and conflict handling are still required.

Are transaction retries necessarily a defect?

No. Aborting a conflicting attempt can be part of preserving isolation. Excessive retries may nevertheless signal contention or transaction-design problems.

AI Glossary / Data engineering and architecture / Advanced

Distributed concurrency control

Definition

Distributed concurrency control coordinates overlapping operations or transactions on data managed across multiple networked nodes. Its purpose is to enforce the system's chosen isolation guarantees despite concurrent access, message delays and the division of data or replicas among locations.

What it means

Two users can make individually sensible decisions that conflict when combined. For example, each may reserve capacity after reading a value that another transaction is about to change. Distribution makes the coordination harder because no node necessarily sees every relevant operation immediately.

A common target is serializability: the combined effect of committed transactions must correspond to some execution in which those transactions ran one after another. This does not require physically executing everything sequentially. It requires the concurrent result to respect that model.

Other isolation levels permit more behaviors, so the selected guarantee matters. Local correctness at each participating database is not enough unless the overall protocol establishes the required global ordering. Likewise, atomic commitment and concurrency control address related but different questions: whether a transaction takes effect across participants, and how it interacts with other transactions.

How it works

The system identifies conflicts involving reads and writes. Locking approaches delay operations until compatible access is possible. Timestamp approaches use an ordering associated with transactions or versions. Optimistic approaches allow work to proceed and validate whether it can commit safely. Real systems may combine these ideas.

Across nodes, these decisions require communication or carefully designed ownership and ordering rules. Multiple versions can let readers access suitable historical values while updates proceed, but versioning alone does not guarantee serializability. The protocol must detect or prevent the relevant dependencies.

Conflicts may cause waiting or aborts followed by retries. A distributed deadlock can involve transactions waiting on locks at different nodes, even though no one local view shows the full cycle. Failure recovery and commit coordination must preserve the promises already made. Application code must also respect the transaction boundary rather than performing important checks outside it.

Three practical examples

A booking service coordinates reservations spanning inventory partitions so competing transactions cannot both rely on incompatible capacity assumptions.
A distributed database checks whether overlapping updates can commit under its configured isolation level and asks the application to retry when necessary.
A reporting application requests a defined transactional view across records rather than combining unrelated reads that may reflect different update stages.

Think of it this way

Think of several branch offices using a shared reservation policy. Each office may handle its own desk efficiently, but a booking spanning branches needs rules that prevent the offices from accepting incompatible commitments.

The analogy is limited: databases implement precise operations, dependencies and recovery protocols rather than relying on informal telephone agreement. It illustrates why coordinating each desk separately does not automatically coordinate the complete reservation.

Worked example

Consider a fictional facility with two emergency support rooms, A and B, stored on different nodes. Each is initially available, represented by 1. A rule requires at least one room to remain available.

Transaction T1 reads A=1 and B=1, then marks A unavailable. Concurrent transaction T2 reads the same original values and marks B unavailable. If both commit solely because they wrote different records, the final values are A=0 and B=0, violating the rule. This is a write-skew pattern.

In any serial execution of these transactions, the second transaction would see that only one room remained and decline its change. Serializable concurrency control must therefore prevent this combined committed history, for example by blocking or aborting a conflicting transaction. The example assumes both reads and the conditional update are inside each transaction; an external check would change the assurance boundary.

Illustrative case study

Fictional case: a maintenance platform distributes equipment records by site. A new scheduling feature checks two sites before taking a shared backup resource offline. Tests with one user pass, but concurrent requests reveal that each request can rely on the other's still-available backup.

The engineers define the cross-site rule explicitly, move the complete check and update into the supported transaction scope, and test overlapping requests. They add retry handling that reruns the whole transaction against a fresh view rather than blindly resubmitting an old decision.

The team also checks that notifications are not sent twice when a transaction retries. The scenario illustrates why database isolation also requires application discipline within the protected boundary.

Common misconceptions and mistakes

Common errors include equating two-phase locking with two-phase commit, assuming that replicas always show the same current value, and treating snapshot isolation as universally equivalent to serializability. The names describe different properties or mechanisms.

Another mistake is retrying only the final write after a transaction abort. Earlier reads and decisions may need to be repeated. A retry must also avoid duplicating external side effects. Finally, strict serializability adds a real-time ordering requirement beyond ordinary serializability; claims should use the correct term.

Business use

Businesses should identify the rules that concurrent activity must preserve before choosing an isolation level. Examples include capacity constraints, uniqueness and relationships spanning records. Test these rules under overlap and failure rather than only testing successful individual requests.

Measure contention, transaction duration, retry rates and cross-node communication. Stronger guarantees can require coordination, but weaker guarantees can create reconciliation work or incorrect decisions. AI agents submitting simultaneous updates need the same transactional protections as other clients; a well-written prompt is not a concurrency-control mechanism.

Check your understanding

Two transactions update different records after reading a shared condition spanning both records. Can they be assumed safe merely because their writes do not overlap?

Answer: No. Their read-write dependencies can produce write skew or another anomaly. The complete transactional condition and isolation guarantee must be considered.

Related terms

Distributed transaction
Two-phase locking
Serializability
isolation levels
write skew
two-phase commit
multiversion concurrency control
deadlock

Learn next

compare snapshot isolation with serializability using write-skew examples. Then study atomic commit separately from concurrency control, and examine transaction retry patterns so application code preserves the guarantees provided by the database.

Sources

Bernstein, Hadzilacos and Goodman, Concurrency Control and Recovery in Database Systems: https://www.microsoft.com/en-us/research/people/philbe/book/ . Relevant primary text in Chapters 2, 3 and 7 reviewed for serializability, locking and atomic commitment. Cockroach Labs, Developer Basics: https://www.cockroachlabs.com/docs/stable/developer-basics.html . Relevant indexed documentation reviewed as an example of isolation choices and client retry handling; product behaviour is not generalised to all databases.

Previous: Distributed computing Next: Distributed constraint optimization