TY - JOUR
T1 - Locking key ranges with unbundled transaction services
AU - Lomet, David
AU - Mokbel, Mohamed F.
PY - 2009
Y1 - 2009
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
SN - 2150-8097
VL - 2
SP - 265
EP - 276
JO - Proceedings of the VLDB Endowment
JF - Proceedings of the VLDB Endowment
IS - 1
ER -