Multi-shot distributed transaction commit

Abstract

Atomic Commit Problem (ACP) is a single-shot agreement problem similar to consensus, meant to model the properties of transaction commit protocols in fault-prone distributed systems. We argue that ACP is too restrictive to capture the complexities of modern transactional data stores, where commit protocols are integrated with concurrency control, and their executions for different transactions are interdependent. As an alternative, we introduce Transaction Certification Service (TCS), a new formal problem that captures safety guarantees of multi-shot transaction commit protocols with integrated concurrency control. TCS is parameterized by a certification function that can be instantiated to support common isolation levels, such as serializability and snapshot isolation. We then derive a provably correct crash-resilient protocol for implementing TCS through successive refinement. Our protocol achieves a better time complexity than mainstream approaches that layer two-phase commit on top of Paxos-style replication.

Reconfigurable Atomic Transaction Commit

“…We present protocols in two different models-the standard asynchronous messagepassing model ( §3) and a model with Remote Direct Memory Access (RDMA), which allows a machine to access the memory of another machine over the network without involving the latter's CPU ( §5). Our protocols are parametric in the isolation level provided, and we prove that they correctly implement the TCS specification from the multi-shot commit problem [5] ( §4).…”

“…A Transaction Certification Service (TCS) is meant to be used in the context of transactional processing systems with optimistic concurrency control [26], where transactions are first executed speculatively, and the results are submitted for certification to the TCS. We start by reviewing its specification proposed in [5]. Clients invoke the TCS using requests of the form certify(t, l), where t ∈ T is a unique transaction identifier and l ∈ L is the transaction payload, which carries the results of the optimistic execution of the transaction (e.g., read and write sets).…”

“…A typical system based on optimistic concurrency control will ensure that transactions submitted for certification only read versions written by previously committed transactions. A history produced by such a system that is correct with respect to certification function (2) is also serializable [5]. Hence, a TCS correct with respect to this certification function can indeed be used to implement serializability.…”

“…When a shard s votes on a transaction, it does not have information about all transactions in the system, but only those that concern it. Hence, the votes are computed using not the global certification function f , but shard-local certification functions [5], which check for conflicts only on objects managed by the shard and correspondingly take as parameters only the parts of the transaction payloads relevant to the shard: for a payload l we denote this by l | s. For example, let Obj s be the set of objects managed by a shard s. For a payload l = ⟨R,W , V c ⟩ of the form given above, we let…”

“…TCS is the most challenging part of transaction processing in systems with the above architecture, since it requires solving a distributed agreement problem among the replicated shards participating in the transaction. This agreement problem has been recently formalized as the multi-shot commit problem [5], generalizing the classical atomic commit problem [9] to more faithfully reflect the requirements of modern transaction processing systems (we review the new problem statement in §2).…”