Lightweight Locking for Main Memory Database Systems

Kun Ren†*

kun@cs.yale.eduAlexander Thomson*

thomson@cs.yale.eduDaniel J. Abadi*

dna@cs.yale.edu†Northwestern Polytechnical University, China *Yale University

ABSTRACT

Locking is widely used as a concurrency control mechanismin database systems. As more OLTP databases are storedmostly or entirely in memory, transactional throughput isless and less limited by disk IO, and lock managers increas-ingly become performance bottlenecks.

In this paper, we introduce very lightweight locking (VLL),an alternative approach to pessimistic concurrency controlfor main-memory database systems that avoids almost alloverhead associated with traditional lock manager opera-tions. We also propose a protocol called selective contention

analysis (SCA), which enables systems implementing VLLto achieve high transactional throughput under high con-tention workloads. We implement these protocols both ina traditional single-machine multi-core database server set-ting and in a distributed database where data is partitionedacross many commodity machines in a shared-nothing clus-ter. Our experiments show that VLL dramatically reduceslocking overhead and thereby increases transactional through-put in both settings.

1. INTRODUCTIONAs the price of main memory continues to drop, increas-

ingly many transaction processing applications keep the bulk(or even all) of their active datasets in main memory atall times. This has greatly improved performance of OLTPdatabase systems, since disk IO is eliminated as a bottle-neck.

As a rule, when one bottleneck is removed, others appear.In the case of main memory database systems, one commonbottleneck is the lock manager, especially under workloadswith high contention. One study reported that 16-25% oftransaction time is spent interacting with the lock managerin a main memory DBMS [8]. However, these experimentswere run on a single core machine with no physical con-tention for lock data structures. Other studies show evenlarger amounts of lock manager overhead when there aretransactions running on multiple cores competing for access

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 profit or commercial advantage and that copies

bear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specific

permission and/or a fee. Articles from this volume were invited to present

their results at The 39th International Conference on Very Large Data Bases,August 26th ­ 30th 2013, Riva del Garda, Trento, Italy.

Proceedings of the VLDB Endowment, Vol. 6, No. 2

Copyright 2012 VLDB Endowment 2150­8097/12/12... $ 10.00.

to the lock manager [9, 18, 14]. As the number of cores permachine continues to grow, lock managers will become evenmore of a performance bottleneck.

Although locking protocols are not implemented in a uni-form way across all database systems, the most common wayto implement a lock manager is as a hash table that mapseach lockable record’s primary key to a linked list of lockrequests for that record [4, 2, 3, 20, 7]. This list is typicallypreceded by a lock head that tracks the current lock state forthat item. For thread safety, the lock head generally storesa mutex object, which is acquired before lock requests andreleases to ensure that adding or removing elements fromthe linked list always occurs within a critical section. Everylock release also invokes a traversal of the linked list for thepurpose of determining what lock request should inherit thelock next.

These hash table lookups, latch acquisitions, and linkedlist operations are main memory operations, and would there-fore be a negligible component of the cost of executing anytransaction that accesses data on disk. In main memorydatabase systems, however, these operations are not negli-gible. The additional memory accesses, cache misses, CPUcycles, and critical sections invoked by lock manager opera-tions can approach or exceed the costs of executing the ac-tual transaction logic. Furthermore, as the increase in coresand processors per server leads to an increase in concurrency(and therefore lock contention), the size of the linked list oftransaction requests per lock increases—along with the as-sociated cost to traverse this list upon each lock release.

We argue that it is therefore necessary to revisit the de-sign of the lock manager in modern main memory databasesystems. In this paper, we explore two major changes tothe lock manager. First, we move all lock information awayfrom a central locking data structure, instead co-locatinglock information with the raw data being locked (as sug-gested in the past [5]). For example, a tuple in a mainmemory database is supplemented with additional (hidden)attributes that contain information about the row-level lockinformation about that tuple. Therefore, a single memoryaccess retrieves both the data and lock information in a sin-gle cache line, potentially removing additional cache misses.

Second, we remove all information about which transac-tions have outstanding requests for particular locks from thelock data structures. Therefore, instead of a linked list ofrequests per lock, we use a simple semaphore containing thenumber of outstanding requests for that lock (alternatively,two semaphores—one for read requests and one for write-requests). After removing the bulk of the lock manager’s

main data structure, it is no longer trivial to determinewhich transaction should inherit a lock upon its release by aprevious owner. One key contribution of our work is there-fore a solution to this problem. Our basic technique is toforce all locks to be requested by a transaction at once, andorder the transactions by the order in which they requesttheir locks. We use this global transaction order to figureout which transaction should be unblocked and allowed torun as a consequence of the most recent lock release.

The combination of these two techniques—which we callvery lightweight locking (VLL)—incurs far less overhead thanmaintaining a traditional lock manager, but it also tracksless total information about contention between transac-tions. Under high-contention workloads, this can result inreduced concurrency and poor CPU utilization. To amelio-rate this problem, we also propose an optimization called se-

lective contention analysis (SCA), which—only when needed—efficiently computes the most useful subset of the con-tention information that is tracked in full by traditional lockmanagers at all times.

Our experiments show that VLL dramatically reduces lockmanagement overhead, both in the context of a traditionaldatabase system running on a single (multi-core) server,and when used in a distributed database system that parti-tions data across machines in a shared-nothing cluster. Insuch partitioned systems, the distributed commit protocol(typically two-phase commit) is often the primary bottle-neck, rather than the lock manager. However, recent workon deterministic database systems such as Calvin [22] haveshown how two-phase commit can be eliminated for dis-tributed transactions, increasing throughput by up to an or-der of magnitude—and consequently reintroducing the lockmanager as a major bottleneck. Fortunately, deterministicdatabase systems like Calvin lock all data for a transactionat the very start of executing the transaction. Since thiselement of Calvin’s execution protocol satisfies VLL’s lockrequest ordering requirement, VLL fits naturally into the de-sign of deterministic systems. When we compare VLL (im-plemented within the Calvin framework) against Calvin’snative lock manager, which uses the traditional design of ahash table of request queues, we find that VLL enables aneven greater throughput advantage than that which Calvinhas already achieved over traditional nondeterministic exe-cution schemes in the presence of distributed transactions.

2. VERY LIGHTWEIGHT LOCKINGThe category of “main memory database systems” en-

compasses many different database architectures, includingsingle-server (multi-processor) architectures and a plethoraof emerging partitioned system designs. The VLL protocolis designed to be as general as possible, with specific opti-mizations for the following architectures:

• Multiple threads execute transactions on a single-server,shared memory system.

• Data is partitioned across processors (possibly span-ning multiple independent servers). At each partition,a single thread executes transactions serially.

• Data is partitioned arbitrarily (e.g. across multiplemachines in a cluster); within each partition, multipleworker threads operate on data.

The third architecture (multiple partitions, each runningmultiple worker threads) is the most general case; the firsttwo architectures are in fact special cases of the third. Inthe first, the number of partitions is one, and in the second,each partition limits its pool of worker threads to just one.For the sake of generality, we introduce VLL in the contextof the most general case in the upcoming sections, but wealso point out the advantages and tradeoffs of running VLLin the other two architectures.

