How Fast can a Distributed Transaction Commit?

Guerraoui, Rachid; Wang, Jingjing

doi:10.1145/3034786.3034799

Cited by 17 publications

(11 citation statements)

References 63 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Recently, Guerraoui and Wang [22] have systematically studied the failure-free complexity of NBAC (in terms of both message delays and number of messages) for various combinations of the correctness properties and failure models. The complexity of certifying a transaction in the failure-free runs of our crash fault-tolerant TCS implementation (provided the coordinator is replaced with all-to-all communication) matches the tight bounds for the most robust version of NBAC considered in [22], which suggests it is optimal. A comprehensive study of the TCS complexity in the absence of failures is the subject of future work.…”

Section: Related Workmentioning

confidence: 99%

Multi-shot distributed transaction commit

Chockler

Gotsman

2021

Distrib. Comput.

View full text Add to dashboard Cite

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.

show abstract

Section: Related Workmentioning

confidence: 99%

Multi-shot distributed transaction commit

Chockler

Gotsman

2021

Distrib. Comput.

View full text Add to dashboard Cite

show abstract

“…Silent confirmation rounds can be used to improve solutions to other distributed problems. For example, a variety of protocols in the literature make use of long silent phases consisting of (t + 1) rounds or more to verify that a specific milestone has been reached (e.g., [17,3,18]). The time complexity of these protocols in the common case can easily be reduced by employing a silent confirmation round instead.…”

Section: Silent Confirmation Roundsmentioning

confidence: 99%

“…Protocols that are highly efficient in the common case can make a significant contribution to the effective operations of a distributed system [8,1,28,7,23,26,18,22,16,17]. If failures are rare, then the system's performance in the common, failure-free, case is much more practically relevant than its performance when failures occur.…”

Section: Introductionmentioning

confidence: 99%

Byzantine Consensus in the Common Case

Goren,

Moses

2019

Preprint

View full text Add to dashboard Cite

Modular methods to transform Byzantine consensus protocols into ones that are fast and communication efficient in the common cases are presented. Small and short protocol segments called layers are custom designed to optimize performance in the common case. When composed with a Byzantine consensus protocol of choice, they allow considerable control over the tradeoff in the combined protocol's behavior in the presence of failures and its performance in their absence. When runs are failure free in the common case, the resulting protocols decide in two rounds and require 2nt bits of communication. For the common case assumption that all processors propose 1 and no failures occur, we show a transformation in which decisions are made in one round, and no bits of communication are exchanged. The resulting protocols achieve better common-case complexity than all existing Byzantine consensus protocols. Finally, in the rare instances in which the common case does not occur, a small cost is added to the complexity of the original consensus protocol being transformed. The key ingredient of these layers that allows both time and communication efficiency in the common case is the use of silent confirmation rounds, which are rounds where considerable relevant information can be obtained in the absence of any communication whatsoever."I am prepared for the worst, but hope for the best"Benjamin Disraeli

show abstract

“…We have implemented in FLAC a family of three protocols that can operate effectively in the three aforementioned environments. These protocols correspond to the three robustness levels: failure-free, crash failure, and network failure, based on the expected failure set defined in [27]. FLAC can switch between the three protocols based on closely monitoring its operating environment.…”

Section: Introductionmentioning

confidence: 99%

FLAC: Practical Failure-Aware Atomic Commit Protocol for Distributed Transactions

Pan¹,

Ta²,

Zhang³

et al. 2023

Preprint

View full text Add to dashboard Cite

In distributed transaction processing, atomic commit protocol (ACP) is used to ensure database consistency. With the use of commodity compute nodes and networks, failures such as system crashes and network partitioning are common. It is therefore important for ACP to dynamically adapt to the operating condition for efficiency while ensuring the consistency of the database. Existing ACPs often assume stable operating conditions, hence, they are either nongeneralizable to different environments or slow in practice.In this paper, we propose a novel and practical ACP, called Failure-Aware Atomic Commit (FLAC). In essence, FLAC includes three protocols, which are specifically designed for three different environments: (i) no failure occurs, (ii) participant nodes might crash but there is no delayed connection, or (iii) both crashed nodes and delayed connection can occur. It models these environments as the failure-free, crash-failure, and network-failure robustness levels. During its operation, FLAC can monitor if any failure occurs and dynamically switch to operate the most suitable protocol, using a robustness level state machine, whose parameters are finetuned by reinforcement learning. Consequently, it improves both the response time and throughput, and effectively handles nodes distributed across the Internet where crash and network failures might occur. We implement FLAC in a distributed transactional keyvalue storage system based on Google Percolator and evaluate its performance with both a micro benchmark and a macro benchmark of real workload. The results show that FLAC achieves up to 2.22x throughput improvement and 2.82x latency speedup, compared to existing ACPs for high-contention workloads.

show abstract

How Fast can a Distributed Transaction Commit?

Cited by 17 publications

References 63 publications

Multi-shot distributed transaction commit

Multi-shot distributed transaction commit

Byzantine Consensus in the Common Case

FLAC: Practical Failure-Aware Atomic Commit Protocol for Distributed Transactions

Contact Info

Product

Resources

About