High-Performance Concurrency Control Mechanisms for Main-Memory Databases

  • Per-Ake Larson ,
  • Spyros Blanas ,
  • Cristian Diaconu ,
  • Craig Freedman ,
  • Jignesh M. Patel ,
  • Mike Zwilling

PVLDB Vol 5(4) |

Published by Very Large Data Bases Endowment Inc.

Errata: The first entry in Table 2 (on page 301) is incorrect and has been changed. Current text (incorrect): V is visible only of V was created by transaction T and V’s end timestamp equals infinity. Corrected text: V is visible unless TE = T. Reasoning: When reaching this point in checking visibility we have already determined that either a) V’s begin timestamp is earlier than T’s read time or b) V was created by transaction T. A transaction TE has updated or deleted V but TE is still active. If TE is a different transaction than T then logically V’s end timestamp is still equal to infinity so V is visible to T. However, if T itself updated or deleted V, V should no longer be visible to T because a transaction must respect (“see”) its own changes.

Download BibTex

A database system optimized for in-memory storage can support much higher transaction rates than current systems. However, standard concurrency control methods used today do not scale to the high transaction rates achievable by such systems. In this paper we introduce two efficient concurrency control methods specifically designed for main-memory databases. Both use multiversioning to isolate read-only transactions from updates but differ in how atomicity is ensured: one is optimistic and one is pessimistic. To avoid expensive context switching, transactions never block during normal processing but they may have to wait before commit to ensure correct serialization ordering. We also implemented a main-memory optimized version of single-version locking. Experimental results show that while single-version locking works well when transactions are short and contention is low performance degrades under more demanding conditions. The multiversion schemes have higher overhead but are much less sensitive to hotspots and the presence of long-running transactions.