2.1 The VLL algorithmThe biggest difference between very lightweight locking

and traditional lock manager implementations is that VLLstores each record’s “lock table entry” not as a linked list ina separate lock table, but rather as a pair of integer values(CX , CS) immediately preceding the record’s value in stor-age, which represent the number of transactions requestingexclusive and shared locks on the record, respectively. Whenno transaction is accessing a record, its CX and CS valuesare both 0.

In addition, a global queue of transaction requests (calledTxnQueue) is kept at each partition, tracking all active trans-actions in the order in which they requested their locks.

When a transaction arrives at a partition, it attempts torequest locks on all records at that partition that it willaccess in its lifetime. Each lock request takes the form ofincrementing the corresponding record’s CX or CS value,depending whether an exclusive or shared lock is needed.Exclusive locks are considered to be “granted” to the re-questing transaction if CX = 1 and CS = 0 after the request,since this means that no other shared or exclusive locks arecurrently held on the record. Similarly, a transaction is con-sidered to have acquired a shared lock if CX = 0, since thatmeans that no exclusive locks are held on the record.

Once a transaction has requested its locks, it is addedto the TxnQueue. Both the requesting of the locks and theadding of the transaction to the queue happen inside thesame critical section (so that only one transaction at a timewithin a partition can go through this step). In order to re-duce the size of the critical section, the transaction attemptsto figure out its entire read set and write set in advance ofentering this critical section. This process is not always triv-ial and may require some exploratory actions. Furthermore,multi-partition transaction lock requests have to be coordi-nated. This process is discussed further in Section 3.1.

Upon leaving the critical section, VLL decides how to pro-ceed based on two factors:

• Whether or not the transaction is local or distributed.A local transaction is one whose read- and write-setsinclude records that all reside on the same partition;distributed transactions may access a set of recordsspanning multiple data partitions.

• Whether or not the transaction successfully acquiredall of its locks immediately upon requesting them. Trans-actions that acquire all locks immediately are termedfree. Those which fail to acquire at least one lock aretermed blocked.

VLL handles each transactions differently based on whetherthey are free or blocked:

• Free transactions are immediately executed. Oncecompleted, the transaction releases its locks (i.e. it

decrements every CX or CS value that it originallyincremented) and removes itself from the TxnQueue

1 .Note, however, that if the free transaction is distributedthen it may have to wait for remote read results, andtherefore may not complete immediately.

• Blocked transactions cannot execute fully, since notall locks have been acquired. Instead, these are taggedin the TxnQueue as blocked. Blocked transactions arenot allowed to begin executing until they are explicitlyunblocked by the VLL algorithm.

In short, all transactions—free and blocked, local and dis-tributed —are placed in the TxnQueue, but only free trans-actions begin execution immediately.

Since there is no lock management data structure to recordwhich transactions are waiting for data locked by other trans-actions, there is no way for a transaction to hand over itslocks directly to another transaction when it finishes. An al-ternative mechanism is therefore needed to determine whenblocked transactions can be unblocked and executed. Onepossible way to accomplish this is for a background threadto examine each blocked transaction in the TxnQueue and ex-amine the CX and CS values of each data item for which thetransaction requested a lock. If the transaction incrementedCX for a particular item, and now CX is down to 1 and CS

is 0 for that item (indicating that no other active transac-tions have locked that item), then the transaction clearlyhas an exclusive lock on it. Similarly, if the transaction in-cremented CS and now CX is down to 0, the transactionhas a shared lock on the item. If all data items that it re-quested are now available, the transaction can be unblockedand executed.

The problem with this approach is that if another trans-action entered the TxnQueue and incremented CX for thesame data item that a transaction blocked in the TxnQueue

already incremented, then both transactions will be blockedforever since CX will always be at least 2.

Fortunately, this situation can be resolved by a simpleobservation: a blocked transaction that reaches the frontof the TxnQueue will always be able to be unblocked andexecuted—no matter how large CX and CS are for the dataitems it accesses. To see why this is the case, note that eachtransaction requests all locks and enters the queue all withinthe same critical section. Therefore if a transaction makesit to the front of the queue, this means that all transactionsthat requested their locks before it have now completed.Furthermore, all transactions that requested their locks afterit will be blocked if their read and write set conflict.

Since the front of the TxnQueue can always be unblockedand run to completion, every transaction in the TxnQueue

will eventually be able to be unblocked. Therefore, in addi-tion to reducing lock manager overhead, this technique alsoguarantees that there will be no deadlock within a partition.(We explain how distributed deadlock is avoided in Section3.1.) Note that a blocked transaction now has two waysto become unblocked: either it makes it to the front of thequeue (meaning that all transactions that requested locksbefore it have finished completely), or it becomes the onlytransaction remaining in the queue that requested locks on

1The transaction is not required to be at the front of theTxnQueue when it is removed. In this sense, TxnQueue isnot, strictly speaking, a queue.

// Requests exclusive locks on all records in T’s// WriteSet and shared locks on all records in T’s ReadSet.// Tags T as free iff ALL locks requested were// successfully acquired.function BeginTransaction(Txn T)

<begin critical section>T.Type = Free;// Request read locks for T.foreach key in T.ReadSet

data[key].Cs++;// Note whether lock was acquired.if (data[key].Cx > 0)

T.Type = Blocked;// Request write locks for T.foreach key in T.WriteSet

data[key].Cx++;// Note whether lock was acquired.if (data[key].Cx > 1 OR data[key].Cs > 0)

T.Type = Blocked;TxnQueue.Enqueue(T);<end critical section>

// Releases T’s locks and removes T from TxnQueue.function FinishTransaction(Txn T)

<begin critical section>foreach key in T.ReadSet

data[key].Cs−−;foreach key in T.WriteSet

data[key].Cx−−;TxnQueue.Remove(T);<end critical section>

// Transaction execution thread main loop.

function VLLMainLoop()

while (true)

// Select a transaction to run next...

// First choice: a previously-blocked txn

// that now does not conflict with older txns.

if (TxnQueue.front().Type == Blocked)

Txn T = TxnQueue.front();

T.Type = Free;

Execute(T);

FinishTransaction(T);

// 2nd choice: Start on a new txn request.

else if (TxnQueue is not full)

Txn T = GetNewTxnRequest();

BeginTransaction(T);

if (T.Type == Free)

Execute(T);

FinishTransaction(T);

Figure 1: Pseudocode for the VLL algorithm.

each of the keys in its read-set and write-set. We discuss amore sophisticated technique for unblocking transactions inSection 2.5.

One problem that VLL sometimes faces is that as theTxnQueue grows in size, the probability of a new transactionbeing able to immediately acquire all its locks decreases,since the transaction can only acquire its locks if it does notconflict with any transaction in the entire TxnQueue.

