MECP: A Memory Efficient Real Time Commit Protocol

MECP: A Memory Efficient Real Time Commit Protocol

Udai Shanker, Manoj Misra, Anil K. Sarje
DOI: 10.4018/978-1-60566-242-8.ch079
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

Important data base system resources are the data items that can be viewed as logical resource, and CPU, disks and the main memory which are physical resources [Garcia-Molina et al. 1992]. Though, the cost of main memory is dropping rapidly and its size is increasing, the size of database is also increasing very rapidly. In real time applications, where the databases are of limited size or are growing at a slower rate than memory capacities are growing, they can be kept in the main memory. However, there are many real time applications, which handle large amount of data and require support of an intensive transaction processing. The amount of data they store is too large (and too expensive) to be stored in the main memory.
Chapter Preview
Top

Background

The development of commit protocols for the traditional database systems has been an area of extensive research in the past decade. However, in case of distributed real time commit protocols, very little amount of the work has been reported in the literature. The real time commit protocol Permits Reading of Modified Prepared-Data for Timeliness (PROMPT) and deadline-driven conflict resolution (DDCR) commit protocol were proposed by Gupta et al. and Lam et al. respectively [Lam et al. 1999; Haritsa et al. 2000]. Based on the concepts of PROMPT and DDCR, Biao Qin and Yunsheng Liu proposed a new commit protocol double space commit (2SC) [Qin et al. 2003]. All the above protocols consume considerable amount of main memory for maintaining the intermediate temporary records created during the execution of transactions. In PROMPT, the lender maintains extra data structures to record the types of dependencies of its borrowers and DDCR uses more than one copy of the data items (i.e. before, after and further).

All of this not only requires extra memory but also creates additional workload on the system. Furthermore, the locking scheme used by PROMPT and 2SC protocols specifies the lock held by the lender only and these protocols either use read-before-write model or write only (blind write) model. The effect of using both models collectively has not been investigated in any previous work. So, another significant difference between our work and the works reviewed above is that we have considered both blind write (a read is not performed before the data item is written) as well as update (read-before-write). A blind-write model is not unrealistic [Burger et al. 1997] and it occurs in real life information processing for example, recording and editing new telephone numbers, opening new accounts, changing addresses etc. There are also many applications such as banking, intelligent network services database etc. where we need write without ever read model.

Key Terms in this Chapter

Blind Write: A read is not performed before the data item is written.

Update: Read before write.

Atomic Commit Protocols: Ensures that either all the effects of the transaction persist or none of them persist despite of the site or communication link failures and loss of messages.

Lender: The transaction that has lent their modified data to newly arrived cohorts

Firm Real Time Transaction: A firm real time transaction loses its value after its deadline expires.

Borrower: The transaction using modified but uncommitted data of lenders.

Distributed Real Time Database Systems: Collection of multiple, logically inter-related databases distributed over a computer network where transactions have explicit timing constraints, usually in the form of deadlines.

Complete Chapter List

Search this Book:
Reset