Using the lock manager to choose timestamps

David Lomet; Richard T. Snodgrass; Christian S. Jensen

doi:10.1109/IDEAS.2005.53

Using the lock manager to choose timestamps

David Lomet, Richard T. Snodgrass, Christian S. Jensen

Computer Science

Research output: Contribution to journal › Conference article › peer-review

3 Scopus citations

Abstract

Our goal is to support transaction-time functionality that enables the coexistence of ordinary, non-temporal tables with transaction-time tables. In such a system, each transaction updating a transaction-time or snapshot table must include a timestamp for its updated data that correctly reflects the serialization order of the transactions, including transactions on ordinary tables. A serious issue is coping with SQL CURRENT-TIME functions, which should return a time consistent with a transaction's timestamp and serialization order. Prior timestamping techniques cannot support such junctions with this desired semantics. We show how to compatibly extend conventional database functionality for transaction-time support by exploiting the database system lock manager and by utilizing a spectrum of optimizations.

Original language	English (US)
Article number	1540926
Pages (from-to)	357-368
Number of pages	12
Journal	Proceedings of the International Database Engineering and Applications Symposium, IDEAS
Volume	2005-January
Issue number	January
DOIs	https://doi.org/10.1109/IDEAS.2005.53
State	Published - 2005
Event	9th International Database Engineering and Application Symposium, IDEAS 2005 - Montreal, Canada Duration: Jul 25 2005 → Jul 27 2005

ASJC Scopus subject areas

Computer Science(all)
Engineering(all)

Access to Document

10.1109/IDEAS.2005.53

Cite this

@article{a2469aab80fb4e0d8fdefd756a5fbcf1,

title = "Using the lock manager to choose timestamps",

abstract = "Our goal is to support transaction-time functionality that enables the coexistence of ordinary, non-temporal tables with transaction-time tables. In such a system, each transaction updating a transaction-time or snapshot table must include a timestamp for its updated data that correctly reflects the serialization order of the transactions, including transactions on ordinary tables. A serious issue is coping with SQL CURRENT-TIME functions, which should return a time consistent with a transaction's timestamp and serialization order. Prior timestamping techniques cannot support such junctions with this desired semantics. We show how to compatibly extend conventional database functionality for transaction-time support by exploiting the database system lock manager and by utilizing a spectrum of optimizations.",

author = "David Lomet and Snodgrass, {Richard T.} and Jensen, {Christian S.}",

note = "Publisher Copyright: {\textcopyright} 2005 IEEE.; 9th International Database Engineering and Application Symposium, IDEAS 2005 ; Conference date: 25-07-2005 Through 27-07-2005",

year = "2005",

doi = "10.1109/IDEAS.2005.53",

language = "English (US)",

volume = "2005-January",

pages = "357--368",

journal = "Proceedings of the International Database Engineering and Applications Symposium, IDEAS",

issn = "1098-8068",

publisher = "Institute of Electrical and Electronics Engineers Inc.",

number = "January",

}

TY - JOUR

T1 - Using the lock manager to choose timestamps

AU - Lomet, David

AU - Snodgrass, Richard T.

AU - Jensen, Christian S.

PY - 2005

Y1 - 2005

N2 - Our goal is to support transaction-time functionality that enables the coexistence of ordinary, non-temporal tables with transaction-time tables. In such a system, each transaction updating a transaction-time or snapshot table must include a timestamp for its updated data that correctly reflects the serialization order of the transactions, including transactions on ordinary tables. A serious issue is coping with SQL CURRENT-TIME functions, which should return a time consistent with a transaction's timestamp and serialization order. Prior timestamping techniques cannot support such junctions with this desired semantics. We show how to compatibly extend conventional database functionality for transaction-time support by exploiting the database system lock manager and by utilizing a spectrum of optimizations.

AB - Our goal is to support transaction-time functionality that enables the coexistence of ordinary, non-temporal tables with transaction-time tables. In such a system, each transaction updating a transaction-time or snapshot table must include a timestamp for its updated data that correctly reflects the serialization order of the transactions, including transactions on ordinary tables. A serious issue is coping with SQL CURRENT-TIME functions, which should return a time consistent with a transaction's timestamp and serialization order. Prior timestamping techniques cannot support such junctions with this desired semantics. We show how to compatibly extend conventional database functionality for transaction-time support by exploiting the database system lock manager and by utilizing a spectrum of optimizations.

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

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

U2 - 10.1109/IDEAS.2005.53

DO - 10.1109/IDEAS.2005.53

M3 - Conference article

AN - SCOPUS:67649644292

SN - 1098-8068

VL - 2005-January

SP - 357

EP - 368

JO - Proceedings of the International Database Engineering and Applications Symposium, IDEAS

JF - Proceedings of the International Database Engineering and Applications Symposium, IDEAS

IS - January

M1 - 1540926

T2 - 9th International Database Engineering and Application Symposium, IDEAS 2005

Y2 - 25 July 2005 through 27 July 2005

ER -

Using the lock manager to choose timestamps

Abstract

ASJC Scopus subject areas

Access to Document

Other files and links

Fingerprint

Cite this