We therefore artificially limit the number of transactionsthat may enter the TxnQueue—if the size exceeds a thresh-old, the system temporarily ceases to process new transac-tions, and shifts its processing resources to finding trans-actions in the TxnQueue that can be unblocked (see Sec-

Figure 2: Example execution of a sequence of transactions {A,B,C,D,E} using VLL. Each transaction’s readand write set is shown in the top left box. Free transactions are shown with white backgrounds in theTxnQueue, and blocked transactions are shown as black. Transaction logic and record values are omitted, sinceVLL depends only on the keys of the records in transactions’ read and write sets.

tion 2.5). In practice we have found that this thresholdshould be tuned depending on the contention ratio of theworkload. High contention workloads run best with smallerTxnQueue size limits since the probability of a new transac-tion not conflicting with any element in the TxnQueue issmaller. A longer TxnQueue is acceptable for lower con-tention workloads. In order to automatically account forthis tuning parameter, we set the threshold not by the sizeof the TxnQueue, but rather by the number of blocked trans-actions in the TxnQueue, since high contention workloads willreach this threshold sooner than low contention workloads.

Figure 1 shows the pseudocode for the basic VLL al-gorithm. Each worker thread in the system executes theVLLMainLoop function. Figure 2 depicts an example execu-tion trace for a sequence of transactions.

2.2 Single­threaded VLLIn the previous section, we discussed the most general ver-

sion of VLL, in which multiple threads may process differenttransactions simultaneously within each partition. It is alsopossible to run VLL in single-threaded mode. Such an ap-proach would be useful in H-Store style settings [19], wheredata is partitioned across cores within a machine (or withina cluster of machines) and there is only one thread assignedto each partition. These partitions execute independently ofone another unless a transaction spans multiple partitions,in which case the partitions need to coordinate processing.

In the general version of VLL described above, once athread begins executing a transaction, it does nothing else

until the transaction is complete. For distributed transac-tions that perform remote reads, this may involve sleepingfor some period of time while waiting for another partitionto send the read results over the network. If single-threadedVLL were implemented simply by running only one threadaccording to the previous specification, the result wouldbe a serial execution of transactions, since no transactionwould ever start until the previous transaction completed,and therefore no transaction could ever block on any other.

In order to improve concurrency in single-threaded VLLimplementations, we allow transactions to enter a third state(in addition to “blocked” and “free”). This third state,“waiting”, indicates that a transaction was previously exe-cuting but could not complete without the result of an out-standing remote read request. When a transaction triggersthis condition and enters the “waiting” state, the main exe-cution thread puts it aside and searches for a new transac-tion to execute. Conversely, when the main thread is lookingfor a transaction to execute, in addition to considering thefirst transaction on the TxnQueue and any new transactionrequests, it may resume execution of any “waiting” trans-action which has received remote read results since enteringthe “waiting” state.

There is also no need for critical sections when running insingle-threaded mode, since only one transaction at a timeattempts to acquire locks at any particular partition.

2.3 Impediments to acquiring all locks at onceAs discussed in Section 2.1, in order to guarantee that the

head of the TxnQueue is always eligible to run (which hasthe added benefit of eliminating deadlocks), VLL requiresthat all locks for a transaction be acquired together in acritical section. There are two possibilities that make thisnontrivial:

• The read and write set of a transaction may not beknown before running the transaction. An exampleof this is a transaction that updates a tuple that isaccessed through a secondary index lookup. With-out first doing the lookup, it is hard to predict whatrecords the transaction will access—and therefore whatrecords it must lock.

• Since each partition has its own TxnQueue, and thecritical section in which it is modified is local to a par-tition, different partitions may not begin processingtransactions in the same order. This could lead to dis-tributed deadlock, where one partition gets all its locksand activates a transaction, while that transaction is“blocked” in the TxnQueue of another partition.

