Bringing Modular Concurrency Control to the Next Level

Su, Chunzhi; Crooks, Natacha; Ding, Cong; Alvisi, Lorenzo; Chao, Xie

doi:10.1145/3035918.3064031

Cited by 15 publications

(21 citation statements)

References 52 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…When validating a predicate, a transaction txn calls the function valGW with the range [sIndex, eIndex] of gList, in which all of its overlapping transactions can be found. In particular, for each concurrent transaction in gList, txn checks whether the predicate intersects with each element in the concurrent transaction's WriteSet (lines [19][20][21]. If yes, the result ABORT is returned.…”

Section: Validation Methodsmentioning

confidence: 99%

“…In Section 5.2, we introduce the analysis of validation cost and how to choose a validation strategy. If LRV2 is chosen, we call the function valLR2 to validate this predicate; otherwise, valGW is called (lines [15][16][17][18][19][20][21][22]. If the function returns ABORT, the transaction sets its status to ABORT and then aborts itself.…”

Section: Validation Phasementioning

confidence: 99%

“…CormCC [20], the successive work of ACC, is a general mixed concurrency control framework without coordination overhead across candidate protocols while supporting the ability to change a protocol online with minimal overhead. Callas [25] and its successive work Tebaldi [19] provided a modular concurrency control mechanism to group stored procedures and provided an optimized concurrency control protocol for each group based on offline workload analysis. Cao et al [3] proposed a hybrid tracking method for choosing one from OCC and pessimistic CC to handle different conflict accesses.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Adaptive optimistic concurrency control for heterogeneous workloads

et al. 2019

View full text Add to dashboard Cite

Optimistic concurrency control (OCC) protocols validate whether a transaction has conflicts with other concurrent transactions after this transaction completes its execution. In this work, we demonstrate that the validation phase has a great influence on the performance of modern in-memory database systems, especially under heterogeneous workloads. The cost of validating operations in a transaction is determined by two main factors. The first factor is the operation type. An OCC protocol would take much less cost on validating a single-record read operation than validating a key-range scan operation. The second factor is the workload type. Existing schemes in OCC variants for validating key-range scan perform differently under various workloads. Although various validation schemes share the same goal of guaranteeing a transaction schedule to be serializable, there are remarkable differences between the costs they introduced. These observations motivate us to design an optimistic concurrency control which can choose a low-cost validation scheme at runtime, referred to as adaptive optimistic concurrency control (AOCC). First, at transactionlevel granularity, AOCC can assign a validation method to a transaction according to the features of its operations. Furthermore, for each operation in a transaction, the validation method is selected according to not only the number of accessed records but also the instant characteristics of workloads. Experimental results show that AOCC has good performance and scalability under heterogeneous workloads mixed with point accesses and predicate queries.

show abstract

Section: Validation Methodsmentioning

confidence: 99%

Section: Validation Phasementioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Adaptive optimistic concurrency control for heterogeneous workloads

et al. 2019

View full text Add to dashboard Cite

show abstract

“…Sundial uses different methods to resolve different types of conflicts between transactions. Such hybrid schemes have also been proposed before in both databases [18,44] and software transactional memory [19].…”

Section: Conflict Handlingmentioning

confidence: 99%

Sundial

Xia

Pavlo

et al. 2018

Proc. VLDB Endow.

View full text Add to dashboard Cite

Distributed transactions suffer from poor performance due to two major limiting factors. First, distributed transactions suffer from high latency because each of their accesses to remote data incurs a long network delay. Second, this high latency increases the likelihood of contention among distributed transactions, leading to high abort rates and low performance.We present Sundial, an in-memory distributed optimistic concurrency control protocol that addresses these two limitations. First, to reduce the transaction abort rate, Sundial dynamically determines the logical order among transactions at runtime, based on their data access patterns. Sundial achieves this by applying logical leases to each data element, which allows the database to dynamically calculate a transaction's logical commit timestamp. Second, to reduce the overhead of remote data accesses, Sundial allows the database to cache remote data in a server's local main memory and maintains cache coherence. With logical leases, Sundial integrates concurrency control and cache coherence into a simple unified protocol. We evaluate Sundial against state-of-the-art distributed concurrency control protocols. Sundial outperforms the next-best protocol by up to 57% under high contention. Sundial's caching scheme improves performance by up to 4.6× in workloads with high access skew. PVLDB Reference Format:

show abstract

“…Standard protocols for distributed transactions lock data at different servers until lengthy cross-server coordination is completed, creating a major bottleneck. This motivated a large volume of work on speeding up distributed transactions while preserving strong consistency [31], [8], [17], [27], [23], [11], [2]. This work proposes new DBMS designs where the concurrency control mechanisms for single-server transactions and distributed transactions are deeply intertwined.…”

Section: Introductionmentioning

confidence: 99%

Gyro: A Modular Scale-Out Layer for Single-Server DBMSs

Saissi

Serafini

Suri

2019

2019 38th Symposium on Reliable Distributed Systems (SRDS)

View full text Add to dashboard Cite

Scaling out database management systems (DBMSs) requires distributed coordination, which can easily become a bottleneck. Recent work on speeding up distributed transactions has addressed this problem by proposing scale-out techniques that are deeply integrated with the concurrency control mechanism of the DBMS. This paper explores the design of modular coordination layers, which encapsulate all scale-out logic and can be applied to scale out any unmodified single-server DBMS. It proposes Gyro, a modular coordination layer that runs on top of a collection of single-server DBMS instances and interacts with them only through their client interface. Gyro distributes the load by ensuring that as many requests as possible are executed by only one DBMS instance. Our experiments show that modular distributed coordination is practically viable and can be much faster than traditional distributed transaction protocols using two-phase commit.

show abstract

Bringing Modular Concurrency Control to the Next Level

Cited by 15 publications

References 52 publications

Adaptive optimistic concurrency control for heterogeneous workloads

Adaptive optimistic concurrency control for heterogeneous workloads

Sundial

Gyro: A Modular Scale-Out Layer for Single-Server DBMSs

Contact Info

Product

Resources

About