Epoch-Based Optimistic Concurrency Control

Epochs let many transactions share a coordination step, while client responses still wait for global commit.

The wide-area round trip inside the commit path

A multi-leader database with leaders in several regions raises availability by accepting writes anywhere. In exchange it has to preserve ACID across every replica, which requires global concurrency control. Those synchronization protocols usually need multiple rounds of communication, and each round adds wide-area network (WAN) latency to the commit path.

Existing approaches differ in when they coordinate transactions.

Coordination remains somewhere in each design. Minerva, proposed by Mao et al. in 2026-02, batches data propagation and uses Raft to agree on epoch boundaries. It separates local execution from global commit rather than removing consensus.

Batching commit and replication into epochs

Optimistic concurrency control (OCC) executes transactions without locks. Before commit, it checks whether the data read by a transaction has changed. If so, the transaction aborts and retries. In a geo-distributed system, validation may need state from a remote region. This adds a round trip before commit.

Replicas execute transactions locally and write results into uncommitted temporary state. The paper uses 15ms epochs and sends batches at a 4MB threshold or a 5ms timeout. These values control batching; local completion does not authorize a success response to the client.

Raft agrees on a global cut: the batch-log prefix from each replica that belongs to an epoch. Many transactions share that agreement, so coordination work is amortized. Each transaction still waits for replication, epoch validation, and global commit before the client receives its result.

Concurrent regions can produce conflicting tentative results for the same record. Epoch validation resolves those conflicts before global commit. The system therefore revises speculative work, not transactions already acknowledged as committed.

sequenceDiagram
    participant C as Client
    participant R as Local replica
    participant Q as Replicas and Raft
    C->>R: Transaction
    R->>R: Execute into temporary state
    R->>Q: Replicate batches
    Q->>Q: Agree on epoch cut
    Q->>R: Validate and re-execute conflicts
    R->>R: Global commit
    R-->>C: Committed result

Deterministic re-execution instead of abort

Classic OCC would abort the conflicting transaction at this point. Minerva re-executes it instead, running five stages at epoch commit time.

flowchart TD
    A["Epoch write sets arrive"] --> B["Build transaction chains<br/>group transactions linked by dependencies"]
    B --> C["Staleness check<br/>compare epoch ids of read-set items"]
    C --> D["Build the conflict graph<br/>vertices are chains, edges are write conflicts"]
    D --> E["Solve MWIS<br/>choose tentative results to retain"]
    E --> F["Re-execute the rest<br/>ordered by tid and replica priority"]

A transaction chain groups dependent transactions within one batch. Minerva evaluates complete chains. If an earlier transaction is invalidated, later dependent transactions also become invalidation candidates.

The staleness check examines each item in the chain's read set. It checks whether the item's epoch id is older than the current epoch id or a preceding transaction aborted.

This check uses epoch ids instead of physical timestamps. Network Time Protocol (NTP) synchronization errors therefore do not affect the decision.

The conflict graph represents transaction chains as vertices and data conflicts as edges. Each vertex's weight equals its transaction count. A maximum weight independent set (MWIS) selects compatible chains whose tentative results can remain.

The paper compares an exact integer linear programming (ILP) solver with a greedy approximation. That experiment does not establish an automatic policy that selects ILP at low contention and greedy solving at high contention.

Chains outside the independent set are re-executed. The ordering key combines the transaction id (tid) with the source replica's static priority. All replicas use the same rule and therefore produce the same order without additional ordering agreement.

Re-execution uses Calvin-style deterministic locking. The read and write sets are already known, so deadlock does not arise.

The difference from Calvin is the scope over which determinism applies. Calvin needs the read and write sets of every transaction before execution. Minerva executes first and narrows deterministic re-execution to the transactions that were confirmed to conflict.

Cost that moves with the conflict rate

Table 1 of the paper breaks epoch commit time into stages under saturation in a 500ms latency environment.

The total is roughly the same in both cases, around 32.5ms, but the cost inside it moves. When conflicts are rare, the staleness check and graph construction dominate at 6.84ms and 5.62ms respectively, and re-execution stays under 1ms. When conflicts are frequent, re-execution takes 17.53ms, more than half of the total.

With few conflicts, MWIS optimization prevents unnecessary aborts. As conflicts increase, re-execution accounts for more of the cost.

How much re-execution occurs is set by the access distribution of the workload. In the YCSB-A experiment with a Zipfian distribution, shown in figure 10 of the paper, the re-execution ratio grows with the coefficient.

The experiment enters high-contention mode in the region above a Zipfian coefficient of 1.2. This mode bypasses local OCC and sends transactions directly to deterministic execution. The roughly 35% re-execution ratio is an observed result, not a configured cap or a universal switching threshold.

Which workloads it wins on

The evaluation compares GeoGauss, Ocean Vista, CockroachDB, COCO, and CalvinDB under full replication with disk persistence disabled. The TPC-C-derived workload uses Payment and NewOrder, with implementation differences across baselines. These conditions limit what the throughput comparison establishes.

Values are approximate transactions per second read from figure 6. At 200ms inter-replica network delay, Minerva reaches about 3.8x CalvinDB throughput. The paper varies injected network delay; this table does not relabel that value as round-trip time (RTT).

A separate LAN scaling experiment grows the replica count from 3 to 15. Figure 9 reports approximately 12,000 transactions per second with 15 replicas, while median TPC-C-derived latency moves from 17ms to 18ms. These latency values do not describe the 200ms network-delay experiment.

The design favors two conditions. Inter-region RTT must be large enough that per-commit round trips dominate. The conflict rate must remain low enough for the system to absorb re-execution costs. Commits still finish at epoch boundaries. The design therefore does not suit workloads that prioritize individual transaction response time.

Remaining constraints

MWIS is NP-hard, so dense conflict graphs make exact solving expensive. High-contention mode reduces speculative local execution, but its benefits still depend on the workload. A Zipfian coefficient observed in one experiment is not a portable production threshold.

The 15ms epoch length is an experimental setting, not a latency guarantee. The paper reports that consensus becomes the bottleneck when its delay exceeds the epoch interval. Size epochs against network conditions, batching load, and the required client commit latency.

Ordering by tid and replica priority removes the NTP dependency. However, transactions from low-priority regions may repeatedly move later in the re-execution order. The paper does not evaluate whether this creates unfairness between regions.

Summary

Epoch-based OCC lets many transactions share replication and coordination work. Minerva executes tentatively, agrees on a global epoch cut through Raft, and resolves conflicts before global commit.

The paper reports throughput gains at high network delay, while its 17-18ms latency result comes from a separate LAN experiment. Evaluate batching and re-execution against the actual workload, since clients still wait for global commit.