RCC: Speculative Write Versioning with Redo Logs

2026-07-21

AI Summary

This work addresses the limited concurrency of traditional OLTP systems under write-write conflicts caused by in-place updates. The authors propose a redo-log-based speculative write-versioning mechanism that enables conflicting transactions to execute speculatively in a pipelined fashion and install their updates only upon commit, supporting lightweight rollback when necessary. Key innovations include a commit-time, one-shot deadlock detection scheme that defers cycle discovery and a column-granularity_RCC protocol (RCC-C) that leverages columnar logging to eliminate false write conflicts at the record level. Implemented atop MySQL and PostgreSQL, the system achieves an order-of-magnitude improvement in throughput and latency over the original engines under 64-thread TPC-C workloads. RCC-C substantially reduces spurious conflicts, enabling scalability to 128 clients under highly contended YCSB scenarios.

Abstract

Modern OLTP engines rely on multi-versioning to eliminate read-write conflicts, yet their concurrency is severely limited for write-write conflicts. The conventional wisdom of updating records in place and immediately causes only one transaction to update a record at a time, and other update-conflicting transactions to wait for the former to commit or abort. Thus, conflicting transactions are serialized. We propose RCC, which leverages redo logs to resolve conflicting writes. A transaction updates a record out of place by creating a speculative write version using the redo log. With multiple speculative versions, RCC allows concurrent transactions to be pipelined after the update-conflicting point. Each update made by a transaction is installed to its record upon commit. This lazy update policy enables lightweight rollback: a transaction aborts by discarding its speculative versions. To realize the performance potential of its speculative versioning, RCC proposes two novel techniques: commit-time deadlock detection and columnar RCC (RCC-C). The former detects cycles only once lazily at commit time and the latter eliminates record-level false WW conflicts by leveraging column-granule redo logs. RCC guarantees serializability using lock-based access-time conflict ordering and dependency graph tracking. We implement RCC on MySQL and PostgreSQL, integrating the concurrency control mechanism with their buffer managers, lock managers, and recovery modules. RCC improves TPC-C's transaction throughput and latency over Vanilla versions by an order of magnitude when running 64 concurrent threads on a machine with 128 cores. RCC-C further boosts throughput and latency by avoiding false conflict-induced deadlocks and unnecessary aborts. For a high-contention YCSB benchmark, commit-time deadlock detection enables RCC to scale to 128 clients while competing schemes do not scale beyond 32 threads.

Problem

• write-write conflicts
• multi-versioning
• concurrency control
• speculative versioning
• serializability

Innovation

• speculative versioning
• redo logs
• commit-time deadlock detection
• columnar concurrency control
• write-write conflict resolution