Lecture 14: Optimistic Concurrency Control

What this lecture covers

FaRM targets a different bottleneck than Spanner: instead of geographic distance, it attacks CPU and network overhead within a single data center, using RDMA-capable network cards to read and write remote memory directly. The lecture asks how a transaction system can exploit that hardware, given that RDMA reads bypass the server's CPU entirely and so cannot check locks or transaction state the way earlier protocols assumed.

It explains why this forces FaRM into optimistic concurrency control rather than locking, and works through FaRM's commit protocol in detail: buffering writes locally, then locking, validating, and committing via RDMA-appended log entries with version numbers and lock bits. After watching, you should be able to explain why RDMA is incompatible with pessimistic locking, trace FaRM's lock/validate/commit protocol on a conflicting pair of transactions, and describe how it achieves serializability without holding locks during reads.

Key ideas

• RDMA (remote direct memory access): lets one machine's network card read or write another machine's memory directly, without interrupting its CPU, at roughly 5 microseconds per operation.
• Kernel bypass: applications talk to the network card directly, skipping the kernel's socket and TCP stack, cutting most of the CPU cost of traditional networking.
• Non-volatile RAM (NVRAM): FaRM keeps all data in RAM for speed, and survives data-center-wide power failures by having battery backup give servers time to dump RAM to solid-state disk before shutting down.
• Why RDMA rules out locking: a one-sided RDMA read bypasses the server's software, so there is no way for the server to check or set a lock during a plain read, which is incompatible with pessimistic two-phase locking.
• Optimistic concurrency control (OCC): transactions read data without locking it and buffer writes locally, then at commit time validate that nothing else modified the data since it was read, aborting if a conflict is detected.
• Version numbers and lock bits: each object header packs a lock bit and a version number; a primary uses an atomic compare-and-swap to check the version is unchanged and the lock is clear before granting a lock.
• Lock phase and commit phase: a transaction appends lock entries (object ID, version read, new value) to each primary's log; if every primary votes yes, the coordinator appends commit entries, and only then does the data change and the lock clear.
• Validate: a faster path for objects that were only read, not written; the coordinator re-reads the object header with a one-sided RDMA read and checks the version and lock bit instead of going through the full lock/commit exchange.

Walkthrough

Why FaRM differs from Spanner (0:00)

The lecture opens by contrasting FaRM with the previous lecture's Spanner: both replicate and use variants of two-phase commit, but Spanner targets geographic replication and tolerates 10-100 millisecond transactions, while FaRM is a research prototype confined to a single data center that achieves roughly 58-microsecond transactions, about 100 times faster, by attacking CPU and network overhead instead of speed-of-light delay.

Non-volatile RAM (9:08)

Since all data lives in RAM for speed, FaRM needs a way to survive power failures. Batteries in every rack keep servers running briefly after a power failure and alert them; servers then stop processing, copy RAM to solid-state drives, and shut down, restoring the saved image on reboot. This scheme only covers power failures, not other crashes, which is why FaRM also keeps primary-backup replicas of each shard.

Kernel bypass and RDMA (16:13)

The lecture explains why conventional networking (system calls, kernel TCP stack, interrupts, data copies) caps RPC throughput far below what network hardware can deliver. Kernel bypass lets applications talk directly to the network card, eliminating that overhead. RDMA goes further: one-sided RDMA lets a network card read or write another machine's memory directly, entirely in card firmware, with no CPU involvement on the target side, delivering around 5-microsecond latency and millions of operations per second.

The concurrency control problem RDMA creates (33:30)

Every transaction protocol covered so far, including two-phase locking, requires active server software to check or set locks and to track committed versus uncommitted data. A pure one-sided RDMA read bypasses that software, so it cannot participate in locking. FaRM's answer is to give up on locking reads and adopt optimistic concurrency control: read freely, buffer writes locally, and check at commit time whether anything changed.

FaRM's commit protocol: lock and commit phases (49:44)

The lecture walks through Figure 4 of the paper. In the execute phase, the client reads everything it needs with one-sided RDMA reads, including the version number of each object. At TX commit, the client appends a lock log entry (object ID, version read, new value) to each relevant primary's log via RDMA. Each primary polls its logs, and using an atomic compare-and-swap checks that the object isn't already locked and that its version number still matches what the client read; if both hold, it sets the lock and votes yes, otherwise it votes no. If every primary votes yes, the coordinator appends commit entries; a primary that sees a commit entry updates the object, bumps its version number, and clears the lock, making the new value visible to others.

Working through conflicting transactions (59:52)

Using two transactions that both try to increment the same object, the lecture traces several interleavings: simultaneous lock messages resolve via whichever compare-and-swap executes first, with the loser voting no; a transaction that reads before another commits but tries to lock after will see a changed version number and abort; a transaction that reads after another has already committed sees the new version and succeeds cleanly. In every case the observed version number and lock bit at lock time reveal whether an intervening commit occurred, which is what gives FaRM serializability without ever holding a lock during a read.

Validate: a faster path for read-only access (1:13:05)

For objects a transaction only read, FaRM skips the lock/commit log exchange and instead re-reads the object header with another one-sided RDMA read, checking that the version number and lock bit are unchanged. The lecture runs a classic strong-consistency test (if x==0 then y=1, if y==0 then x=1) through this validation path, showing that concurrent execution correctly aborts both transactions when they conflict, and lets one succeed while the other aborts when timing allows it, matching only the legal serializable outcomes. A transaction that only reads needs no lock or commit phase at all, making pure read-only transactions extremely cheap.

Before you watch

• Review two-phase locking and two-phase commit from the earlier distributed transactions lecture, since FaRM's protocol is explicitly compared against them.
• Watch the Spanner lecture first if possible, since this lecture opens by contrasting FaRM's design goals and performance with Spanner's.
• Be familiar with the general idea of optimistic versus pessimistic concurrency control introduced earlier in the course.

Check your understanding

1. Why can't FaRM use a locking scheme built purely on one-sided RDMA reads and writes?
2. What roles do the version number and the lock bit play in FaRM's compare-and-swap check during the lock phase?
3. Walk through why a transaction that reads an object, then observes a different version number when it tries to lock or validate that object, must abort.
4. Why does FaRM's non-volatile RAM scheme protect against power failures but not against other kinds of crashes?
5. Why is the validate path for read-only objects faster than the full lock-and-commit path used for writes?