One-phase commit: does it make sense?

Abdallah, Maha; Guerraoui, Rachid; Pelletier, Philippe

doi:10.1109/icpads.1998.741040

Cited by 31 publications

(34 citation statements)

References 9 publications

(24 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…(2) One Phase Commit Protocols [3,9,51]. Due to a series of synchronous messages and logging cost, commit processing can result in a significant increase in the transaction execution time.…”

Section: Real Time Commit Protocolsmentioning

confidence: 99%

Distributed real time database systems: background and literature review

Shanker

Misra

Sarje

2008

Distrib Parallel Databases

View full text Add to dashboard Cite

Today's real-time systems (RTS) are characterized by managing large volumes of dispersed data making real-time distributed data processing a reality. Large business houses need to do distributed processing for many reasons, and they often must do it in order to stay competitive. So, efficient database management algorithms and protocols for accessing and manipulating data are required to satisfy timing constraints of supported applications. Therefore, new research in distributed real-time database systems (DRTDBS) is needed to investigate possible ways of applying database systems technology to real-time systems. This paper first discusses the performance issues that are important to DRTDBS, and then surveys the research that has been done so far on the issues like priority assignment policy, commit protocols and optimizing the use of memory in non-replicated/replicated environment pertaining to distributed real time transaction processing. In fact, this study provides a foundation for addressing performance issues important for the management of very large real time data and pointer to other publications in journals and conference proceedings for further investigation of unanswered research questions.

show abstract

Section: Real Time Commit Protocolsmentioning

confidence: 99%

Distributed real time database systems: background and literature review

Shanker

Misra

Sarje

2008

Distrib Parallel Databases

View full text Add to dashboard Cite

show abstract

“…As observed in [44], 1-delay commit protocols proposed in [45,46] assumes that all processes propose 1 before an execution starts. Jiménez-Peris et al proposed a commit service which has the same latency as 2PC but allows a process to decide twice and differently.…”

Section: Low-latency Commit Protocols With Weak Semanticsmentioning

confidence: 99%

How Fast can a Distributed Transaction Commit?

Guerraoui

Wang

2017

Proceedings of the 36th ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems

View full text Add to dashboard Cite

The atomic commit problem lies at the heart of distributed database systems. The problem consists for a set of processes (database nodes) to agree on whether to commit or abort a transaction (agreement property). The commit decision can only be taken if all processes are initially willing to commit the transaction, and this decision must be taken if all processes are willing to commit and there is no failure (validity property). An atomic commit protocol is said to be non-blocking if every correct process (a database node that does not fail) eventually reaches a decision (commit or abort) even if there are failures elsewhere in the distributed database system (termination property).Surprisingly, despite the importance of the atomic commit problem, little is known about its complexity. In this paper, we present, for the first time, a systematic study on the time and message complexity of the problem. We measure complexity in the executions that are considered the most frequent in practice, i.e., failure-free, with all processes willing to commit. In other words, we measure how fast a transaction can commit. Through our systematic study, we close many open questions like the complexity of synchronous non-blocking atomic commit. We also present optimal protocols which may be of independent interest. In particular, we present an effective protocol which solves what we call indulgent atomic commit that tolerates practical distributed database systems which are synchronous "most of the time".

show abstract

“…However, the problem of transaction blocking in the sense of Definition 2, which occurs when the executing database disconnects from the network after sending the voteCommit message, has, to the authors' knowledge, not been studied yet. Even 1PC [1,2], which does not require a vote message but acknowledges each operation, encounters the problem of transaction blocking since each acknowledged operation that accesses a data tuple must block this data tuple until the transaction is successfully completed. Our solution relates to three ideas that are used in different contexts: Escrow locks [11], speculative locking [21], and multiversion databases [6,7,13].…”

Section: Related Workmentioning

confidence: 99%

A DBMS for Mobile Transactions Using Bi-State-Termination

Obermeier¹,

Böttcher²

2010

IJDMS

View full text Add to dashboard Cite

Whenever distributed transaction processing in MANETs or other unreliable networks has to guarantee atomicity and isolation, a major challenge is how long-term blocking of resources can be avoided in case the mobile device looses connection to other participants of the transaction. We present a new technique for treating blocked data of transaction participants that wait for a coordinator's commit decision. Our technique, Bi-State-Termination (BST), gives participants that have moved during transaction execution the possibility to continue transaction processing before they know the coordinator's decision on transaction commit. The key idea of our technique is to consider both possible outcomes (commit and abort) of unknown transaction decisions. Within this paper, we describe a fast implementation of the fundamental relational database operations for a DBMS supporting the BST transaction synchronization protocol that avoids longterm transaction blocking.

show abstract

One-phase commit: does it make sense?

Cited by 31 publications

References 9 publications

Distributed real time database systems: background and literature review

Distributed real time database systems: background and literature review

How Fast can a Distributed Transaction Commit?

A DBMS for Mobile Transactions Using Bi-State-Termination

Contact Info

Product

Resources

About