Locking key ranges with unbundled transaction services

David Lomet, Mohamed Mokbel

Research output: Contribution to journalArticle

18 Citations (Scopus)

Abstract

To adapt database technology to new environments like cloud platforms or multi-core hardware, or to try anew to provide an extensible database platform, it is useful to separate transaction services from data management elements that need close physical proximity to data. With "generic" transactional services of concurrency control and recovery in a separate transactional component (TC), indexing, cache and disk management, now in a data component (DC), can be simplified and tailored more easily to the platform or to a data type extension with a special purpose index. This de-composition requires that details of the DC's management of data be hidden from the TC. Thus, locking and logging need to be "logical", which poses a number of problems. One problem is the handling of locking for ranges of keys. Locks need to be taken at the TC prior to the records and their keys being known to the TC. We describe generic two approaches for dealing with this. (1) Make a "speculative" visit" to the DC to learn key values. (2) Lock a "covering resource" first, then learn and lock key values and ultimately release the covering resource lock. The "table" is the only logical (and hence known to the TC) covering resourse in the traditional locking hierarchy, but using it limits con-currency. Concurrency is improved with the introduction of new partition resources. We show how partitions as covering resources combine high concurrency with low locking over-head. Using partitions is sufficiently effective to consider adapting it for a traditional database kernel.

Original languageEnglish
Pages (from-to)265-276
Number of pages12
JournalProceedings of the VLDB Endowment
Volume2
Issue number1
DOIs
Publication statusPublished - 1 Jan 2009
Externally publishedYes

Fingerprint

Concurrency control
Information management
Hardware
Recovery
Chemical analysis

ASJC Scopus subject areas

  • Computer Science (miscellaneous)
  • Computer Science(all)

Cite this

Locking key ranges with unbundled transaction services. / Lomet, David; Mokbel, Mohamed.

In: Proceedings of the VLDB Endowment, Vol. 2, No. 1, 01.01.2009, p. 265-276.

Research output: Contribution to journalArticle

@article{ae2c1b058c32405c9f953f27664895ed,
title = "Locking key ranges with unbundled transaction services",
abstract = "To adapt database technology to new environments like cloud platforms or multi-core hardware, or to try anew to provide an extensible database platform, it is useful to separate transaction services from data management elements that need close physical proximity to data. With {"}generic{"} transactional services of concurrency control and recovery in a separate transactional component (TC), indexing, cache and disk management, now in a data component (DC), can be simplified and tailored more easily to the platform or to a data type extension with a special purpose index. This de-composition requires that details of the DC's management of data be hidden from the TC. Thus, locking and logging need to be {"}logical{"}, which poses a number of problems. One problem is the handling of locking for ranges of keys. Locks need to be taken at the TC prior to the records and their keys being known to the TC. We describe generic two approaches for dealing with this. (1) Make a {"}speculative{"} visit{"} to the DC to learn key values. (2) Lock a {"}covering resource{"} first, then learn and lock key values and ultimately release the covering resource lock. The {"}table{"} is the only logical (and hence known to the TC) covering resourse in the traditional locking hierarchy, but using it limits con-currency. Concurrency is improved with the introduction of new partition resources. We show how partitions as covering resources combine high concurrency with low locking over-head. Using partitions is sufficiently effective to consider adapting it for a traditional database kernel.",
author = "David Lomet and Mohamed Mokbel",
year = "2009",
month = "1",
day = "1",
doi = "10.14778/1687627.1687658",
language = "English",
volume = "2",
pages = "265--276",
journal = "Proceedings of the VLDB Endowment",
issn = "2150-8097",
publisher = "Very Large Data Base Endowment Inc.",
number = "1",

}

TY - JOUR

T1 - Locking key ranges with unbundled transaction services

AU - Lomet, David

AU - Mokbel, Mohamed

PY - 2009/1/1

Y1 - 2009/1/1

N2 - To adapt database technology to new environments like cloud platforms or multi-core hardware, or to try anew to provide an extensible database platform, it is useful to separate transaction services from data management elements that need close physical proximity to data. With "generic" transactional services of concurrency control and recovery in a separate transactional component (TC), indexing, cache and disk management, now in a data component (DC), can be simplified and tailored more easily to the platform or to a data type extension with a special purpose index. This de-composition requires that details of the DC's management of data be hidden from the TC. Thus, locking and logging need to be "logical", which poses a number of problems. One problem is the handling of locking for ranges of keys. Locks need to be taken at the TC prior to the records and their keys being known to the TC. We describe generic two approaches for dealing with this. (1) Make a "speculative" visit" to the DC to learn key values. (2) Lock a "covering resource" first, then learn and lock key values and ultimately release the covering resource lock. The "table" is the only logical (and hence known to the TC) covering resourse in the traditional locking hierarchy, but using it limits con-currency. Concurrency is improved with the introduction of new partition resources. We show how partitions as covering resources combine high concurrency with low locking over-head. Using partitions is sufficiently effective to consider adapting it for a traditional database kernel.

AB - To adapt database technology to new environments like cloud platforms or multi-core hardware, or to try anew to provide an extensible database platform, it is useful to separate transaction services from data management elements that need close physical proximity to data. With "generic" transactional services of concurrency control and recovery in a separate transactional component (TC), indexing, cache and disk management, now in a data component (DC), can be simplified and tailored more easily to the platform or to a data type extension with a special purpose index. This de-composition requires that details of the DC's management of data be hidden from the TC. Thus, locking and logging need to be "logical", which poses a number of problems. One problem is the handling of locking for ranges of keys. Locks need to be taken at the TC prior to the records and their keys being known to the TC. We describe generic two approaches for dealing with this. (1) Make a "speculative" visit" to the DC to learn key values. (2) Lock a "covering resource" first, then learn and lock key values and ultimately release the covering resource lock. The "table" is the only logical (and hence known to the TC) covering resourse in the traditional locking hierarchy, but using it limits con-currency. Concurrency is improved with the introduction of new partition resources. We show how partitions as covering resources combine high concurrency with low locking over-head. Using partitions is sufficiently effective to consider adapting it for a traditional database kernel.

UR - http://www.scopus.com/inward/record.url?scp=77954891696&partnerID=8YFLogxK

UR - http://www.scopus.com/inward/citedby.url?scp=77954891696&partnerID=8YFLogxK

U2 - 10.14778/1687627.1687658

DO - 10.14778/1687627.1687658

M3 - Article

AN - SCOPUS:77954891696

VL - 2

SP - 265

EP - 276

JO - Proceedings of the VLDB Endowment

JF - Proceedings of the VLDB Endowment

SN - 2150-8097

IS - 1

ER -