In order to overcome the first problem, before the trans-action enters the critical section, we allow the transactionto perform whatever reads it needs to (at no isolation) forit to figure out what data it will access (for example, it per-forms the secondary index lookups). This can be done in theGetNewTxnRequest function that is called in the pseudocodeshown in Figure 1. After performing these exploratory reads,it enters the critical section and requests those locks that itdiscovered it would likely need. Once the transaction gets itslocks and is handed off to an execution thread, the transac-tion runs as normal unless it discovers that it does not havea lock for something it needs to access (this could happen if,for example, the secondary index was updated immediatelyafter the exploratory lookup was performed and now returnsa different value. In such a scenario, the transaction aborts,releases its locks, and submits itself to the database systemto be restarted as a completely new transaction.

There are two possible solutions to the second problem.The first is simply to allow distributed deadlocks to occurand to run a deadlock detection protocol that aborts dead-locked transactions. The second approach is to coordinateacross partitions to ensure that multi-partition transactionsare added to the TxnQueue in the same order on each parti-tion.

We choose the second approach for our implementationin this paper. The reason is that multi-partition trans-actions are typically bottlenecked by the commit protocol(e.g. two-phase commit) that are run in order to ensureACID-compliance of transactional execution. Reducing thelock manager overhead in such a scenario is therefore un-helpful in the face of a larger bottleneck. However, recentwork on deterministic database systems [21, 22] shows thatthe commit protocol may be eliminated by performing allmulti-partition coordination before beginning transactionalexecution. In short, deterministic database systems such asCalvin order all transactions across partitions, and this or-der can be leveraged by VLL to avoid distributed deadlock.Furthermore, since deterministic systems have been shownto be a particularly promising approach in main memorydatabase systems [21], the integration of VLL and deter-ministic database systems seems to be a particularly goodmatch.

2.4 Tradeoffs of VLLVLL’s primary strength lies in its extremely low overhead

in comparison to that of traditional lock management ap-proaches. VLL essentially “compresses” a standard lockmanager’s linked list of lock requests into two integers. Fur-thermore, by placing these integers inside the tuple itself,both the lock information and the data itself can be re-trieved with a single memory access, minimizing total cachemisses.

The main disadvantage of VLL is a potential loss in con-currency. Traditional lock managers use the informationcontained in lock request queues to figure out whether alock can be granted to a particular transaction. Since VLLdoes not have these lock queues, it can only test more selec-tive predicates on the state: (a) whether this is the only lockin the queue, or (b) whether it is so old that it is impossiblefor any other transaction to precede it in any lock queue.

As a result, it is common for scenarios to arise under VLLwhere a transaction cannot run even though it “should” beable to run (and would be able to run under a standard lockmanager design). Consider, for example, the sequence oftransactions:

txn writesetA xB yC x, zD z

Suppose A and B are both running in executor threads(and are therefore still in the TxnQueue) when C and D comealong. Since transaction C conflicts with A on record x andD conflicts with C on z, both are put on the TxnQueue inblocked mode. VLL’s “lock table state” would then look likethe following (as compared to the state of a standard locktable implementation):

VLL Standard

key Cx Cs key request queuex 2 0 x A, Cy 1 0 y Bz 2 0 z C, D

TxnQueueA, B, C, D

Next, suppose that A completes and releases its locks. Thelock tables would then appear as follows:

VLL Standard

key Cx Cs key request queuex 1 0 x Cy 1 0 y Bz 2 0 z C,D

TxnQueueB, C, D

Since C appears at the head of all its request queues, astandard implementation would know that C could safelybe run, whereas VLL is not able to determine that.

When contention is low, this inability of VLL to immedi-ately determine possible transactions that could potentially

be unblocked is not costly. However, under higher con-tention workloads, and especially when there are distributedtransactions in the workload, VLL’s resource utilization suf-fers, and additional optimizations are necessary. We discusssuch optimizations in the next section.

2.5 Selective contention analysis (SCA)For high contention and high percentage multi-partition

workloads, VLL spends a growing percentage of CPU cyclesin the state described in Section 2.4 above, where no trans-action can be found that is known to be safe to execute—whereas a standard lock manager would have been able tofind one. In order to maximize CPU resource utilization, weintroduce the idea of selective contention analysis (SCA).

SCA simulates the standard lock manager’s ability to de-tect which transactions should inherit released locks. It doesthis by spending work examining contention—but only whenCPUs would otherwise be sitting idle (i.e., TxnQueue is fulland there are no obviously unblockable transactions). SCAtherefore enables VLL to selectively increase its lock man-agement overhead when (and only when) it is beneficial todo so.

Any transaction in the TxnQueue that is in the ’blocked’state, conflicted with one of the transactions that precededit in the queue at the time that it was added. Since then,however, the transaction(s) that caused it to become blockedmay have completed and released their locks. As the trans-action gets closer and closer to the head of the queue, ittherefore becomes much less likely to be “actually” blocked.

In general, the ith transaction in the TxnQueue can onlyconflict now with up to (i−1) prior transactions, whereas itpreviously had to contend with (up to) TxnQueueSizeLimitprior transactions. Therefore, SCA starts at the front of thequeue, and works its way through the queue looking for atransaction to execute. The whole while, it keeps two bit-arrays, DX and DS , each of size 100kB (so that both willeasily fit inside an L2 cache of size 256kB) and initialized toall 0s. SCA then maintains the invariant that after scanningthe first i transactions:

• DX [j] = 1 iff an element of one of the scanned trans-actions’ write-sets hashes to j

• DS [k] = 1 iff an element of one of the scanned trans-actions’ read-sets hashes to k

Therefore, if at any point the next transaction scanned (let’scall it Tnext) has the properties

• DX [hash(key)] = 0 for all keys in Tnext’s read-set

• DX [hash(key)] = 0 for all keys in Tnext’s write-set

• DS [hash(key)] = 0 for all keys in Tnext’s write-set

then Tnext does not conflict with any of the prior scannedtransactions and can safely be run2.

In other words, SCA traverses the TxnQueue starting withthe oldest transactions and looking for a transaction that isready to run and does not conflict with any older transac-tion. Pseudocode for SCA is provided in Figure 3.

2Although there may be some false negatives (in which an“actually” runable transaction is still perceived as blocked)due to the need to hash the entire keyspace into a 100kBbitstring, this algorithm gives no false positives.

// SCA returns a transaction that can safely be run (or null

// if none exists). It is called only when TxnQueue is full.

function SCA()

// Create our 100kB bit arrays.

bit Dx[819200] = {0};

bit Ds[819200] = {0};

foreach Txn T in TxnQueue

// Check whether the Blocked transaction

// can safely be run

if (T.state() == BLOCKED)

bool success = true;

// Check for conflicts in ReadSet.

foreach key in T.ReadSet

// Check if a write lock is held by any

// earlier transaction.

int j = hash(key);

if (Dx[j] == 1)

success = false;

Ds[j] = 1;

// Check for conflicts in WriteSet.

foreach key in T.WriteSet

// Check if a read or write lock is held

// by any earlier transaction.

int j = hash(key);

if (Dx[j] == 1 OR Ds[j] == 1)

success = false;

Dx[j] = 1;

if (success)

return T;

// If the transaction is free, just mark the bit-arrays.

else

foreach key in T.ReadSet

int j = hash(key);

Ds[j] = 1;

foreach key in T.WriteSet

int j = hash(key);

Dx[j] = 1;

return NULL;

Figure 3: SCA pseudocode.

SCA is actually “selective” in two different ways. First,it only gets activated when it is really needed (in contrastto traditional lock manager overhead which always pays thecost of tracking lock contention even when this informationwill not end up being used). Second, rather than doing anexpensive all-to-all conflict analysis between active transac-tions (which is what traditional lock managers track at alltimes), SCA is able to limit its analysis to those transactionsthat are (a) most likely to be able to run immediately and(b) least expensive to check.

In order to improve the performance of our implementa-tion of SCA, we include a minor optimization that reducesthe CPU overhead of running SCA. Each key needs to behashed into the 100kB bitstring, but hashing every key foreach transaction as we iterate through the TxnQueue can beexpensive. We therefore cache the results of the hash func-tion the first time SCA encounters a transaction inside thetransaction state. If that transaction is still in the TxnQueuethe next time SCA iterates through the queue, the algorithmmay then use the saved list of offsets that corresponds to thekeys read and written by that transaction to set the appro-

priate bits in the SCA bitstring, rather having to re-hasheach key.

3. EXPERIMENTAL EVALUATIONTo evaluate VLL and SCA, we ran several experiments

comparing VLL (with and without SCA) against alterna-tive schemes in a number of contexts. We separate our ex-periments into two groups: single-machine experiments, andexperiments in which data is partitioned across multiple ma-chines in a shared-nothing cluster.

In our single-machine experiments, we ran VLL (exactlyas described in Section 2.1) in a multi-threaded environmenton a multi-processor machine. As a comparison point, weimplemented a traditional two-phase locking (2PL) protocolinside the same main-memory database system prototype.This allows for an apples-to-apples comparison in which theonly difference is the locking protocol.

Our second implementation of VLL is designed to runin a shared-nothing (multi-server) configuration. As de-scribed in Section 3.1, the cost of running any locking proto-col is usually dwarfed by the contention cost of distributedcommit protocols such as two-phase commit (2PC) thatare used to guarantee ACID for multi-partition transac-tions. We therefore implemented VLL inside Calvin, a deter-ministic database system that does not require distributedagreement protocols to commit distributed transactions [22].We compare our deterministic VLL implementation against(1) Calvin’s default concurrency control scheme (which usesstandard lock management data structures to track whatdata is locked), (2) a traditional distributed database imple-mentation which uses 2PL (with a standard lock manageron each partition that tracks locks of data in that parti-tion) and 2PC, and (3) an H-Store implementation3 [19]that partitions data across threads (so that an 8-server clus-ter, where each server has 8 hardware threads, is partitionedinto 64 partitions) and executes all transactions at each par-tition within a single thread, removing the need for lockingor latching of shared data structures.

Our prototype is implemented in C++. All the exper-iments measuring throughput were conducted on a Linuxcluster of a 2.6 GHz quad-core Intel Xeon X5550 machineswith 8 CPU threads and 12G RAM, connected by a singlegigabit Ethernet switch.

In order to minimize the effects of irrelevant componentsof the database system on our results, we devote 3 out of 8cores on every machine to those components that are com-pletely independent of the locking scheme (e.g. client loadgeneration, performance monitoring instrumentation, intra-process communications, input logging, etc.), and devote theremaining 5 cores to worker threads and lock managementthreads. For all techniques that we compare in the exper-iments, we tuned the worker thread pool size by hand byincreasing the number of worker threads until throughputdecreased due to too much thread contention.

3.1 Multi­core, single­server experimentsThis section compares the performance of VLL against

two-phase locking. For VLL, we analyze performance with

3Although we refer to this system as “H-Store” in the dis-cussion that follows, we actually implemented the H-Storeprotocol within the Calvin framework in order to provide asfair a comparison as possible.

and without the SCA optimization. We also implement twoversions of 2PL: a “traditional” implementation that detectsdeadlocks via timeouts and aborts deadlocked transactions,and a deadlock-free variant of 2PL in which a transactionplaces all of its lock requests in a single atomic step (wherethe data that must be locked is determined in an identicalway as VLL, as described in Section ). However, this mod-ified version of 2PL still differs from VLL in that it uses atraditional lock management data structure.

Our first set of single-machine experiments uses the samemicrobenchmark as was used in [22]. Each microbenchmarktransaction reads 10 records and updates a value at eachrecord. Of the 10 records accessed, one is chosen from asmall set of ‘hot’ records, and the rest are chosen from alarger set of ‘cold’ records. Contention levels between trans-actions can be finely tuned by varying the size of the setof hot records. In the subsequent discussion, we use theterm contention index to refer to the probability of any twotransactions conflicting with one another. Therefore, for thismicrobenchmark, if the number of the hot records is 1000,the contention index would be 0.001. If there is only onehot record (which would then be modified by every singletransaction) the contention index would be 1. The set ofcold records is always large enough such that transactionsare extremely unlikely to conflict due to accessing the samecold record.

As a baseline for all four systems, we include a “no lock-ing” scheme, which represents the performance of the samesystem with all locking completely removed (and any iso-lation guarantees completely forgone). This allows us toclearly see the overhead of acquiring and releasing the locks,maintaining lock management data structures for each scheme,and waiting for blocked transactions when there is contention.

Figure 4 shows the transactional throughput the system isable to achieve under the four alternative locking schemes.

When contention is low (below 0.02), VLL (with and with-out SCA) yields near-optimal throughput. As contention in-creases, however, the TxnQueue starts to fill up with blockedtransactions, and the SCA optimization is able to improveperformance relative to the basic VLL scheme by selectivelyunblocking transactions and “unclogging” the execution en-gine. In this experiment, SCA boosts VLL’s performanceby up to 76% under the highest contention levels.

At the very left-hand side of the figure, where contentionis very low, transactions are always able to acquire all theirlocks and run immediately. Looking at the difference be-tween “no locking” and 2PL at low contention, we can seethat the locking overhead of 2PL is about 21%. This numberis consistent with previous measurements of locking over-head in main memory databases [8, 14]. However, the over-head of VLL is only 2%, demonstrating VLL’s lightweightnature. By co-locating lock information with data to in-crease cache locality, and by representing lock informationin only two integers per record, VLL is able to lock datawith extremely low overhead.

As contention increases, the throughput of both VLL and2PL decrease (since the system is “clogged” by blocked trans-actions), and the two schemes approach one another in per-formance as the additional information that the 2PL schemekeeps in the lock manager becomes increasingly useful (asmore transactions block). However, it is interesting to notethat 2PL never overtakes the performance of VLL with SCA,since SCA can quickly construct the relevant part of trans-

0

10000

20000

30000

40000

50000

0.0001 0.001 0.01 0.1

thro

ughp

ut (

txns

/sec

)

contention index

VLL with SCA VLL

Standard 2PLDeadlock-free 2PL

No locking

Figure 4: Transactional throughput vs. contentionunder a deadlock-free workload.

actional data dependencies on the fly. In fact, it appearsthat the overhead of repeatedly running SCA at very highcontention is approximately equal to the overhead of main-taining a full lock manager. Therefore, VLL with the SCAoptimization has the advantage that it eliminates the lockmanager overhead when possible, while still reconstructingthe information stored in standard lock tables when this isneeded to make progress on transaction execution.

With increasing contention, the deadlock-free 2PL imple-mentation saw a greater throughput reduction than the tra-ditional 2PL implementation. This is because in traditional2PL, transactions delay requesting locks until actually read-ing or writing the corresponding record, thereby holdinglocks for shorter durations than the deadlock-free versionin which transactions request all locks up front.

Since this workload involved locking only one hot item pertransaction, there is (approximately) no risk of transactionsdeadlocking4. This hides a major disadvantage of 2PL rel-ative to VLL, since 2PL must detect and resolve deadlocks,while VLL does not, since VLL is always deadlock-free re-gardless of the transactional workload (due to the way itorders its lock acquisitions). In order to model other typesof workloads where multiple records per transaction can becontested (which can lead to deadlock for the traditionallock schemes), we increase the number of hot records pertransaction in our second experiment. Figure 5 shows theresulting throughput as we vary contention index. Frequentdeadlocks causes throughput for traditional 2PL to drop dra-matically, which results in VLL with SCA outperforming2PL by at least 163% in most cases, and as much as 18Xin the extreme high contention case (the right-most part ofthe figure).

Although traditional 2PL performance changes significantlybetween Figures 4 and 5, the deadlock-free 2PL variant isnot affected (as expected). However, since it still uses a tra-ditional lock manager data structure, it has higher overheadthan VLL at low contention levels. Furthermore, the criti-cal section in which all locks are acquired is more expensive

4The exception is that deadlock is possible in this workloadif transactions conflict on cold items. This was rare enough,however, that we observed no deadlocks in our experiments.

0

10000

20000

30000

40000

50000

0.0001 0.001 0.01 0.1

thro

ughp

ut (

txns

/sec

)

contention index

VLL with SCA VLL

Standard 2PL Deadlock-free 2PL

No locking

Figure 5: Transactional throughput vs. contentionunder a workload in which deadlocks are possible.

than the corresponding critical section for VLL (since it in-cludes the more expensive hash table and queue operationsassociated with standard lock table implementations insteadof VLL’s simple integer operations) and therefore continuesto be outperformed by VLL even at higher contention levels.

3.2 Distributed Database ExperimentsIn this section, we examine the performance of VLL in

a distributed (shared-nothing) database architecture. Wecompare VLL against three other concurrency control de-signs for distributed main memory databases: traditionaldistributed 2PL, H-Store’s lock-free protocol, and Calvin’sdeterministic locking protocol.

The first comparison point we use is traditional distributed2PL, which uses a traditional lock manager (exactly as inthe single-server experiments) on each partition, and usesthe two-phase commit (2PC) protocol to commit distributedtransactions.

The H-Store implementation [19] eliminates all lock man-ager overhead by removing locking entirely and executingtransactions serially. In order to make use of multiple cores(and multiple machines), H-Store partitions data across coresand runs transactions serially in a single thread at each par-tition. If a transaction touches data across multiple parti-tions, each participating partition blocks until all partic-ipants reach and start to process that transaction. Themain disadvantage of this approach is that, in general, par-titions are not synchronized in their execution of transac-tions, so partitions participating in a distributed transactionmay have to wait for other, slower participants to reach thesame point in execution to complete the transaction (andsince transactions are executed serially, the waiting par-ticipant cannot apply idle CPU resources to other usefultasks while waiting). Furthermore, even after each partitionstarts on the same transaction, there can be significant idletime while waiting for messages to be passed between parti-tions. Therefore, H-Store performs extremely well on “em-barrassingly partitionable” workloads—where every trans-action can be executed within a single partition—but its per-formance quickly degrades as distributed transactions enterthe mix.

The third comparison point is Calvin, a deterministic databasesystem prototype that employs a traditional hash-table-of-request-queues structure in its lock manager. Previous workhas shown that Calvin performs similarly to traditional databasesystems when transactions are short and only access memory-resident data, worse when there are long-running transac-tions that access disk (due to the additional inflexibility as-sociated with the determinism guarantee), and better whenthere are distributed transactions (since the determinismguarantee allows the elimination of two-phase commit) [21,22]. For these experiments, all transactions are completelyin-memory (so that Calvin is expected to perform approx-imately as well as possible as a comparison point), and wevary the percentage of transactions that span multiple par-titions.

Since VLL acquires locks for each transaction all at once,it is possible for it to also be used in a deterministic system.We simply require that each transaction acquires its locksin the same order as the deterministic transaction sequence.This is more restrictive than the general VLL algorithm—which allows transactions to (atomically) request their locksin any order—but allows for a more direct comparison withCalvin, since by satisfying Calvin’s determinism invariant,VLL too can use Calvin’s determinism invariant to eschewtwo-phase commit. To further improve the quality of com-parison, we allow H-Store to omit the two-phase commitprotocol as well (even though the original H-Store papersimplement two-phase commit).

For these experiments, we implement the single-threadedversion of VLL as described in Section 2.2, since, as ex-plained in that section, this allows for locks to be acquiredoutside of critical sections. The main disadvantage of single-threaded VLL is that in order to utilize all the CPU re-sources on a multi-core server, data must be partitionedacross each core (with a single thread in charge of process-ing transactions for that core), which leads to the overheadof dealing with multi-partition transactions for transactionsthat touch data controlled by threads on different cores.However, since this “distributed” set of experiments has todeal with multi-partition transactions anyway (for transac-tions that span data stored on different physical machines),the infrastructure cost of this extra overhead has alreadybeen incurred. Therefore, we use the multi-threaded ver-sion of VLL for the single-server (multi-core) experiments,and the single-threaded version of VLL for the distributeddatabase experiments.

Since we are running a distributed database, we dedicateone of the virtual cores on each database server node tohandle communication with other nodes (in addition to thethree other virtual cores previously reserved for databasecomponents described above), leaving 4 virtual cores dedi-cated to transaction processing. For H-Store and both VLLimplementations, we leveraged these 4 virtual cores by cre-ating 4 data partitions per machine, so every execution en-gine used one core to handle transactions associated withits partition, and for distributed 2PL, we left 4 virtual coresdedicated to worker threads5. Similarly to distributed 2PL,Calvin does not partition data within a node. We found

5For 2PL, we hand-tuned the number of worker threads foreach experiment, since workloads with more multi-partitiontransactions require more worker threads to keep the CPUoccupied (because many worker threads are sleeping, wait-ing for remote data). With enough worker threads, the ex-

0

50000

100000

150000

200000

250000

300000

350000

0 5 10 15 20 30 40 50 60 70 80 90 100

thro

ughp

ut (

txns

/sec

)

% multi-partition transactions

VLL with SCA VLL

Calvin H-Store

Distributed 2PL

Figure 6: Microbenchmark throughput with lowcontention, varying how many transactions spanmultiple partitions.

0

50000

100000

150000

200000

250000

300000

350000

0 5 10 15 20 30 40 50 60 70 80 90 100

thro

ughp

ut (

txns

/sec

)

% multi-partition transactions

VLL with SCA VLL

Calvin H-Store

Figure 7: Microbenchmark throughput with highcontention, varying how many transactions spanmultiple partitions (distributed 2PL results omitteddue to large amounts of distributed deadlock).

that Calvin’s scheduler (which includes one thread that per-forms all lock manager operations) fully utilized one of thefour cores that were devoted to transaction processing.

3.2.1 Microbenchmark experiments

In our first set of distributed experiments, we used thesame microbenchmark from Section 3.1. For these experi-ments, we vary both lock contention and the percentage ofmulti-partition transactions.

We ran this experiment on 8 machines, so H-Store andVLL split data across 32 partitions, while the Calvin anddistributed 2PL deployments used a single partition per ma-chine for a total of 8 partitions (each of which was 4 timesthe size of one H-Store/VLL partition). For the low con-tention test (Figure 6), each H-Store/VLL partition con-

tended contention footprint of 2PC eventually becomes thebottleneck that limits total throughput.

tained 1,000,000 records of which 10,000 were hot, and eachCalvin partition contained 4,000,000 records of which 40,000were hot. Since VLL and H-Store had a smaller number ofhot records per partition, they ended up having a slightlylarger contention index than Calvin and distributed 2PL(0.0001 for VLL/H-Store vs. 0.000025 for Calvin/2PL).Calvin and distributed 2PL therefore had a slight advantagein the experiments relative to VLL and H-Store. Similarly,for the high contention tests (Figure 7), we used 100 hotrecords for each H-Store/VLL partition and 400 hot recordsfor each Calvin partition, resulting in contention indexes of0.01 for VLL/H-Store and 0.0025 for Calvin.

Before comparing VLL to the other schemes, we exam-ine VLL with and without the SCA optimization. Underhigh contention, SCA is extremely important, and VLL’sthroughput is poor without it. Under low contention how-ever, the SCA optimization actually hinders performanceslightly when there are more than 60% multi-partition trans-actions. There are three reasons for this effect. First, underlow contention, very few transactions are blocked waiting forlocks, so SCA has a smaller number of potential transactionsto unblock.

Second, since multi-partition transactions take longer thansingle-partition transactions, the TxnQueue typically con-tains many multi-partition transactions waiting for read re-sults from other partitions. The higher the percentage ofmulti-partition transactions, the longer the TxnQueue tendsto be (recall that the queue length is limited by the numberof blocked transactions, not the total number of transac-tions). Since SCA iterates through the TxnQueue each timethat it is called, the overhead of each SCA run thereforeincreases with multi-partition percentage.

Third, since low contention workloads typically have moremulti-partition transactions per blocked transaction in theTxnQueue, each blocked transaction has a higher probabil-ity of being blocked behind a multi-partition transaction.This further reduces the effectiveness of SCA’s ability tofind transactions to unblock, since multi-partition transac-tions are slower to finish, and there is nothing that SCA cando to accelerate a multi-partition transaction.

Despite all these reasons for the reduced effectiveness ofSCA for low contention workloads, SCA is only slower thanregular VLL by a small amount. This is because SCA runsare only ever initiated when the CPU would otherwise beidle, so SCA only comes with a cost if the CPU would haveleft its idle state before SCA finishes its iteration throughthe TxnQueue.

VLL with SCA always outperforms Calvin in both experi-ments. With few multi-partition transactions, the lock man-ager overhead is clearly visible in these plots. Calvin keepsone of its four dedicated transaction processing cores (or25% of its available CPU resources) saturated running thelock manager thread. VLL is therefore able to outperformCalvin by up to 33% by eliminating the lock manager threadand devoting that extra core to query execution instead.As the number of multi-partition transactions increases, thelock management overhead becomes less of a bottleneck asthroughput becomes limited by communication delays nec-essary to process multi-partition transactions. Therefore,the performance of Calvin and VLL (with SCA) becomemore similar.

As in the single-server experiments, the full contentiondata tracked by the standard lock manager becomes use-

0

100000

200000

300000

400000

500000

600000

700000

800000

1 2 4 8 12 16 20 24

thro

ughp

ut (

txns

/sec

)

number of machines

VLL with SCA, 10% multi-partitionVLL with SCA, 20% multi-partition

Calvin, 10% multi-partitionCalvin, 20% multi-partition

H-Store, 10% multi-partitionH-Store, 20% multi-partition

Distributed 2PL, 10% multi-partitionDistributed 2PL, 20% multi-partition

Figure 8: Scalability.

ful at higher contention workloads, since information con-tained in the lock manager can be used to unblock trans-actions, so Calvin outperforms the default version of VLLunder high contention (especially when there are more multi-partition transactions that fill the TxnQueue and preventblocked transactions from reaching the head of the queue).However, the SCA optimization is able to reconstruct thesetransactional dependencies when needed, nullifying Calvin’sadvantage.

Both VLL and Calvin significantly outperform the H-Store (serial execution) scheme as more multi-partition trans-actions are added to the workload. This is because H-Storepartitions have no mechanism for concurrent transaction ex-ecution, and so must sit idle any time it depends on an out-standing remote read result to complete a multi-partitiontransaction6. Since H-Store is designed for partitionableworkloads (fewer than 10% multi-partition transactions), itis most interesting to compare H-Store and VLL at the left-hand side of the graph. Even at 0% multi-partition trans-actions, H-Store is unable to significantly outperform VLL,despite the fact that VLL acquires locks before executing atransaction, while H-Store does not. This further demon-strates the extremely low overhead of lock acquisition inVLL.

Both VLL and Calvin also significantly outperform thetraditional distributed 2PL scheme (usually by about 3X).This is largely due to the fact that the distributed 2PLscheme pays the contention cost of running 2PC while hold-ing locks (which Calvin and VLL do not). Furthermore,while Calvin, VLL, and H-Store all avoid deadlock, tradi-tional distributed databases that use 2PL and 2PC mustdetect and resolve deadlocks. We found that under our highcontention benchmark, distributed deadlock rates for the

6Subsequent versions of H-Store proposed to speculativelyexecute transactions during this idle time [10], but this canlead to cascading aborts and wasted work if there wouldhave been a conflict. We do not implement speculative exe-cution in our H-Store prototype since H-Store is designed forworkloads with small percentages of multi-partition trans-actions (when speculative execution is not necessary), andour purpose for including it as a comparison point is onlyto analyze how it compares to VLL on these target single-partition workloads.

0

20000

40000

60000

80000

100000

120000

140000

160000

0 5 10 15 20 30 40 50 60 70 80 90 100

thro

ughp

ut (

txns

/sec

)

% multi-partition transactions

VLL with SCA VLL

Calvin H-Store

Figure 9: TPC-C throughput.

distributed 2PL scheme were so high that throughput ap-proached 0. We therefore omitted the distributed 2PL linefrom Figure 7.

Figure 8 shows the results of an experiment in which wetest the scalability of the different schemes at low contentionwhen there are 10% and 20% multi-partition transactions.We scale from 1 to 24 machines in the cluster. This figureshows that VLL is able to achieve similar linear scalabilityas Calvin, and is therefore able to maintain (and extend) itsperformance advantage at scale. Meanwhile, traditional dis-tributed 2PL does not scale as well as VLL and Calvin, againdue to the contention cost of 2PC. We observed very sim-ilar behavior under the higher contention benchmark (plotomitted due to space constraints).

3.2.2 TPC­C experiments

To expand our benchmarking efforts beyond our simplemicrobenchmark, we present in this section benchmarks ofVLL on TPC-C. The TPC-C benchmark models the OLTPworkload of an eCommerce order processing system. TPC-C consists of a mix of five transactions with different prop-erties. In order to vary the percentage of multi-partitiontransactions in TPC-C, we vary the percentage of New Or-der transactions that access a remote warehouse.

For this experiment, we divided 96 TPC-C warehousesacross the same 8-machine cluster described in the previoussection. As with the microbenchmark experiments, VLLand H-Store partitioned the TPC-C data across 32 three-warehouse partitions (four per machine), while Calvin par-titioned it across 8 twelve-warehouse partitions (one per ma-chine).

Figure 9 shows the throughput results for VLL, Calvin,and H-Store. (Again, we omit the distributed 2PL schemebecause high amounts of distributed deadlocks caused near-zero throughput). Overall, the relative performance of thedifferent locking schemes is very similar to the high-contentionmicrobenchmark results. The high contention in TPC-C re-sults in the SCA optimization improving performance rela-tive to regular VLL by 35% to 109% when multi-partitiontransactions are numerous.

The shape of the Calvin and H-Store lines relative to thetwo versions of VLL is also similar to the high contentionmicrobenchmark experiments. At low percentages of multi-

partition transactions, the lock manager overhead of Calvinreduces its performance, but at higher percentages of multi-partition transactions, it is able to use the information inthe lock manager to unblock stuck transactions and is ableto outperform VLL unless the SCA optimization is used.

3.3 CPU costsThe above experiments show the performance of the dif-

ferent locking schemes by measuring total throughput underdifferent conditions. These results reflect both (a) the CPUoverhead of each scheme, and (b) the amount of concurrencyachieved by the system.

In order to tease apart these two components of perfor-mance, we measured the CPU cost per transaction of re-questing and releasing locks for each locking scheme. Theseexperiments were not run in the context of a fully loadedsystem—rather, we measured the CPU cost of each mecha-nism in complete isolation.

per-transactionlocking mechanism CPU cost (µs)Traditional 2PL 20.13Deterministic Calvin 20.16Multi-threaded VLL 1.8Single-threaded VLL 0.71

Figure 10: Locking overhead per transaction.

Figure 10 shows the results of our isolated CPU cost evalu-ation, which demonstrates the reduced CPU costs that VLLachieves by eliminating the lock manager. We find that theCalvin and 2PL schemes (which both use traditional lockmanagers) have an order of magnitude higher CPU costthan the VLL schemes. The CPU cost of multi-threadedVLL is a little larger than the cost of single-threaded VLL,since multi-threaded VLL has the additional cost of acquir-ing and releasing a latch around the acquisition of locks.

4. RELATED WORKThe System R lock manager described in [6] is the lock

manager design that has been adopted by most databasesystems. In order to reduce the cost of locking, there havebeen several published methods for reducing the numberof lock calls [11, 15, 17]. While these schemes may par-tially mitigate the cost of locking in main-memory systems,but they don’t address the root cause of high lock man-ager overhead—the size and complexity of the data struc-ture used to store lock requests.

[12] presented a Lightweight Intent Lock (LIL), whichmaintains a set of lightweight counters in a global lock table.However, this proposal doesn’t co-locate the counters withthe raw data (to improve cache locality), and if the transac-tion doesn’t acquire all of its locks immediately, the threadblocks, waiting to receive a message from another releasedtransaction thread. VLL differs from this approach in usingthe global transaction order to figure out which transactionshould be unlocked and allowed to run as a consequence ofthe most recent lock release.

The idea of co-locating a record’s lock state with therecord itself in main memory databases was proposed al-most two decades ago [5, 16]. However, this proposal in-volved maintaining a linked list of “Lock Request Blocks”(LCBs) for each record, significantly complicating the un-derlying data structures used to store records, whereas VLL

aims to simplify lock tracking structures by compressing allper-record lock state into a simple pair of integers.

Given the high overhead of the lock manager when adatabase is entirely in main memory [8, 9, 14], some re-searchers observe that executing transactions serially thatwithout concurrency control can buy significant throughputimprovement in main memory database systems [10, 19, 23].Such an approach works well only when the workload can bepartitioned across cores, with very few multi-partition trans-actions. VLL enjoys some of the advantages of reduced lock-ing overhead, while still performing well for a much largervariety of workloads.

Other attempts to avoid locks in main memory databasesystems include optimistic concurrency control schemes andmulti-version concurrency control schemes [1, 4, 13, 14].While these schemes eliminate locking overhead, they in-troduce other sources of overhead. In particular, optimisticschemes can cause overhead due to aborted transactionswhen the optimistic assumption fails (in addition to dataaccess tracking overhead), and multi-version schemes useadditional (expensive) memory resources to store multiplecopies of data.

5. CONCLUSION AND FUTURE WORKWe have presented very lightweight locking (VLL), a pro-

tocol for main memory database systems that avoids thecosts of maintaining the data structures kept by traditionallock managers, and therefore yields higher transactional through-put than traditional implementations. VLL co-locates lockinformation (two simple semaphores) with the raw data, andforces all locks to be acquired by a transaction at once. Al-though the reduced lock information can complicate answer-ing the question of when to allow blocked transactions to ac-quire locks and proceed, selective contention analysis (SCA),allows transactional dependency information to be createdas needed (and only as much information as is needed tounblock transactions). This optimization allows our VLLprotocol to achieve high concurrency in transaction execu-tion, even under high contention.

We showed how VLL can be implemented in traditionalsinger-server multi-core database systems and also in deter-ministic multi-server database systems. The experimentswe presented demonstrate that VLL can outperform stan-dard two-phase locking, deterministic locking, and H-Storestyle serial execution schemes significantly—without inhibit-ing scalability, or interfering with other components of thedatabase system. Furthermore, VLL is highly compatiblewith both standard (non-deterministic) approaches to trans-action processing and deterministic database systems likeCalvin.

Our focus in this paper was on database systems that up-date data in place. In future work, we intend to investigatemulti-versioned variants of the VLL protocol, and integratehierarchical locking approaches into VLL.

6. ACKNOWLEDGMENTSThis work was sponsored by the NSF under grants IIS-

0845643 and IIS-1249722, and by a Sloan Research Fellow-ship. Kun Ren is also supported by National Natural ScienceFoundation of China under Grant 61033007 and National973 project under Grant 2012CB316203.

7. REFERENCES

[1] D. Agrawal and S. Sengupta. Modular synchronization indistributed, multiversion databases: Version control andconcurrency control. IEEE TKDE, 5, 1993.

[2] R. Agrawal and M. J. C. M.Livny. Concurrency controlperformance modeling: Alternatives and implications.volume 12, pages 609–654, 1987.

[3] P. A. Bernstein and N. Goodman. Concurrency control indistributed database systems. ACM Comput. Surv.,13(2):185–221, 1981.

[4] P. A. Bernstein, V. Hadzilacos, and N. Goodman.Concurrency Control and Recovery in Database Systems.Addison-Wesley, 1987.

[5] V. Gottemukkala and T. Lehman. Locking and latching ina memory-resident database system. VLDB, 1992.

[6] J. Gray. Notes on database operating systems. OperatingSystem, An Advanced Course. Springer-Verlag,Berlin, 1979.

[7] J. Gray and Reuter. Transaction Processing: Concepts andTechniques. Morgan Kaufmann, New York, 1993.

[8] S. Harizopoulos, D. J. Abadi, S. R. Madden, andM. Stonebraker. OLTP through the looking glass, and whatwe found there. In SIGMOD, 2008.

[9] R. Johnson, I. Pandis, and A. Ailamaki. Improving oltpscalability using speculative lock inheritance. PVLDB,2(1):479–489, 2009.

[10] E. P. C. Jones, D. J. Abadi, and S. R. Madden.Concurrency control for partitioned databases. InSIGMOD, 2010.

[11] A. Joshi. Adaptive locking strategies in a multi-node datasharing environment. VLDB, 1991.

[12] H. Kimura, G. Graefe, and H. Kuno. Efficient lockingtechniques for databases on modern hardware. InWorkshop on Accelerating Data Management SystemsUsing Modern Processor and Storage Architectures, 2012.

[13] H. T. Kung and J. T. Robinson. On optimistic methods forconcurrency control. TODS, 6(2), 1981.

[14] P. Larson, S. Blanas, C. Diaconu, C. Freedman, J. Patel,and M. Zwilling. High-performance concurrency controlmechanisms for main-memory database. PVLDB,5(4):298–309, 2011.

[15] T. Lehman. Design and Performance Evaluation of a MainMemory Relational Database System. PhD thesis,University of Wisconsin-Madison, 1986.

[16] T. J. Lehman and V. Gottemukkala. The Design andPerformance Evaluation of a Lock Manager for aMemory-Resident Database System. Performance ofConcurrency Control Mechanisms in Centralised DatabaseSystem, Addison-Wesley, 1996.

[17] C. Mohan and I. Narang. Recovery and coherency-controlprotocols for fast inter-system page transfer andfine-granularity locking in shared disks transactionenvironment. VLDB, 1991.

[18] I. Pandis, R. Johnson, N. Hardavellas, and A. Ailamaki.Data-oriented transaction execution. PVLDB,3(1):928–939, 2010.

[19] M. Stonebraker, S. R. Madden, D. J. Abadi,S. Harizopoulos, N. Hachem, and P. Helland. The end of anarchitectural era (it’s time for a complete rewrite). InVLDB, Vienna, Austria, 2007.

[20] A. Thomasian. Two-phase locking performance and itsthrashing behavior. TODS, 18(4):579–625, 1993.

[21] A. Thomson and D. J. Abadi. The case for determinism indatabase systems. VLDB, 2010.

[22] A. Thomson, T. Diamond, P. Shao, K. Ren, S.-C. Weng,and D. J. Abadi. Calvin: Fast distributed transactions forpartitioned database systems. In SIGMOD, 2012.

[23] A. Whitney, D. Shasha, and S. Apter. High volumetransaction processing without concurrency control, twophase commit, SQL or C++. In HPTS, 1997.