TicToc

Abstract

Concurrency control for on-line transaction processing (OLTP) database management systems (DBMSs) is a nasty game. Achieving higher performance on emerging many-core systems is difficult. Previous research has shown that timestamp management is the key scalability bottleneck in concurrency control algorithms. This prevents the system from scaling to large numbers of cores. In this paper we present TicToc, a new optimistic concurrency control algorithm that avoids the scalability and concurrency bottlenecks of prior T/O schemes. TicToc relies on a novel and provably correct data-driven timestamp management protocol. Instead of assigning timestamps to transactions, this protocol assigns read and write timestamps to data items and uses them to lazily compute a valid commit timestamp for each transaction. TicToc removes the need for centralized timestamp allocation, and commits transactions that would be aborted by conventional T/O schemes. We implemented TicToc along with four other concurrency control algorithms in an in-memory, shared-everything OLTP DBMS and compared their performance on different workloads. Our results show that TicToc achieves up to 92% better throughput while reducing the abort rate by 3.3× over these previous algorithms.

Mostly-optimistic concurrency control for highly contended dynamic workloads on a thousand cores

“…After formulated by Kung et al [20] , OCC has been adopted by databases for manycore servers [17,41] . TicToc [47] avoid centralized timestamp allocation and can commit certain transactions that would be aborted by traditional timestamp ordering schemes. OCC is vulnerable to aborts under high conflict.…”

2plsf

“…Our 2PLSF concurrency control described in Algorithm 1 uses the same read-indicator layout as 2PL-RW-Dist, however, it does so in a way as to guarantee starvation-freedom and efficient conflict detection. Similarly to most other concurrency controls, 2PL-RW-Dist uses a backoff strategy to solve conflicts, a strategy referred in the literature as 2PL No-Wait [28,29], while our 2PLSF does no backoff. As can be observed in Figure 2, on read-mostly workloads (rightmost plot) the 2PLSF approach has no advantage over 2PL-RW-Dist, however, on write-intensive workloads (leftmost plot) 2PLSF is significantly faster at solving conflicts, giving it an advantage of more than 2x over 2PL-RW-Dist.…”

“…2PL implementations typically use a mutual exclusion lock even for read accesses [29], the reason being that common reader-writer locks have poor scalability for short lived readlock acquisitions. This happens because of contention on the variable that counts the number of active readers, henceforth named the read-indicator.…”

“…When it comes to the way conflicts are handled, there are three main variants of 2PL, named no-wait, wait-or-die and deadlock-detection [1,28,29]. The 2PL no-wait variant uses a backoff strategy, aborting the transaction as a soon as a lock conflict is detected.…”

A queue-oriented transaction processing paradigm

“…Notes Centralized (deterministic) H-Store [13] two-orders of magnitude YCSB Multi-partition workload Distributed (deterministic) Calvin [18] 22× YCSB Low-contention workload (Uniform access) Centralized (non-deterministic) Cicada [16], TicToc [25], Foudus [15], Ermia [14], Silo [20], 2PL-NoWait [24] 3× TPC-C High-contention workload (1 warehouse) Table 2. Experimental results using TPC-C and YCSB for the centralized implementation of queue-oriented paradigm [17], and a distributed deterministic database.…”