Transaction Isolation and Lazy Commit
In order to guarantee durability of transactions (D in the ACID properties) database systems issue a synchronous log write on transaction commit. However, in many scenarios such as queue processing and personal information management systems, durability on commit is not required as the transactions...
Gespeichert in:
Hauptverfasser: | , , |
---|---|
Format: | Tagungsbericht |
Sprache: | eng |
Schlagworte: | |
Online-Zugang: | Volltext bestellen |
Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
Zusammenfassung: | In order to guarantee durability of transactions (D in the ACID properties) database systems issue a synchronous log write on transaction commit. However, in many scenarios such as queue processing and personal information management systems, durability on commit is not required as the transactions rolled back due to a crash can be reprocessed using the application state. Avoiding such synchronous I/O improves system throughput and response time. Also, when the database is running on a mobile device or a laptop, reduced I/O consumes less power and increases battery life - a significant consideration for mobile users. Transactions that do not require durability can be "lazily committed", i.e. the log is not written synchronously upon commit. If another transaction reads such lazily committed data and performs an independently committed external action based on it, then an inconsistency may result if the effects of the lazily committed transaction are lost in a crash. We present a solution that provides the efficiency of lazily committed transactions and the flexibility for other transactions to read only durably committed data. We demonstrate that even in the presence of a large number of readers requesting durably committed data our approach reduces I/Os significantly. |
---|---|
ISSN: | 1063-6382 2375-026X |
DOI: | 10.1109/ICDE.2007.368979 |