EDRC: An Early Data Lending-Based Real-Time Commit Protocol

EDRC: An Early Data Lending-Based Real-Time Commit Protocol

Sarvesh Pandey, Udai Shanker
Copyright: © 2021 |Pages: 15
DOI: 10.4018/978-1-7998-3479-3.ch055
OnDemand:
(Individual Chapters)
Available
$33.75
List Price: $37.50
10% Discount:-$3.75
TOTAL SAVINGS: $3.75

Abstract

Advancing the distributed real-time database systems (DRTDBS) performance requires critical consideration of the reasons for data inaccessibility (i.e., predictability and consistency, scheduling and conflict resolution schemes, and commit process). Traditionally, execute-commit conflict is handled through the two-phase commit protocol to ensure the consistency of the database by blocking an incoming cohort intending to access the data item(s) already locked by other prepared cohort. Such blocking makes the transaction execution time of incoming cohort unpredictable due to unbounded waiting time. This chapter proposes an early data lending-based real-time commit (EDRC) protocol that increases data accessibility by providing the means to start the lending process early. Furthermore, lender is permitted to lend its uncommitted data items just after the completion of data processing task. The EDRC protocol outperforms state-of-the-art distributed commit protocols particularly PROMPT, 2SC, and SWIFT under all load conditions.
Chapter Preview
Top

Introduction

The advanced Distributed Database System (DDBS), with the integration of ‘real-time’ attribute to each transaction, makes sure that results are produced within a stipulated deadline while maintaining the consistency. Such systems are broadly studied under the umbrella of the research area named Distributed Real Time Database System (DRTDBS). In simple, they are time constrained DDBSs (Pandey & Shanker, 2018a). In the DRTDBS, the distributed real-time transaction (DRTT) is invoked to perform changes at multiple sites atomically. Here, the correctness of the result depends on two things: logical computation performed, and the time when the result is produced. Even if the result produced is functionally right, it may lead to tragic repercussions, be unusable, or has less value if it is not produced in time (Shanker, Misra, & Sarje, 2001).

Based on the consequences of their deadline misses, DRTTs may be categorized as soft, firm and hard. The soft DRTT is not killed/aborted in case of its deadline miss because the result has some value (obviously degrading) even after the deadline miss. The firm DRTT is killed in case it misses its deadline because its outcome has no value after the deadline miss. In addition, allowing the execution of firm DRTT after its deadline expiry may also lead to deadline expiration of other concurrently executing firm DRTTs requiring access to resources already locked by it. The hard DRTT must be finished before its deadline; otherwise, it may lead to a potentially catastrophic consequence.

Scheduling concurrent execution of DRTTs is extremely complex as the goal of database management algorithms is not only to maintain database consistency but also to ensure that timing constraints are met. Issues such as data conflicts, site failures, communication delays, interaction through the underlying operating system and I/O subsystem are major obstacles in meeting the deadlines of concurrently executing DRTTs (Shanker U., 2008). Among all these, the data conflict problem is a key factor that adversely affects system performance; it can be categorized as Execute-Execute Conflict and Execute-Commit Conflict. The Execute-Execute conflict may occur amongst executing transactions. A considerable research investigation has been carried out to resolve this conflict. For detailed knowledge about the Execute-Execute conflict and strategies proposed for its resolution, the readers may go through (Shanker, Misra, & Sarje, 2008). The Execute-Commit conflict may occur between executing and committing transactions. It occurs only if one of the transactions involved in data conflict is in a PREPARED state. The real-time concurrency control protocol resolves execute-execute conflict while the real-time commit protocol, an optimistic implementation of 2-Phase Commit (2PC) protocol with relaxed ACID property, resolves execute-commit conflict.

To overcome execute-commit conflicts, the lender-borrower approach is commonly used in next generation commit protocols — which are not only of optimistic nature, but also intended to satisfy real-time constraints. Such real-time commit protocols permit prepared lender cohorts to lend their modified and uncommitted data items to executing borrower cohorts in case of occurrence of Execute-Commit conflict between them. This reduces data inaccessibility. Thus, they improve DRTDBS performance. They, however, usually do not permit the borrower cohort to send WORKDONE/PREPARED message, and thus, increase the borrowing transactions’ commit time. Hence, designing efficient real-time commit protocol is a vital issue as it largely affects the DRTDBS performance.

Key Terms in this Chapter

Locking-Processing Conflict: The locking-processing conflict is handled based on the status of the cohort i.e. whether it has sent WORKSTARTED message or not, and lending may be allowed only when the cohort has already sent WORKSTARTED message.

Soft Distributed Real-Time Transaction(Soft DRTT): The soft DRTT is not killed/aborted in case of its deadline miss because the result has some value (obviously degrading) even after the deadline miss.

Firm Distributed Real-Time Transaction (Firm DRTT): The firm DRTT is killed in case it misses its deadline because its outcome has no value after the deadline miss.

Locking-Committing Conflict: The locking-committing conflict is handled in the same way as execute-commit conflict.

Real-Time Commit Protocols: Ensure that either all the effects of the DRTT persist or none of them irrespective of any such failure.

Locking-Locking Conflict: The locking-locking conflict is handled simply by aborting the DRTT with low priority in case of priority inversion.

Hard Distributed Real-Time Transaction (Hard DRTT): The hard DRTT must be finished before its deadline; otherwise, it may lead to a potentially catastrophic consequence.

Complete Chapter List

Search this Book:
Reset