Conference PaperPDF Available

QueCC: A Queue-oriented, Control-free Concurrency Architecture



We investigate a coordination-free approach to transaction processing on emerging multi-sockets, many-core, shared-memory architecture to harness its unprecedented available parallelism. We propose a queue-oriented, control-free concur-rency architecture, referred to as QueCC, that exhibits minimal contention among concurrent threads by eliminating the overhead of concurrency control from the critical path of the transaction. QueCC operates on batches of transactions in two deterministic phases of priority-based planning followed by control-free execution. We extensively evaluate our transaction execution architecture and compare its performance against seven state-of-the-art concurrency control protocols designed for in-memory, key-value stores. We demonstrate that QueCC can significantly out-perform state-of-the-art concurrency control protocols under high-contention by up to 6.3×. Moreover, our results show that QueCC can process nearly 40 million YCSB transactional operations per second while maintaining serializability guarantees with write-intensive workloads. Remarkably, QueCC out-performs H-Store by up to two orders of magnitude.
QueCC: A Queue-oriented, Control-free Concurrency
Thamir M. Qadah1, Mohammad Sadoghi2
Exploratory Systems Lab
1Purdue University, West Lafayette
2University of California, Davis,
We investigate a coordination-free approach to transaction
processing on emerging multi-sockets, many-core, shared-
memory architecture to harness its unprecedented available
parallelism. We propose a queue-oriented, control-free concur-
rency architecture, referred to as eCC, that exhibits mini-
mal contention among concurrent threads by eliminating the
overhead of concurrency control from the critical path of the
transaction. eCC operates on batches of transactions in
two deterministic phases of priority-based planning followed
by control-free execution. We extensively evaluate our trans-
action execution architecture and compare its performance
against seven state-of-the-art concurrency control protocols
designed for in-memory, key-value stores. We demonstrate
that eCC can signicantly out-perform state-of-the-art
concurrency control protocols under high-contention by up
to 6
. Moreover, our results show that eCC can pro-
cess nearly 40 million YCSB transactional operations per
second while maintaining serializability guarantees with
write-intensive workloads. Remarkably, eCC out-performs
H-Store by up to two orders of magnitude.
CCS Concepts Information systems Data manage-
ment systems
DBMS engine architectures
transaction processing
Parallel and distributed DBMSs
Key-value stores;Main memory engines;
ACM Reference Format:
Thamir M. Qadah
, Mohammad Sadoghi
. 2018. QueCC: A Queue-
oriented, Control-free Concurrency Architecture. In 19th Interna-
tional Middleware Conference (Middleware ’18), December 10–14,
2018, Rennes, France. ACM, New York, NY, USA, 14 pages. hps:
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not
made or distributed for prot or commercial advantage and that copies bear
this notice and the full citation on the rst page. Copyrights for components
of this work owned by others than ACM must be honored. Abstracting with
credit is permitted. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specic permission and/or a fee. Request
permissions from
Middleware ’18, December 10–14, 2018, Rennes, France
©2018 Association for Computing Machinery.
ACM ISBN 978-1-4503-5702-9/18/12. . . $15.00
1 Introduction
New multi-socket, many-core hardware architectures with
tens or hundreds of cores are becoming commonplace in the
market today [
]. This is a trend that is expected
to increase exponentially, thus, reaching thousands of cores
per box in the near future [
]. However, recent studies
have shown that traditional transactional techniques that
rely on extensive coordination among threads fail to scale
on these emerging hardware architectures; thus, there is
an urgent need to develop novel techniques to utilize the
power of next generation of highly parallel modern hardware
]. There is also a new wave to study deter-
ministic concurrency techniques, e.g., the read and write
sets are known a priori. These promising algorithms are
motivated from the practical standpoint by examining the
predened stored procedures that are heavily deployed in
customer settings [
]. However, many of
the existing deterministic approaches do not fundamentally
redesign their algorithms for the many-core architecture,
which is the precise focus on this work, a novel deterministic
concurrency control for modern highly parallel architec-
The main challenge for transactional processing systems
built on top of many-core hardware is the increased con-
tention (due to increased parallelism) among many compet-
ing cores for shared resources, e.g., failure to acquire highly
contended locks (pessimistic) or failure to validate contented
tuples (optimistic). The role of concurrency control mecha-
nisms in traditional databases is to determine the interleav-
ing order of operations among concurrent transactions over
shared data. But there is no fundamental reason to rely on
concurrency control logic during the actual execution nor it
is a necessity to force the same thread to be responsible for
executing both transaction and concurrency control logic.
This important realization has been observed in recent stud-
ies [
] that may lead to a complete paradigm shift in
how we think about transactions, but we have just scratched
the surface. It is essential to note that the two tasks of es-
tablishing the order for accessing shared data and actually
executing the transaction
s logic are completely independent.
Hence, these tasks can potentially be performed in dierent
phases of execution by independent threads.
For instance, Ren et al. [
] propose ORTHRUS which op-
erates based on pessimistic concurrency control, in which
transaction executer threads delegate locking functionality
to dedicated lock manager threads. Yao et al. [
] propose
LADS that process batches of transactions by constructing a
set of transaction dependency graphs and partition them into
smaller pieces (e.g., min-cut algorithms) followed by depend-
ency-graph-driven transaction execution. Both ORTHRUS
and LADS rely on explicit message-passing to communicate
among threads, which can introduce an unnecessary over-
head to transaction execution despite the available shared
memory model of a single machine. In contrast, eCC em-
braces the shared memory model and applies determinism
in a two-phase, priority-based, queue-oriented execution
The proposed work in this paper is motivated by a sim-
ple profound question: is it possible to have concurrent ex-
ecution over shared data without having any concurrency
control? To answer this question, we investigate a deter-
ministic approach to transaction processing geared towards
multi-socket, many-core architectures. In particular, we pro-
pose eCC, pronounced Quick, a novel queue-oriented,
control-free concurrency architecture that exhibits minimal
contention during execution and imposes no coordination
among transactions while oering serializable guarantees.
The key intuition behind our eCC’s design is to eliminate
concurrency control by executing a set of batched transac-
tions in two disjoint and deterministic phases of planning and
execution, namely, decompose transactions into (predeter-
mined) priority queues followed by priority-queue-oriented
execution. In other words, we impose a deterministic plan of
execution on batches of transactions, which eliminates the
need for concurrency control during the actual execution of
1.1 Emergence of Deterministic Key-Value Stores
Early proposals for deterministic execution for transaction
processing aimed at data replication (e.g., [
]). The sec-
ond wave of proposals focused on deterministic execution
in distributed environments, and lock-based approaches for
concurrency control. For example, H-Store is exclusively tai-
lored for partitionable workloads (e.g. [
]) as it essentially
relies on partition-level locks and runs transactions serially
within each partition. Calvin and all of its derivatives primar-
ily focused on developing a novel distributed protocol, where
essentially all nodes partaking in distributed transactions
execute batched transactions on all replicas in a predeter-
mined order known to all. For local in-node concurrency,
in Calvin all locks are acquired (in order to avoid deadlock)
before a transaction starts and if not all locks are granted,
then the node stalls [
]. In fact, Calvin and eCC dovetails,
the former sequences transactions pre-execution to essen-
tially (almost) eliminate agreement protocol while the latter
introduces a novel predetermined prioritization and queue-
oriented execution model to essentially (almost) eliminate
the concurrency protocol.
Deterministic data stores guarantee se-
rializable execution of transactions seamlessly. A determin-
istic transaction processing engine needs to ensure that (a)
the order of conicting operations, and (b) the commitment
ordering of transactions follow the same order that is deter-
mined prior to execution. With those two constraints are
satised by the execution engine, serializable execution is
guaranteed. In fact, from the scheduling point of view, de-
terministic data stores are less exible compared to other
serializable approaches [
] because there is only one
possible serial schedule that is produced by the execution en-
gine. However, this allows the protocol to plan a near-optimal
schedule that maximizes the throughput. Furthermore, given
the deterministic execution, evaluating and testing the con-
currency protocol is dramatically simplied because all non-
determinism complexity has been eliminated. The determin-
ism profoundly simplies the recovery execution, in fact,
normal and recovery routines become identical.
Future of Deterministic In-memory Key-Value Stores
Notably, deterministic data stores have their own advantages
and disadvantages that they may not be optimal for every
possible workload [
]. For instance, it is an open question
how to support transactions that demands multiple rounds
of back-and-forth client-server communication or how to
support traditional cursor-based access. Clients must reg-
ister stored procedures in advance and supply all input pa-
rameters at run-time, i.e., the read-set and the write-set of
a transaction must be known prior to execution, and the
use of non-deterministic functions, e.g.,
, is
non-trivial. Notably, there have been several lightweight
solutions to eciently determining read/write (when not
known as a priori) through a passive, pre-play execution
model [9, 11, 12, 16, 32, 33].
1.2 Contributions
In this paper, we make the following contributions:
we present a rich formalism to model our re-thinking
of how transactions are processed in eCC. Our for-
malism does not suer from the traditional data depen-
dency conicts among transactions because they are
seamlessly eliminated by our execution model (Sec-
tion 2).
we propose an ecient deterministic, queue-oriented
transaction execution model for highly parallel archi-
tectures, that is amenable to ecient pipelining and
oers a exible and adaptable thread-to-queue assign-
ment to minimize coordination (Section 3).
we design a novel two-phase, priority-based, queue-
oriented planning and execution model that eliminates
the need for concurrency control (Section 4).
we prototype our proposed concurrency architecture
within a comprehensive concurrency control testbed,
which includes eight modern concurrency techniques,
to demonstrate eCC eectiveness compared to state-
of-the-art approaches based on well-established bench-
marks such as TPC-C and YCSB (Section 5).
2 Formalism
Before describing the design and architecture of eCC, we
rst present data and transaction models used by eCC.
2.1 Data Model
The data model used is the widely adopted key-value storage
model. In this model, each record in the database is logically
dened as a pair
, where
uniquely identies a record
is the value of that record. Internally, we access records
by knowing its physical record identiers (RID), i.e., the
physical address in either memory or disk.
Operations are modeled as two fundamental types of oper-
ations; namely,
operations. However, there
are other kinds of operations such as
, and
. Those operations are treated as dierent forms of
the WRITE operation[1].
2.2 Transaction Model
Transactions can be modeled as a DAG (Directed Acyclic
Graphs) of “sub-transactions” called transaction fragments.
Each fragment performs a sequence of operations on a set of
records (each internally associated with a RID). In addition
to the operations, each fragment is associated with a set
of constraints that captures the application integrity. We
formally dene transaction fragments as follows:
Denition 1. (Transaction fragments):
A transaction fragment
is dened as a pair
(Sop ,C)
, where
is a nite sequence of operations either
on records
identied with RIDs that are mapped to the same contiguous RID
range, and
is a nite set of constraints that must be satised post
the fragment execution.
Fragments that belong to the same transaction can have
two kinds of dependencies, and such dependencies are based
on the transaction’s logic. We refer to them as logic-induced
dependencies, and they are of two types: (1) data dependen-
cies and (2) commit dependencies [
]. Because these logic-
induced dependencies may also exist among transaction frag-
ments that belong to the same transaction, we call them
intra-transaction dependencies to dierentiate them from
inter-transaction dependencies that exist between fragments
that belong to dierent transactions. Inter-transaction de-
pendencies are induced by the transaction execution model.
Thus, they are also called execution-induced dependencies.
An intra-transaction data dependency between fragment
, and another fragment
such that
is data-dependent
implies that
requires some data that is computed
. To illustrate, consider a transaction that reads a value
of a particular record, say,
and updates the value
another record, say,
such that
1. This transaction
can be decomposed into two fragments
, and
with a data
dependency between
such that
depends on
. We
formalize the notion of intra-transaction data dependencies
as follows:
Denition 2. (Intra-transaction data dependency):
An intra-transaction data dependency exist between two transaction
, denoted as
, if and only if both frag-
ments belong to the same transaction and the logic of
requires data
computed by the logic of fi.
The second type of logic-induced dependency is called an
intra-transaction commit dependency. This kind of depen-
dency captures the atomicity of a transaction when some of
its fragments may abort due to logic-induced aborts. We re-
fer to such fragments as abortable fragments. Logic-induced
aborts are the result of violating integrity constraints dened
by applications, which are captured by the set of constraints
for each fragment. Intuitively, if a fragment is associated
with at least one constraint that may not be satised post
the execution of the fragment, then it is abortable.
A formal denition of abortable fragments is as follows:
Denition 3. (Abortable transaction fragments):
A transaction fragment fiis abortable if and only if fi.C,ϕ.
Using the denition of abortable fragments, intra-transaction
commit dependencies are formally dened as follows:
Denition 4. (Intra-transaction commit dependency):
An intra-transaction commit dependency exist between two trans-
action fragments
, denoted as
, if and only if both
fragments belong to the same transaction and fiis abortable.
The notion of transaction fragments is similar in spirit
to the notion of pieces [
], the notion of actions
in DORA[
], and the notion of record actions in LADS[
However, unlike those notions, we impose a RID-range re-
striction on records accessed by fragments and formally
model the set of constraints associated with fragments.
Now, we can formally dene transactions based on the
fragments and their dependencies, as follows:
Denition 5. (Transactions):
A transaction
is dened as a directed acyclic graph (DAG)
, where
is nite set of transaction fragments
{f1,f2, . . . , fk}
and Eti={(fp,fq)| fp
In eCC, there is a third type of dependencies that may
exist between transaction fragments of dierent transactions,
which are induced by the execution model. Therefore, they
are called execution-induced dependencies. Since we are
modeling transactions at the level of fragments, we capture
them at that level. However, they are called “commit de-
pendencies” by Larson et al. [
] when not considering the
notion of transaction fragments. They are the result of spec-
ulative reading of uncommitted records. We formally dene
them as follows:
Denition 6. (Inter-transaction commit dependency):
An inter-transaction commit dependency exist between two transac-
tion fragments
is denoted as
, if and only if both
fragments belong to dierent transactions and
speculatively reads
uncommitted data written by fi
Note that inter-transaction commit dependencies may
cause cascading aborts among transactions. This problem can
be mitigated by exploiting the idea of “early write visibility”,
which is proposed by Faleiro et al.[10].
Also, note that execution-induced data dependencies among
transactions, used to model conicts in traditional concur-
rency control mechanisms, are no longer possible in eCC
because these conicts are seamlessly resolved and elimi-
nated by the deterministic, priority-based, queue-oriented
execution model of eCC. Non-deterministic data stores
that rely on traditional concurrency control mechanisms, suf-
fer from non-deterministic aborts caused by their execution
model that employs non-deterministic concurrency control.
A notable observation is that deterministic stores eliminate
non-deterministic aborts, which improves the eciency of
the transaction processing engine.
3 Priority-based, Queue-oriented
Transaction Processing
We rst oer a high-level description of our transaction
processing architecture. Our proposed architecture (depicted
in gure 1) is geared towards a throughput-optimized in-
memory key-value stores.
Transaction batches are processed in two deterministic
phases. First, in the planning phase, multiple planner threads
consume transactions from their respective client transac-
tion queue in parallel and create prioritized execution queues.
Each planner thread is assigned a predetermined distinct pri-
ority. The idea of priority is essential to the design of eCC
and it has two advantages. First, it allows planner threads to
independently and in parallel perform their planning task.
By assigning the priority to the execution queue, the order-
ing of transactions planned by dierent planner threads is
preserved. Secondly, the priory enables execution threads
to decide the order of executing fragments, which leads to
correct serializable execution.
The planner thread acts as a local sequencer with a prede-
termined priority for its assigned transactions and spreads
operations of each transaction (e.g., reads and writes) into a
set of queues based on the sequence order.
Each queue represents a distinct set of records, and queues
inherit their planner distinct priorities. The goal of the plan-
ner is to distribute operations (e.g.,
) into a set
of almost equal-sized queues. Queues for each planner can
be merged or split arbitrarily to satisfy balanced size queues.
However, queues across planners can only be combined to-
gether following the strict priority order of each planner. We
introduce execution-priority invariance that states for each
record, operations that belong to higher priority queues (created
by a higher priority planner) must always be executed before ex-
ecuting any lower priority operations. This execution-priority
invariance is the essence of how we capture determinism
in eCC. Since all planners operate at dierent priorities,
then they can be plan independently in parallel without any
The execution queues are handed over to a set of execu-
tion threads based on their priorities. Each execution thread
can arbitrarily select any outstanding queues within a batch
and execute its operations without any coordination with
others executors. The only criterion that must be satised
is the execution-priority invariance, implying that if a lower
priority queue overlaps with any higher priority queues (i.e.,
containing overlapping records), then before executing a
lower priority queue, the operations in all higher priority
queues must be executed rst. Depending on the number of
operations per transaction and its access patterns, indepen-
dent operations from a single transaction may be processed
in parallel by multiple execution threads without any syn-
chronization among the executors; hence, coordination-free
and independent execution across transactions. Once all the
execution queues are processed, it signals the completion
of the batch, and transactions in the batch are committed
except those that violated an integrity constraint. The vio-
lations are identied by executing a set of commit threads
once each batch is completed.
To ensure recoverability, all parameters required to recre-
ate the execution queues are persisted at the end of the
planning phase. A second persistent operation is done at the
end of the execution phase once the batch is fully processed;
which is similar to the group commit technique [7].
3.1 Proof of serializability
In this section, we show that eCC produces serializable
execution histories. We use
to denote the commit or-
dering of transaction
, and
e(fi j )
to denote the completion
time for the execution of fragment
fi j
, where
fi j
belongs to
. For the sake of this proof, we use the notion of conicting
fragments to have the same meaning as conicting opera-
tions in serializability theory [
]. Without loss of generality,
we assume that each fragment accesses a single record, but
the same argument applies in general because of the RID
range restriction (see Denition 1).
Theorem 1.
The transaction execution history produced by
eCC is serializable.
Suppose that the execution of two transactions
is not serial, and their commit ordering is
Note that their commitment ordering is the same as their
ordering when they were planned. Therefore, there exist two
conicting fragments
such that
e(fjq )>e(fi p )
access the same record, we have the
following cases: (Case 1) if
are planned by the same
planner thread, they must be placed in the same execution
queue (EQ). Since the commitment ordering is the same as
the order they were planned, the planner must have placed
ahead of
in the execution queue which contradicts
the conicting order. (Case 2) if
are planned by dif-
ferent planner threads, their respective fragments are placed
in two dierent EQs with the EQ containing
having a
higher priority than the other EQ containing
. Having
e(fjq )>e(fi p )
implies that the priority execution invariance
is violated, which is also a contradiction.
Trans ac ti o n'
Figure 1. Overview of Priority-based, Queue-oriented Architecture
4 Control-free Architectural Design
In this section, we present planning and execution tech-
niques introduced by eCC.
4.1 Deterministic Planning Phase
In the planning phase, our aim is to answer the key ques-
tions: how to eciently produce execution plans and distribute
them across execution threads in a balanced manner? How to
eciently deliver the plans to execution threads?
A planner thread consumes transactions from its dedi-
cated client transaction queue , which eliminates contention
from using a single client transaction queue. Since each plan-
ner thread has its own pre-determined priority, at this point,
transactions are partially ordered based the planners’ prior-
ities. Each planner can independently determine the order
within its own partition of the batch. The set of execution
queues (EQs) lled by planners inherit their planner’s prior-
ity thus forming a priority group (PG) of EQs. To represent
priority inheritance of EQs, we associate all EQs planned by
a planner with a priority group (PG). Each batch is organized
into priority groups of EQs with each group inheriting the
priority of its planner. We formally dene the notion of a
priority group as follows:
Denition 7. (Priority Group):
Given a set of transactions in a batch,
T={t1,t2, . . . ,tn}
and a set of planner threads
{pt1,pt2, . . . . ptk}
, the planning
phase will produce a set of
priority groups
{pд1,pд2, . . . pдk}
where each
is a partition of
and is produced by planner
thread pti.
In eCC, EQs are the main data structure used to repre-
sents the workload of transaction fragments. Planners ll
EQs with transaction fragments augmented with some ad-
ditional meta-data during the planning and assign EQs to
execution threads on batch delivery. EQs have a xed ca-
pacity and are recycled across batches. Under extreme con-
tention, they are dynamically expanded to hold transaction
fragments beyond their initial capacity. Planners may physi-
cally split or logically merge EQs in order to balance the load
given to execution queues. Splitting EQs is costly because
it requires copying transaction fragments from one queue
to two new queues that resulted from the split. The cost of
allocating memory for EQs is minimized by maintaining a
thread-local pool of EQs, which allows recycling EQs after
batch commitment.
We now focus on how each planner produces the priority-
based EQs associated with its PG. Our planning technique is
based on RID value ranges.
Range-based Planning
In our range-based planning ap-
proach, each planner starts by partitioning the whole RID
space into a number of ranges equal to the number of exe-
cution threads. For example, if we have 4execution threads,
then we will initially have 4range partitions of the whole RID
space. Based on the number of transactions accessing each
range, that range can be further partitioned progressively
into smaller ranges to ensure that they can be assigned to
execution threads in a balanced manner (i.e., each execution
thread will have the same number of transaction fragments
to process). Note that each range is associated with an EQ,
and partitioning a range implies splitting their associated
EQs as well. Range partitioning is progressive such that a
partitioning of a previous batch is reused for future ones,
which amortize the cost of range partitioning across multiple
batches, and reduces the planning time for the subsequent
A range needs to be partitioned if its associated EQ is full.
In eCC, we have a adaptable system conguration param-
eter that controls the capacity of EQs. When EQs become
full during planning, they are split into additional queues.
The split algorithm is simple. Given an EQ to split, a planner
partitions its associated range in half. Each range split will
be associated with a new EQ obtained from a local thread
pool of preallocated EQs
. Based on the new ranges, planners
copy transaction fragments from the original EQ into the
two new EQs.
A planner needs to determine when a batch is ready.
Batches can be considered complete based on time (i.e., com-
plete a batch every 5milliseconds) or based on counts (i.e.,
complete a batch every 1000 transaction). The choice of how
batches are determined is orthogonal to our techniques. How-
ever, in our implementation, we use count-based batches
with the batch size being a congurable system parameter.
Using count-based batches allows us to easily study the im-
pact of batching. For count-based batches, a planner thread
can easily compute the number of transactions in its parti-
tion of the batch since the number of planners and the batch
size, are known parameters. Once the batch is planned and
ready, it can be delivered to execution threads for execution.
Operation Planning
tions are straightforward, but special handling is needed for
1If the pool is empty, a new EQ is dynamically allocated.
operations. When planning a
or an
operation, a planner will simply do an index lookup
to nd the RID value for the record and its pointer. Based on
the RID value, it determines the EQ responsible for the trans-
action fragment. It will check if the EQ is full and perform
a split if needed. Finally, it inserts the transaction fragment
into the EQ.
operations are handled the same way
operations from planning perspective. For the
operations, a planner assigns a new RID value to the
new record and places the fragment into the respective EQ.
4.2 Deterministic Execution Phase
Once the batch is delivered, execution threads start pro-
cessing transaction fragments from assigned EQs without
any need for controlling its access to records. Fragments
are executed in the same order they are planned within a
single EQ. Execution threads try to execute the whole EQ
before moving to the next EQ. The execution threads may en-
counter a transaction fragment that has an intra-transaction
data dependency to another fragment that resides in another
EQ. Data dependencies exist when intermediate values are
required to execute the fragment in hand. Once the interme-
diate values are computed by the corresponding fragments,
they are are stored in the transaction’s meta-data accessible
by all transaction fragments. Data dependencies may trigger
EQ switching before the whole EQ is consumed. In particular,
an EQ switch occurs if intermediate values required by the
fragment in hand are not available.
To illustrate, consider the example transaction from sec-
tion 2, which has the following logic:
writ e(kj,b)}
, where keys are denoted as
. In this
transaction, we have a data dependency between the two
transaction fragments. The
operation on
be performed until the
operation on
is completed.
Suppose that
are placed in two separate EQs, e.g.,
respectively. An attempt to execute
can happen, which triggers an EQ switch by the attempt-
ing execution thread. Note that, this delaying behavior
unavoidable because there is no way for
to complete with-
out the completion of
. This mechanism of EQ switching
ensures that the execution thread will only wait if data depen-
dencies associated with transaction fragments at the head
of all EQs are not satised. Our EQ switch mechanism is
very lightweight and requires only a single private counter
per EQ to keep track of how many fragments of the EQ are
Execution Priority Invariance
Each execution thread
(ET) is assigned one or more EQ in each PG. ETs can exe-
cute fragments from multiple PGs. Since EQs are planned
independently by each planner, the following degenerate
case may occur. Consider two planner threads, say,
with their respective PGs (i.e.,
), and two exe-
cution threads
. A total of four EQs are planned
Notably, although further processing of a queue maybe delayed, the ex-
ecutor is not blocked and may simply begin processing another queue.
in the batch. Each EQ is denoted as
EQi j
such that
to the planner thread index and
refers to the execution
thread index, according to the assignment. For example,
is assigned by
, and so forth. Therefore, we have the
following set of EQs:
EQ00 ,EQ01,EQ10,
. Now for
each EQ, there is an associated RID range
ri j
, and the indices
of the ranges correspond to planner and execution threads,
respectively. A violation of the execution priority invariance
occurs under the following conditions: (1)
start executing
; (2)
has not completed the execution of
; (3)
a fragment in
updates a record, while a fragment in
reads the same record (this implies that
). Therefore, to ensure the invariance, an executor
checks that all overlapped EQs from higher priority PGs have
completed their processing. If so, it proceeds with the execu-
tion of the EQ in hand, otherwise, it switches to another EQ.
Fully processing all planned EQs in a batch signies that all
transactions are executed, and execution threads can start
the commit stage for the whole batch. Notably, at any point
during the execution, the executor thread may act as commit
thread, by checking commit dependencies of fully executed
transactions as described next.
Commit Dependency Tracking
When processing a trans-
action, execution threads need to track inter-transaction
commit dependencies. When a transaction fragment spec-
ulatively reads uncommitted data written by a fragment
that belongs to another transaction in the batch, a commit
dependency is formed between the two transactions. This
dependency must be checked during commitment (or as soon
as all prior transactions are fully executed) to ensure that the
earlier transaction has committed. If the earlier transaction
is aborted, the later transaction must abort. This dependency
information is stored in the transaction context. To capture
such dependencies, eCC uses a similar approach to the
approach used by Larson et al. [
] for dealing with commit
dependencies. eCC maintains the transaction id of the last
transaction that updated a record in per-record meta-data.
During execution, the transaction ID is checked and if it
refers to a transaction that belongs to the current batch, a
commit dependency counter for the current transaction is in-
cremented and a pointer to the current transaction’s context
is added to the context of the other transaction. During the
commit stage, when a transaction is committing, the coun-
ters for all dependent transactions is decremented. When the
commit dependency counter is equal to zero, the transaction
is allowed to commit. Once all execution threads are done
with their assigned work, the batch goes through a commit
stage. This can be done in parallel by multiple threads.
4.3 QueCC Implementation Details
Plan Delivery After each planner, completes its batch par-
tition and construct its PG, it needs to be delivered to the
execution layer so that execution threads can start executing
transactions. In eCC, we use a simple lock-free delivery
mechanism using atomic operations. We utilize a shared
Figure 2.
Example of concurrent batch planning and execu-
tion with 4worker threads (2planner threads
threads). Priority groups are color-coded by planners. Execu-
tion threads process transactions from both priority groups.
data structure called BatchQueue, which is basically a cir-
cular buer that contains slots for each batch. Each batch
slot contains pointers to partitions of priority groups which
are set in a latch-free manner using atomic CAS operations.
Priority group partitions are assigned to execution threads.
Figure 2, illustrates an example of concurrent batch planning
and execution of batch
respectively. In this ex-
ample, planner threads denoted as
are planning
their respective priority groups for batch
; and concur-
rently, execution threads
are executing EQs from
the previously planned batch (i.e., batch bi).
Delivering priority group partitions to the execution layer
must be ecient and lightweight. For this reason, eCC
uses a latch-free mechanism for delivery. The mechanism
goes as follows. Execution threads spin on priority group
partition slots while they are not set (i.e., their values is zero).
Once the priority groups are ready to be delivered, planner
threads merge EQs into priority group partitions such that
the workload is balanced, and each priority group partition is
assigned to one execution thread. Note that, we determinis-
tically assign EQs to execution threads. The alternative way
is to make all execution threads available to all execution
threads, but this approach has a risk of increasing contention
when there are many execution threads. To achieve balanced
workload among execution threads, we have a simple greedy
algorithm that keeps track of how many transaction frag-
ments are assigned to each execution thread. It iterates over
the remaining unassigned EQs until all EQs are assigned. In
each iteration, it assigns an EQ to the worker with the lowest
Once a planner is done with creating execution threads
assignments, it uses atomic CAS operations to set the values
of the slots in the BatchQueue to point to the list of assigned
EQs for each execution thread, which constitutes the priority
group partition assigned to the respective execution thread.
In the pipelined design, execution threads are either pro-
cessing EQs or waiting for their slots to be set by planner
threads. As soon as the slot is set, execution threads can start
processing EQs from the newly planned batch. On the other
hand, for the un-pipelined conguration, worker threads
acting as planner threads, will synchronize at the end of
the planning phase. Once the synchronization is completed,
worker threads will act as execution threads and start exe-
cuting EQs.
Note that in eCC, regardless of the number of planner
threads and execution threads, there is zero contention with
respect to the BatchQueue data structure.
RID Management
Our planning is based on record iden-
tiers (RIDs). RIDs can be physical or logical depending
on the storage architecture being row-oriented or column-
oriented. Typically, in row-oriented storage, physical RIDs
are used. While in column-oriented storage, logical RIDs
are used. As opposed to traditional disk-oriented data stores,
where RIDs are typically physical and is composed of the disk
page identier and the record oset, main-memory stores
typically uses memory pointers as physical RIDs. On the
other hand, logical RIDs can be used as an optimization to
improve performance under contention. In eCC, we use
logical RIDs from a single space of 64-bit integers. These
logical RIDs which are used for planning purposes are stored
alongside index entries.
4.4 Discussion
eCC supports “speculative write visibility” (SWV) when
executing transaction fragments because it defers commit-
ment to the end of the batch and allows reading uncommitted
data written within a batch. In general, transaction fragments
that may abort can cause cascading aborts. To ensure recov-
erability, eCC maintains an undo buer per transaction,
which is populated by the pre-write values of records (or its
elds) being updated. A transaction can abort only if at least
one of its fragments is abortable and have exercised its abort
If a transaction aborts, the original values are recovered
from the undo buers. This approach makes conservative
assumptions about the abortability of transaction fragments
(i.e., it assumes that all transaction fragments can abort). The
overhead of maintaining undo-buers can be eliminated if
the transaction fragment is guaranteed to commit (i.e., it
does not depend on other fragments). We can maintain in-
formation the abortability of a transaction fragment in its
respective transaction meta-data. Thus, instead of perform-
ing populating the undo buers “blindly”, we can check the
possibility of an abort by looking at the transaction context,
and skip the copying to undo buers if the transaction is
guaranteed to commit (i.e., passed its commit point[10]).
However, eCC is not limited to only SWV and can sup-
port multiple write visibility policies. Faleiro et al. [
] in-
troduced a new write visibility policy called “early write
visibility” (EWV), which can improve the throughput of
transaction processing by allowing reads on records only if
their respective writes are guaranteed to be committed with
serializability guarantees. Unlike SWV, which is prone to
Table 1.
YCSB Workload congurations. Notes: default values
are in parenthesis; in partitioned stores, it reects the number of
partitions; batch size parameters are applicable only to eCC;
multi-partition transaction parameter is applicable only to the
partitioned stores.
Parameter Name Parameter Values
# of worker threads 4,8,16,24,(32)
Zipan’s theta 0.0,0.4,0.8,0.9,(0.99)
%of write operations 0%,5%,20%,(50%),80%,95%
Rec. sizes 50B,(100B),200B,400B,800B,1KB,2KB
Operations per txn 1,10,(16),20,32
Batch sizes 1K,4K,(10K),20K,40K,80K
%of multi-partition txns. 1%,5%,10%,20%,50%,80%,100%
cascading aborts, EWV is not. In fact, both EWV and SWV
can be used at the same time by eCC. A special token is
placed ahead of the original fragment to make ETs adhere
to the EWV policy. If that special token is not placed, then
ETs will follow SWV course. One major advantage of using
EWV in the context of eCC is eliminating the process of
backing-up copies of records in the undo-buers. Since the
transaction that updated record is guaranteed to commit,
there will be no potential rollback and the undo-action is
5 Experimental Analysis
To evaluate eCC, we have substantially extended an ex-
isting concurrency testbed, referred to as Deneva [
which is the successor of DBx1000 [41].
This is a comprehensive framework for evaluating concur-
rency control schemes, and it includes many concurrency
control techniques. We compare eCC to a variants of two-
phase locking [
] (i.e., NO-WAIT [
] as a representative of
pessimistic concurrency control), TicToc [
], Cicada [
], FOEDUS with MOCC [
], ERMIA with SSI and
SSN [18], and H-Store [16].
5.1 Experimental Setup
We run all of our experiments using a Microsoft Azure G5
VM instance. This VM is equipped with an Intel Xeon CPU
E5-2698B v3 running at 2GHz, and has 32 cores. The memory
hierarchy includes a 32KB L1 data cache, 32KB L2 instruc-
tion cache, 256KB L2 cache, 40MB L3 cache, and 448GB of
RAM. The operating system is Ubuntu 16.04.3 LTS (xenial).
The codebase is compiled with GCC version 5.4.0 and
compiler optimization ag.
The workloads are generated at the server before any
transaction is processed, and are stored in main-memory
buers. This is done to remove any eects of the network,
and allows us to study concurrency control protocols under
high stress.
Every experiment starts with a warm-up period where
measurements are not collected; followed by a measured
period. Each experiment is run three times, and the average
value is reported in the results of this section.
We focus on evaluating three metrics: throughput, latency,
and abort percentage. The abort percentage is computed as
the ratio between the total number of aborted transaction to
Table 2.
TPC-C Workload congurations, default values are
in parenthesis
Parameter Name Parameter Values
# of worker threads 4,8,16,24,(32)
%of payment txns. 0%,50%,100%
the sum of the total number of attempted transaction (i.e.,
both aborted and committed transactions).
5.2 Workloads Overview
We have experimented with both YCSB and TPC-C bench-
marks. Below, we briey discuss the workloads used in our
] is a web-application benchmark that is repre-
sentative of web applications used by YAHOO. While the
original workload does not have any transaction semantics,
ours is adapted to have transactional capability by including
multiple operations per transaction. Each operation can be
either a
or a
operation. The ratio
operations can also vary. The benchmark
consists of a single table.
The table in our experiments contains 16 million records.
Table 1 summarizes the various conguration parameters
used in our evaluation, and default values are in parenthesis.
The data access patterns can be controlled using the param-
of the Zipan distribution. For example, a workload
with uniform access has
0, while a skewed workload
has a larger value of theta e.g., θ=0.99.
] is the industry standard benchmark for evalu-
ating transaction processing systems. It basically simulates
a wholesale order processing system. Each warehouse is
considered to be a single partition. There are 9tables and 5
transaction types for this benchmark. The data store is parti-
tioned by warehouse, which is considered the best possible
partitioning scheme for the TPC-C workload [
]. Similar to
previous studies in the literature[
], we focus on the two
main transaction proles (
) out of the
ve proles, which correspond to 88% of the default TPC-C
workload mix [
]. These two proles are also the most com-
plex ones. For example, the
transaction performs
operations, 6
operations, and about 15% of these operations
can access a remote partition. The Payment transaction, on
the other hand, performs 3
and 1
operation. One of the reads uses the last name
of the customer, which requires a little more work to look
up the record.
In this paper, we primarily study high-contention work-
loads because when there is limited or no contention, then,
generally, the top approaches behave comparably with negli-
gible dierences. This choice also has an important practical
signicance [
] because real workloads are
often skewed, thus, exhibiting a high contention. Therefore,
in the interest of space, we present our detailed results for
(a) Throughput (b) Latency
Figure 3.
Varying batch sizes and high data access skew
Figure 4.
Time breakdown when varying number of worker
high-contention workloads and briey overview the results
for lower-contention scenarios.
5.3 YCSB Experiments
Using YCSB workloads, we start by evaluating the perfor-
mance of eCC with dierent batch sizes, which is a unique
aspect of eCC. Subsequently, we compare eCC with
other concurrency control protocols.
Eect of Batch Sizes
We gear our experiments to study
the eect of batch sizes on throughput and latency for eCC
because it is the only approach that uses batching. We use a
write-intensive workload, 32 worker threads, a record size
of 100 bytes, Zipan’s
99, and 16 operations per trans-
We observe that eCC exhibit low average latency (i.e.,
under 3ms) for batches smaller than 20
transactions 3b,
which is considered reasonable for many applications. For
the remaining experiments, we use a batch of size 10K.
Time Breakdown
Figure 4 illustrates the time break-
down spent on each phase of eCC under highly skewed
data accesses. Notably, eCC continues to achieve high-
utilization even under extreme contention model. For exam-
ple, even scaling to 32 worker threads, over the 80% of the
time is dedicated to useful work, i.e., planning and execution
Eect of Data Access Skew
We evaluate the eect of
varying record contention using Zipan’s
parameter of
the YCSB workload while keeping the number of worker
threads constant. We use 32 worker threads and assign one
to each available core. Figure 5a, shows the throughput re-
sults of eCC compared with other concurrency control
protocols. We use a write-intensive workload which has
operations per transaction. As ex-
pected eCC performs comparably with the best competing
approaches under low contention scenarios
8. Re-
markably, in high contention scenarios, eCC begins to
(a) Throughput (b) Abort Percentage
Figure 5.
Variable contention (
) on write-intensive YCSB
(a) High contention, θ=0.99 (b) Abort percentage, θ=0.99
Figure 6.
Scaling Worker Threads Under Write Intensive
signicantly outperforms all the state-of-the-art approaches.
eCC improves the next best approach by 3
99, and has 35% better throughput with
9. The main
reason for eCC’s high-throughput is that it eliminates con-
currency control induced aborts completely. On the other
hand, the other approaches suer from excessive transac-
tion aborts which lead to wasted computations and complete
stalls for lock-based approaches. This experiments also high-
lights the stability and predictability of eCC with respect
to degree of contention.
We evaluate the scalability of eCC by vary-
ing the number of worker threads while maintaining a skewed,
write-intensive access pattern. We observe that all other ap-
proaches scale poorly under highly concurrent access sce-
nario (6a) despite employing techniques to reduce the cost
of contention (e.g., Cicada). In contrast, eCC scales well
despite the higher contention due to increased number of
threads. For instance, eCC achieves nearly 3
the through-
put of Cicada with 32 worker threads.
This results demonstrates the eectiveness of eCC’s
concurrency architecture that exploits the untapped paral-
lelism available in transactional workloads. Figure 6b shows
that the abort rate for Cicada,TicToc, and ERMIA as paral-
lelism increases. This high abort-rate behavior is caused by
the large number of worker threads competing to read and
modify a small set of records (cf. 6). Unlike eCC, any non-
deterministic scheduling and concurrency control protocols
will be a subject to signicant amplied abort rates when
the number of conicting operations by competing threads
Eect of Write Operation Percentage
Another factor
that contributes to contention is the percentage of write op-
erations. With read-only workloads, concurrency control
(a) High contention, θ=0.99 (b) Abort percentage, θ=0.99
Figure 7.
Results for varying the percentage of write opera-
tions in each transaction
(a) Throughput (b) Abort Percentage
Figure 8.
Results for varying the size of records under high
protocols exhibit limited contention even if the data access is
skewed. However, as the number of conicting write opera-
tions on records increases, the contention naturally increases,
e.g., exclusive locks need to be acquired for NO-WAIT, more
failed validations for SILO and Cicada, and in general, any
approach relying on the optimistic assumption that conicts
are rare will suer. Since eCC does not perform any con-
currency control during execution, no contention arise from
the write operations.
In addition to increased contention, write operations trans-
lates into increased size of undo logging for recovery. This is
an added cost for any in-place update approach and eCC
is no exception. As we increase the write percentage, more
records are backed up in the undo-buers log and, thus, neg-
atively impacts the overall system throughput. Of course,
through multi-version storage model by avoiding in-place
updates, the undo-buer overhead can be mitigated. Never-
theless, eCC signicantly outperforms other concurrency
control protocols by up to 4
under write-intensive work-
loads, i.e., once the write percentage exceeds 50%.
Eect of Record Sizes
Having larger record sizes may
also negatively aect the performance of logging component
as shown in Figure 8. Since the undo log maintains a copy of
every modied record, the logging throughput suers when
large records are used.
One approach to handle the logging is to exploit the notion
of “abortabity” of the transaction last updated the record,
and re-purpose the key principle of EWV[
Even under
logging pressure that begins to become one of the dominant
factor when the records size reaches 2
,eCC continues
to maintains its superiority and outperform Cicada by factor
Similarly in eCC, we check if all fragments of the last writer transaction
has been executed successfully, if so, we avoid writing to the undo buers,
and we further avoid adding the commit dependency.
(a) High contention, θ=0.99 (b) Abort percentage, θ=0.99
Figure 9.
Results for varying the number of operations in
each transaction.
(a) Throughput (b) Abort percentage
Figure 10.
Results of multi-partition transactions with com-
parison to H-Store.
of 3
despite the contention regulation mechanism employed
by Cicada.
Eect of Transaction Size
So far, each transaction con-
tains a total of 16 operations. Now we evaluate the eect
of varying the number of operations per transaction, essen-
tially the depth of a transaction. Figure 9 shows the results
of having 1
20, and 32 operations per transaction un-
der high data skew. For these experiments, we report the
throughput in terms of the number of operations completed
or records accessed per second. For all concurrency control
protocols, the throughput is lowest when there is only a
single operation per transaction, which indicates that the
work for ensuring transactional semantics is becoming the
More interestingly, when increasing the transaction depth,
the probability of conicting access is also increased; thereby,
higher contention and higher abort rates. In contrast, under
higher contention, eCC continues to have zero percent
abort rates. It further benets from improved cache-locality
and yields higher throughput because the smaller subset
of records are handled by the same worker thread. eCC
further exploits intra-transaction parallelism and altogether
improves up to 2
over the next best performing protocol
(Cicada) when increasing the transaction depth.
Comparison to Partitioned Stores
eCC is not sen-
sitive to multi-partition transactions despite its per-queue,
single-threaded execution model, which is one of its key
distinction. To establish eCC’s resilience to non-partition
workloads, we devise an experiment in which we vary the de-
gree of multi-partition transactions. Figure 10 illustrates that
eCC throughput virtually remains the same regardless of
the percentage of multi-partition transactions. We observed
that eCC improves over H-Store by factor 4
even when
there is only 1% multi-partition transactions in the work-
load. Remarkably, with 100% multi-partition transactions,
(a) Throughput - 100% NewOrder (b) Throughput - 50% NewOrder +50% Payment (c) Throughput - 100% Payment
(d) Abort Percentage - 100% NewOrder (e)
Abort Percentage - 50%
NewOrder +
Payment (f) Abort Percentage - 100% Payment
Figure 11. Results for 32 worker threads for TPC-C benchmark. Number of warehouses =1.
eCC improves on H-Store by two orders of magnitude.H-
Store is limited to a thread-to-transaction assignment and
resolves conicting access at the partition level. For multi-
partition transactions, H-Store is forced to lock each partition
accessed by a transaction prior to starting its execution. If
the partition-level locks cannot be acquired, the transaction
is aborted and restarted after some randomized delay. The
H-Store coarse-grained partition locks oer an elegant model
when assuming partition-able workload, but it noticeably
limits concurrency when this assumption no longer holds.
5.4 TPC-C Experiments
In this section, we study eCC using the industry standard
TPC-C. Our experiments in this section focus on through-
put and abort percentage under high contention with three
dierent workload mixes.
From a data access skew point of view, the TPC-C bench-
mark is inherently skewed towards warehouse records be-
cause both
transactions access the
warehouse table. The scale factor for TPC-C is the number
of warehouses, but it also determines the data access skew.
As we increase the number of warehouses, we get less data
access skew (assuming a xed number of transactions in the
generated workload). Therefore, to induce high contention
in TPC-C, we limit the number of warehouses to 1in the
workload and use all the 32 cores for processing the work-
Figure 11 captures the throughput and the abort percent-
age. With a workload mix of 100%
Figure 11c, eCC performs 6
better than the other ap-
proaches. With the a 50%
transaction mix, eCC
improves by nearly 2
over FOEDUS with MOCC. Despite
the skewness towards the single warehouse record (where
every transaction in the workload would accesses it), eCC
can process fragments accessing other tables in parallel be-
cause it distributes them among multiple queues, and assign
those queues to dierent threads. In addition, eCC per-
forms no spurious aborts which contributes its high perfor-
6 Related Work
There have been extensive research on concurrency control
approaches, and there many excellent publications dedicated
to this topic (e.g., [
]). However, research interest in
concurrency control in the past decade has been revived
due to emerging hardware trends, e.g., mutli-core and large
main-memory machines. We will cover key approaches in
this section.
Novel Transaction Processing Architectures
one of the rst paper that started to question the status quo
for concurrency mechanism was H-Store [
]. H-Store imag-
ined a simple model, where the workload always tends to
be partitionable and advocated single-threaded execution in
each partition; thereby, drop the need for any coordination
mechanism within a single partition. Of course, as expected
its performance degrades when transactions span multiple
Unlike H-Store,eCC through a deterministic, priority-
based planning and execution model that not only eliminates
the need for concurrency mechanism, but also it is not lim-
ited to partitionable workloads and can swiftly readjust and
reassign thread-to-queue assignment or merge/spit queues
during the planning and/or execution, where queue is es-
sentially an ordered set of operations over a ne-grained
partition that is created dynamically.
Unlike the classical execution model, in which each trans-
action is assigned to a single thread, DORA [
] proposed a
novel reformulation of transactions processing as a loosely-
coupled publish/subscribe paradigm, decomposes each trans-
action through a set of rendezvous points, and relies on
message passing for thread communications. DORA assigns
a thread to a set of records based on how the primary key
index is traversed, often a b-tree index, where essentially
the tree divided into a set of contiguous disjoint ranges, and
each range is assigned to a thread. The goal of DORA is to
improve cache eciency using thread-to-data assignment
as opposed to thread-to-transaction assignment. However,
DORA continues to rely on classical concurrency controls to
coordinate data access while eCC is fundamentally dier-
ent by completely eliminating the need for any concurrency
control through deterministic planning and execution for
a batch of transactions. Notably, eCC’s thread-to-queue
assignment also substantially improve cache locality.
Concurrency Control Protocols
The well-understood
pessimistic two-phase locking schemes for transactional con-
currency control on single-node systems are shown to have
scalability problems with large numbers of cores[
]. There-
fore, several research proposals focused on the optimistic
concurrency control (OCC) approach (e.g., [
which is originally proposed by [
]. Tu et al.’s SILO [
is a scalable variant of optimistic concurrency control that
avoids many bottlenecks of the centralized techniques by
an ecient implementation of the validation phase. TicToc
] improves concurrency by using a data-driven timestamp
management protocol. Both BCC [
] and MOCC [
] are
designed to minimize the cost of false aborts. All of these CC
protocols suer from non-deterministic aborts, which results
in wasting computing resources and reducing the overall
system’s throughput. On the other hand, eCC does not
have such limitation because it deterministically processes
transactions, which eliminates non-deterministic aborts.
Larson et al. [
] revisited concurrency control for in-
memory stores and proposed a multi-version, optimistic con-
currency control with speculative reads. Sadoghi et al. [
introduced a two-version concurrency control that allows the
coexistence of both pessimistic and optimistic concurrency
protocols, all centered around a novel indirection layer that
serves as a gateway to nd the latest version of the record and
a lightweight coordination mechanism to implement block
and non-blocking concurrency mechanism. Cicada by Lim
et al. mitigates the costs associated with multi-versioning
and contention by carefully examining various layers of the
system [
]. eCC is in sharp contrast with these research
eorts, eCC focuses on eliminates concurrency mecha-
nism as opposed to improving it.
ORTHRUS by Ren et al. [
] uses dedicated threads for
pessimistic concurrency control and message passing com-
munication between threads. Transaction execution threads
delegate their locking functionality to dedicated concurrency
control threads. In contrast to ORTHRUS,eCC plans a batch
of transactions in the rst phase and execute them in the sec-
ond phase using coordination-free mechanism. LADS by Yao
et al. [
] builds dependency graphs for a batch of transac-
tions that dictates execution orders. Faleiro et al. [
] propose
PWV which is based on the “early write visibility” technique
that exploits the ability to determine the commit decision
of a transaction before it completes all of its operations. In
terms of execution, both LADS and PWV process transactions
explicitly by relying on dependency graphs. On the other
hand, eCC does satisfy transaction dependencies but its
execution model is organized in term of prioritized queues.
In eCC, not only do we drop the partitionability assump-
tion, but we also eliminate any graph-driven coordination
by introducing a novel deterministic, priority-based queuing
execution. Notably, the idea of “early write visibility” can be
exploited by eCC to further reduce chances of cascading
The ability to parallelize transaction processing is limited
by various dependencies that may exist among transactions
fragments. IC3 [
] is a recent proposal for a concurrency
control optimized for multi-core in-memory stores. IC3 de-
composes transactions into pieces through static analysis,
and constrain the parallel execution of pieces at run-time to
ensure serializable.
Unlike IC3,eCC achieves transaction-level parallelism
by using two deterministic phases of planning and execution
and without relying on conict graphs explicitly.
Deterministic Transaction Processing
All the afore-
mentioned single-version transaction processing schemes in-
terleave transaction operations non-deterministically, which
leads to fundamentally unnecessary aborts and transaction
restarts. Deterministic transaction processing, e.g.,[
on the other hand, eliminates this class of non-deterministic
aborts and allow only logic-induced aborts (i.e., explicit
aborts by the transaction’s logic). Calvin[
] is designed
for distributed environments and uses determinism elim-
inate the cost of two-phase-commit protocol when process-
ing distributed transactions and does not address multi-
core optimizations in the individual nodes. Gargamel [
] pre-
serilaize possibly conicting transactions using a dedicated
load-balancing node in distributed environments. It uses a
classier based on static analysis to determine conicting
transactions. Unlike Gargamel,eCC is centered around the
notion of priority, and is designed for multi-core hardware.
] started re-thinking multi-version concurrency
control for deterministic multi-core in-memory stores. In
particular, BOHM process batches of transactions in three
sequential phases (1) a single-threaded sequencing phase to
determine the global order of transactions, (2) a parallel multi-
version concurrency control phase to determine the version
conicts, and (3) a parallel execution phase based on trans-
action dependencies, which optionally performs garbage
collection for unneeded record versions. In sharp contrast,
eCC process batches of transactions in only two deter-
ministic phases, and it has a parallel priority-based queue-
oriented planning and execution phases that do not suer
from additional costs such as garbage collection costs.
7 Conclusion
In this paper, we presented eCC, a queue-oriented, control-
free concurrency architecture for high-performance, in-memory,
key-value stores on emerging multi-sockets, many-core, shared-
memory architectures. eCC exhibits minimal contention
among concurrent threads by eliminating the overhead of
concurrency control from the critical path of the transac-
tion. eCC operates on batches of transactions in two de-
terministic phases of priority-based planning followed by
control-free execution. Instead of the traditional thread-to-
transaction assignment, eCC uses a novel thread-to-queue
assignment to dynamically parallelize transaction execution
and eliminate bottlenecks under high contention workloads.
We extensively evaluate eCC with two popular bench-
marks. Our results show that eCC can process almost
40 Million YCSB operation per second and over 5Million
TPC-C transactions per second. Compared to other concur-
rency control approaches, eCC achieves up to 4
throughput for YCSB workloads, and 6
higher throughput
for TPC-C workloads.
A. Adya, B. Liskov, and P. O’Neil. 2000. Generalized isolation level
denitions. In Proc. ICDE. 67–78.
Arthur J. Bernstein, David S. Gerstl, and Philip M. Lewis. 1999. Con-
currency Control for Step-decomposed Transactions. Inf. Syst. 24, 9
(Dec. 1999), 673–698. hp://
Philip A. Bernstein and Nathan Goodman. 1981. Concurrency Control
in Distributed Database Systems. ACM Comput. Surv. 13, 2 (June 1981),
185–221. DOI:hps://
P. Cincilla, S. Monnet, and M. Shapiro. 2012. Gargamel: Boosting DBMS
Performance by Parallelising Write Transactions. In 2012 IEEE 18th
International Conference on Parallel and Distributed Systems. 572–579.
Brian F. Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrish-
nan, and Russell Sears. 2010. Benchmarking Cloud Serving Systems
with YCSB. In Proc. SoCC. ACM, 143–154.
Carlo Curino, Evan Jones, Yang Zhang, and Sam Madden. 2010. Schism:
A Workload-driven Approach to Database Replication and Partitioning.
Proc. VLDB Endow. 3, 1-2 (Sept. 2010), 48–57.
David J. DeWitt, Randy H. Katz, Frank Olken, Leonard D. Shapiro,
Michael R. Stonebraker, and David A. Wood. 1984. Implementation
Techniques for Main Memory Database Systems. In Proc. SIGMOD.
ACM, 1–8. DOI:hps://
K. P. Eswaran, J. N. Gray, R. A. Lorie, and I. L. Traiger. 1976. The
Notions of Consistency and Predicate Locks in a Database System.
Commun. ACM 19, 11 (Nov. 1976), 624–633.
Jose M. Faleiro and Daniel J. Abadi. 2015. Rethinking Serializable
Multiversion Concurrency Control. Proc. VLDB Endow. 8, 11 (July
2015), 1190–1201. DOI:hps://
Jose M. Faleiro, Daniel J. Abadi, and Joseph M. Hellerstein. 2017. High
Performance Transactions via Early Write Visibility. Proc. VLDB En-
dow. 10, 5 (Jan. 2017), 613–624.
[11] Jose M. Faleiro, Alexander Thomson, and Daniel J. Abadi. 2014. Lazy
Evaluation of Transactions in Database Systems. In Proc. SIGMOD.
ACM, 15–26. DOI:hps://
Rachael Harding, Dana Van Aken, Andrew Pavlo, and Michael Stone-
braker. 2017. An Evaluation of Distributed Concurrency Control. Proc.
VLDB Endow. 10, 5 (Jan. 2017), 553–564.
Hewlett Packard Enterprise. 2017. HPE Superdome Servers. hps:
// (2017).
Hewlett Packard Labs. 2017. The Machine: A new kind of computer.
hp:// (2017).
R. Jimenez-Peris, M. Patino-Martinez, and S. Arevalo. 2000. Determin-
istic scheduling for transactional multithreaded replicas. In Proc. IEEE
SRDS. 164–173. DOI:hps://
Robert Kallman, Hideaki Kimura, Jonathan Natkins, Andrew Pavlo,
Alexander Rasin, Stanley Zdonik, Evan P. C. Jones, Samuel Madden,
Michael Stonebraker, Yang Zhang, John Hugg, and Daniel J. Abadi.
2008. H-store: A High-performance, Distributed Main Memory Trans-
action Processing System. Proc. VLDB Endow. 1, 2 (Aug. 2008), 1496–
1499. DOI:hps://
Bettina Kemme and Gustavo Alonso. 2000. Don’T Be Lazy, Be
Consistent: Postgres-R, A New Way to Implement Database Repli-
cation. In Proc. VLDB. Morgan Kaufmann Publishers Inc., 134–143.
Kangnyeon Kim, Tianzheng Wang, Ryan Johnson, and Ippokratis Pan-
dis. 2016. ERMIA: Fast Memory-Optimized Database System for Het-
erogeneous Workloads. In Proceedings of the 2016 International Confer-
ence on Management of Data (SIGMOD ’16). ACM, New York, NY, USA,
1675–1687. DOI:hps://
Hideaki Kimura. 2015. FOEDUS: OLTP Engine for a Thousand Cores
and NVRAM. In Proceedings of the 2015 ACM SIGMOD International
Conference on Management of Data (SIGMOD ’15). ACM, New York,
NY, USA, 691–706. DOI:hps://
Vijay Kumar (Ed.). 1995. Performance of Concurrency Control Mech-
anisms in Centralized Database Systems. Prentice-Hall, Inc., Upper
Saddle River, NJ, USA.
H. T. Kung and John T. Robinson. 1981. On Optimistic Methods for
Concurrency Control. ACM Trans. Database Syst. 6, 2 (June 1981),
213–226. DOI:hps://
Per A. Larson, Spyros Blanas, Cristian Diaconu, Craig Freedman, Jig-
nesh M. Patel, and Mike Zwilling. 2011. High-performance Concur-
rency Control Mechanisms for Main-memory Databases. Proc. VLDB
Endow. 5, 4 (Dec. 2011), 298–309.
Hyeontaek Lim, Michael Kaminsky, and David G. Andersen. 2017.
Cicada: Dependably Fast Multi-Core In-Memory Transactions. In Proc.
SIGMOD. ACM, 21–35.
Mellanox Technologies. 2017. Multicore Processors Overview. hp:
// (2017).
Ippokratis Pandis, Ryan Johnson, Nikos Hardavellas, and Anastasia
Ailamaki. 2010. Data-oriented Transaction Execution. Proc. VLDB En-
dow. 3, 1-2 (Sept. 2010), 928–939.
Kun Ren, Jose M. Faleiro, and Daniel J. Abadi. 2016. Design Principles
for Scaling Multi-core OLTP Under High Contention. In Proc. SIGMOD.
ACM, 1583–1598. DOI:hps://
Kun Ren, Alexander Thomson, and Daniel J. Abadi. 2014. An Eval-
uation of the Advantages and Disadvantages of Deterministic Data-
base Systems. Proc. VLDB Endow. 7, 10 (June 2014), 821–832.
Mohammad Sadoghi, Mustafa Canim, Bishwaranjan Bhattacharjee,
Fabian Nagel, and Kenneth A. Ross. 2014. Reducing Database Locking
Contention Through Multi-version Concurrency. Proc. VLDB Endow.
7, 13 (Aug. 2014), 1331–1342.
Sgi. 2017. SGI UV 3000 and SGI UV 30. hps://
servers/uv/uv_3000_30.html. (2017).
Dennis Shasha, Francois Llirbat, Eric Simon, and Patrick Valduriez.
1995. Transaction Chopping: Algorithms and Performance Studies.
ACM Trans. Database Syst. 20, 3 (Sept. 1995), 325–363.
Alexander Thomasian. 1998. Concurrency Control: Methods, Perfor-
mance, and Analysis. ACM Comput. Surv. 30, 1 (March 1998), 70–119.
Alexander Thomson and Daniel J. Abadi. 2015. CalvinFS: Consistent
WAN Replication and Scalable Metadata Management for Distributed
File Systems. In Proc. FAST. USENIX Association, 1–14. hp://portal.
Alexander Thomson, Thaddeus Diamond, Shu C. Weng, Kun Ren,
Philip Shao, and Daniel J. Abadi. 2012. Calvin: Fast Distributed Trans-
actions for Partitioned Database Systems. In Proc. SIGMOD. ACM, 1–12.
TPCC. TPC-C, On-line Transaction Processing Benchmark. (????).
Stephen Tu, Wenting Zheng, Eddie Kohler, Barbara Liskov, and
Samuel Madden. 2013. Speedy Transactions in Multicore In-memory
Databases. In SOSP. ACM, 18–32.
Tianzheng Wang and Hideaki Kimura. 2016. Mostly-optimistic Con-
currency Control for Highly Contended Dynamic Workloads on a
Thousand Cores. Proc. VLDB Endow. 10, 2 (Oct. 2016), 49–60.
Zhaoguo Wang, Shuai Mu, Yang Cui, Han Yi, Haibo Chen, and Jinyang
Li. 2016. Scaling Multicore Databases via Constrained Parallel Execu-
tion. In Proc. SIGMOD. ACM, 1643–1658.
Gerhard Weikum and Gottfried Vossen. 2001. Transactional Infor-
mation Systems: Theory, Algorithms, and the Practice of Concurrency
Control and Recovery. Morgan Kaufmann Publishers Inc., San Francisco,
Arthur T. Whitney, Dennis Shasha, and Stevan Apter. 1997. High
Volume Transaction Processing without Concurrency Control, Two
Phase Commit, Sql or C++. In HPTS.
C. Yao, D. Agrawal, G. Chen, Q. Lin, B. C. Ooi, W. F. Wong, and M.
Zhang. 2016. Exploiting Single-Threaded Model in Multi-Core In-
Memory Systems. IEEE TKDE 28, 10 (2016), 2635–2650.
Xiangyao Yu, George Bezerra, Andrew Pavlo, Srinivas Devadas, and
Michael Stonebraker. 2014. Staring into the Abyss: An Evaluation of
Concurrency Control with One Thousand Cores. Proc. VLDB Endow. 8,
3 (Nov. 2014), 209–220.
Xiangyao Yu, Andrew Pavlo, Daniel Sanchez, and Srinivas Devadas.
2016. TicToc: Time Traveling Optimistic Concurrency Control. In
Proc. SIGMOD. ACM, 1629–1642.
Yuan Yuan, Kaibo Wang, Rubao Lee, Xiaoning Ding, Jing Xing, Spyros
Blanas, and Xiaodong Zhang. 2016. BCC: Reducing False Aborts
in Optimistic Concurrency Control with Low Cost for In-memory
Databases. Proc. VLDB Endow. 9, 6 (Jan. 2016), 504–515.
... 2PC is a pessimistic approach that pessimistically assumes aborts would happen and hence prepare a series of steps to handle that issue if it really happens. Deterministic database (DDB) [2,23,24,26,73,74,76,77,90,91], in contrast, is a preventive approach that leverages full transaction information (e.g., read-write sets) and carefully plans the execution schedule a priori to avoid any non-deterministic aborts to happen. Access localization (e.g., LEAP [50]) is another preventive approach that aggressively avoids any transaction to span across partitions by pre-localizing the remote data at the same site (i.e., all ship to one site), which also requires knowing the transactions read-write sets beforehand. ...
... The baselines are incorporated with common 2PC optimizations including Presumed-Abort [22] and Unsolicited-Vote [84]. Deterministic databases other than Aria [2,23,24,26,56,73,74,76,77,90,91] and access localization protocols [39,50] are not listed for comparison due to their limitations (e.g, read-write sets must be pre-determined, data location seldom changes). Star [58] and Lotus [110] also require prior knowledge of transactions (e.g., whether a transaction is local or distributed) to multiplex their execution paths and thus also not included. ...
... QueCC [73] also shows that determinism can be optimized to improve core scalability in non-distributed settings. However, they still rely on the assumption that transactions' read-write sets can be inferred before execution. ...
Full-text available
Two-phase-commit (2PC) has been widely adopted for distributed transaction processing, but it also jeopardizes throughput by introducing two rounds of network communications and two durable log writes to a transaction's critical path. Despite the various proposals that eliminate 2PC such as deterministic database and access localization, 2PC remains the de facto standard since the alternatives often lack generality (e.g., the workload cannot contain branches based on query results). In this paper, we present Primo, a distributed transaction protocol that supports a more general set of workloads without 2PC. Primo features write-conflict-free concurrency control that guarantees once a transaction enters the commit phase, no concurrency conflict (e.g., deadlock) would occur when installing the write-set -- hence commit consensus is no longer needed to prepare for any potential conflict from any partition. In addition, Primo further optimizes the transaction path using asynchronous group commit. With that, the durability delay is also taken off the transaction's critical path. Empirical results on Primo are encouraging -- in YCSB and TPC-C, Primo attains 1.42x to 8.25x higher throughput than state-of-the-art general protocols including Sundial and COCO, while having similar latency as COCO which also employs group commit.
... This might require a locking mechanism to achieve concurrency while ensuring deterministic serial order, but this results in high scheduling overhead. A number of approaches are proposed to reduce the scheduling overhead, e.g., Aria [51], QueCC [58], PWV [45], and LADS [74]. However, there exist several disadvantages of deterministic databases, including 1) lack of support for interactive SQL because it is required to disseminate the SQL statements before executing them, which limits their application; 2) the additional scheduling overhead for determinism; 3) undesirable performance due to imbalanced workloads among transactions, especially for long running transactions (because a previous batch of transactions must finish executing before a new batch can begin). ...
Multinational enterprises conduct global business that has a demand for geo-distributed transactional databases. Existing state-of-the-art databases adopt a sharded master-follower replication architecture. However, the single-master serving mode incurs massive cross-region writes from clients, and the sharded architecture requires multiple round-trip acknowledgments (e.g., 2PC) to ensure atomicity for cross-shard transactions. These limitations drive us to seek yet another design choice. In this paper, we propose a strongly consistent OLTP database GeoGauss with full replica multi-master architecture. To efficiently merge the updates from different master nodes, we propose a multi-master OCC that unifies data replication and concurrent transaction processing. By leveraging an epoch-based delta state merge rule and the optimistic asynchronous execution, GeoGauss ensures strong consistency with light-coordinated protocol and allows more concurrency with weak isolation, which are sufficient to meet our needs. Our geo-distributed experimental results show that GeoGauss achieves 7.06X higher throughput and 17.41X lower latency than the state-of-the-art geo-distributed database CockroachDB on the TPC-C benchmark.
Developers would benefit greatly from time travel: being able to faithfully replay past executions and retroactively execute modified code on past events. Currently, replay and retroaction are impractical because they require expensively capturing fine-grained timing information to reproduce concurrent accesses to shared state. In this paper, we propose practical time travel for database-backed applications , an important class of distributed applications that access shared state through transactions. We present R ³ , a novel Record-Replay-Retroaction tool. R ³ implements a lightweight interceptor to record concurrency information for applications at transaction-level granularity, enabling replay and retroaction with minimal overhead. We address key challenges in both replay and retroaction. First, we design a novel algorithm for faithfully reproducing application requests running with snapshot isolation, allowing R ³ to support most production DBMSs. Second, we develop a retroactive execution mechanism that provides high fidelity with the original trace while supporting nearly arbitrary code modifications. We demonstrate how R ³ simplifies debugging for real, hard-to-reproduce concurrency bugs from popular open-source web applications. We evaluate R ³ using TPC-C and microservice workloads and show that R ³ always-on recording has a small performance overhead (<25% for point queries but <0.1% for complex transactions like in TPC-C) during normal application execution and that R ³ can retroactively execute bugfixed code over recorded traces within 0.11--0.78× of the original execution time.
Private blockchain as a replicated transactional system shares many commonalities with distributed database. However, the intimacy between private blockchain and deterministic database has never been studied. In essence, private blockchain and deterministic database both ensure replica consistency by determinism. In this paper, we present a comprehensive analysis to uncover the connections between private blockchain and deterministic database. While private blockchains have started to pursue deterministic transaction executions recently, deterministic databases have already studied deterministic concurrency control protocols for almost a decade. This motivates us to propose Harmony, a novel deterministic concurrency control protocol designed for blockchain use. We use Harmony to build a new relational blockchain, namely HarmonyBC, which features low abort rates, hotspot resiliency, and inter-block parallelism, all of which are especially important to disk-oriented blockchain. Empirical results on Smallbank, YCSB, and TPC-C show that HarmonyBC offers 2.0x to 3.5x throughput better than the state-of-the-art private blockchains.
This paper studies how to improve the performance of main memory multicore OLTP systems for executing transactions with conflicts. A promising approach is to partition transaction workloads into mutually conflict-free clusters, and distribute the clusters to different cores for concurrent execution. We show that if transactions in each cluster are properly scheduled, transactions that are traditionally considered conflicting can be executed without conflicts at runtime. In light of this, we propose to schedule transactions and reduce runtime conflicts, instead of partitioning based on the conventional notion of conflicts. We formulate the transaction scheduling problem to minimize runtime conflicts, and show that the problem is NP-complete. This said, we develop an efficient scheduling algorithm to improve parallelism. Moreover, for transactions that are not packed in batches, we show that runtime conflict analysis also helps reduce conflict penalties, by proposing a proactive deferring method. Using standard and enhanced benchmarks, we show that on average our scheduling and proactive deferring methods improve the throughput of existing partitioners and concurrency control protocols by 131% and 109%, respectively, up to 294% and 152%.
Multinational enterprises conduct global business that has a demand for geo-distributed transactional databases. Existing state-of-the-art databases adopt a sharded master-follower replication architecture. However, the single-master serving mode incurs massive cross-region writes from clients, and the sharded architecture requires multiple round-trip acknowledgments (e.g., 2PC) to ensure atomicity for cross-shard transactions. These limitations drive us to seek yet another design choice. In this paper, we propose a strongly consistent OLTP database GeoGauss with full replica multi-master architecture. To efficiently merge the updates from different master nodes, we propose a multi-master OCC that unifies data replication and concurrent transaction processing. By leveraging an epoch-based delta state merge rule and the optimistic asynchronous execution, GeoGauss ensures strong consistency with light-coordinated protocol and allows more concurrency with weak isolation, which are sufficient to meet our needs. Our geo-distributed experimental results show that GeoGauss achieves 7.06X higher throughput and 17.41X lower latency than the state-of-the-art geo-distributed database CockroachDB on the TPC-C benchmark.
MVCC-based snapshot isolation promises that read queries can proceed without interfering with concurrent writes. However, as we show experimentally, in existing implementations a single long-running query can easily cause transactional throughput to collapse. Moreover, existing out-of-memory commit protocols fail to meet the scalability needs of modern multi-core systems. In this paper, we present three complementary techniques for robust and scalable snapshot isolation in out-of-memory systems. First, we propose a commit protocol that minimizes cross-thread communication for better scalability, avoids touching the write set on commit, and enables efficient fine-granular garbage collection. Second, we introduce the Graveyard Index, an auxiliary data structure that moves logically-deleted tuples out of the way of operational transactions. Third, we present an adaptive version storage scheme that enables fast garbage collection and improves scan performance of frequently-modified tuples. All techniques are engineered to scale well on multi-core processors, and together enable robust performance for complex hybrid workloads.
Full-text available
Hybrid OLTP and OLAP
Full-text available
Blockchain Transaction Processing.
Conference Paper
Full-text available
Large scale distributed databases are designed to support commercial and cloud based applications. The minimal expectation from such systems is that they ensure consistency and reliability in case of node failures. The distributed database guarantees reliability through the use of atomic commitment protocols. Atomic commitment protocols help in ensuring that either all the changes of a transaction are applied or none of them exist. To ensure efficient commitment process, the database community has mainly used the two-phase commit (2PC) protocol. However, the 2PC protocol is blocking under multiple failures. This necessitated the development of the non-blocking, three-phase commit (3PC) protocol. However, the database community is still reluctant to use the 3PC protocol, as it acts as a scalability bottleneck in the design of efficient transaction processing systems. In this work, we present Easy Commit which leverages the best of both the worlds (2PC and 3PC), that is, non-blocking (like 3PC) and requires two phases (like 2PC). Easy Commit achieves these goals by ensuring two key observations: (i) first transmit and then commit , and (ii) message redundancy. We present the design of the Easy Commit protocol and prove that it guarantees both safety and liveness. We also present a detailed evaluation of EC protocol, and show that it is nearly as efficient as the 2PC protocol.
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.3x over these previous algorithms.
Conference Paper
Multi-core in-memory databases promise high-speed online transaction processing. However, the performance of individual designs suffers when the workload characteristics miss their small sweet spot of a desired contention level, read-write ratio, record size, processing rate, and so forth. Cicada is a single-node multi-core in-memory transactional database with serializability. To provide high performance under diverse workloads, Cicada reduces overhead and contention at several levels of the system by leveraging optimistic and multi-version concurrency control schemes and multiple loosely synchronized clocks while mitigating their drawbacks. On the TPC-C and YCSB benchmarks, Cicada outperforms Silo, TicToc, FOEDUS, MOCC, two-phase locking, Hekaton, and ERMIA in most scenarios, achieving up to 3X higher throughput than the next fastest design. It handles up to 2.07 M TPC-C transactions per second and 56.5 M YCSB transactions per second, and scans up to 356 M records per second on a single 28-core machine.
Increasing transaction volumes have led to a resurgence of interest in distributed transaction processing. In particular, partitioning data across several servers can improve throughput by allowing servers to process transactions in parallel. But executing transactions across servers limits the scalability and performance of these systems. In this paper, we quantify the effects of distribution on concurrency control protocols in a distributed environment. We evaluate six classic and modern protocols in an in-memory distributed database evaluation framework called Deneva, providing an apples-to-apples comparison between each. Our results expose severe limitations of distributed transaction processing engines. Moreover, in our analysis, we identify several protocol-specific scalability bottlenecks. We conclude that to achieve truly scalable operation, distributed concurrency control solutions must seek a tighter coupling with either novel network hardware (in the local area) or applications (via data modeling and semantically-aware execution), or both.
In order to guarantee recoverable transaction execution, database systems permit a transaction's writes to be observable only at the end of its execution. As a consequence, there is generally a delay between the time a transaction performs a write and the time later transactions are permitted to read it. This delayed write visibility can significantly impact the performance of serializable database systems by reducing concurrency among conflicting transactions. This paper makes the observation that delayed write visibility stems from the fact that database systems can arbitrarily abort transactions at any point during their execution. Accordingly, we make the case for database systems which only abort transactions under a restricted set of conditions, thereby enabling a new recoverability mechanism, early write visibility, which safely makes transactions' writes visible prior to the end of their execution. We design a new serializable concurrency control protocol, piece-wise visibility (PWV), with the explicit goal of enabling early write visibility. We evaluate PWV against state-of-the-art serializable protocols and a highly optimized implementation of read committed, and find that PWV can outperform serializable protocols by an order of magnitude and read committed by 3X on high contention workloads.
Future servers will be equipped with thousands of CPU cores and deep memory hierarchies. Traditional concurrency control (CC) schemes---both optimistic and pessimistic---slow down orders of magnitude in such environments for highly contended workloads. Optimistic CC (OCC) scales the best for workloads with few conflicts, but suffers from clobbered reads for high conflict workloads. Although pessimistic locking can protect reads, it floods cache-coherence backbones in deep memory hierarchies and can also cause numerous deadlock aborts. This paper proposes a new CC scheme, mostly-optimistic concurrency control (MOCC), to address these problems. MOCC achieves orders of magnitude higher performance for dynamic workloads on modern servers. The key objective of MOCC is to avoid clobbered reads for high conflict workloads, without any centralized mechanisms or heavyweight interthread communication. To satisfy such needs, we devise a native, cancellable reader-writer spinlock and a serializable protocol that can acquire, release and re-acquire locks in any order without expensive interthread communication. For low conflict workloads, MOCC maintains OCC's high performance without taking read locks. Our experiments with high conflict YCSB workloads on a 288-core server reveal that MOCC performs 8× and 23× faster than OCC and pessimistic locking, respectively. It achieves 17 million TPS for TPC-C and more than 110 million TPS for YCSB without conflicts, 170× faster than pessimistic methods.
Conference Paper
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.3x over these previous algorithms.