Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Vishal Kathuria

dblp:82/1415 · DBLP profile ↗
← Back
1ranked-venue papers
1as first author
0since 2021 · last 2007
—ORCID · unresolved

Domains — the database's venue-derived domains; a paper can count in several

Databases, data management, data science and information retrieval · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Databases, data mining, and information retrieval
1 paper
Transaction processing and concurrency control · 100%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
Storage systems · 100%

Topics — the 3 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Transaction processing and concurrency control › ACID transactions
durability
0.112007
Transaction Isolation and Lazy Commit · ICDE 2007
Transaction processing and concurrency control
transaction isolation
0.112007
Transaction Isolation and Lazy Commit · ICDE 2007
Storage systems
log management
0.012007
Transaction Isolation and Lazy Commit · ICDE 2007
YearPublicationVenuePosition
2007 Transaction Isolation and Lazy Commit
abstract
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.
Vishal Kathuria, Robin Dhamankar, Hanuma Kodavalla
ICDE1