Commit Processing in Distributed Real-Time Database Systems Ramesh Gupta * Jayant Haritsa * Krithi Ramamritham j S. Seshadri * Abstract ity. Over the last two decades, a variety of commit protocols have been proposed by database researchers. We investigate here the performance implications of These include the classical two phase commit (2PC) supporting transaction atomicity in a distributed real- protocol [6], its variations such as presumed commit time database system. Using a detailed simulation and presumed abort [lo], and three phase commit [14]. model of a firm-deadline distributed real-time database To achieve their functionality, these commit protocols system, we profile the real-time performance of a repre- typically require exchange of multiple messages, in mul- sentative set of commit protocols. A new commit proto- tiple phases, between the participating sites where the col that is designed for the real-time domain and allows distributed transaction executed. In addition, several transactions to “optimistically” read uncommitted data log records are generated, some of which have to be is also proposed and evaluated, “forced”, that is, flushed to diik immediately. Due to The experimental results show that data distribution these costs, commit processing can result in a signif- has a significant influence on the real-time performance icant increase in transaction execution times, making and that the choice of commit protocol clearly affects the choice of commit protocol an important design de- the magnitude of this injhence. Among the protocols cision for distributed database systems. evaluated, the new optimistic commit protocol provides From a performance perspective, commit protocols the best performance for a variety of workloads and sys- can be compared on the following two issues: First, the tem configurations. extent to which the commit protocol affects the normal distributed transaction processing performance. That is, how expensive is it to provide atomicity? Second, 1. Introduction in the event of a site failure, the ability of the opera- tional sites to correctly terminate the transaction with- Many real-time database applications, especially in out waiting for recovery of the failed site. That is, is the areas of communication systems and military sys- the protocol “blocking” or “non-blocking”? tems, are inherently distributed in nature [15]. Incor- With respect to the above issues, the performance porating distributed data into the real-time database of a representative set of commit protocols has been framework incurs the well-known additional complex- analyzed to a limited extent in [4, lo]. These studies ities that are associated with transaction concurrency were conducted in the context of a conventional DBMS control and database recovery in distributed database where transaction throughput or response time is the systems [3, 111. While the issue of distributed real- primary performance metric. In a RTDBS, however, time concurrency control has been considered to some performance is usually measured in terms of the num- extent(e.g. [13, 16, 18]), comparatively little work ber of transactions that complete before their dead- has been done with regard to distributed real-time lines. Due to the difference in objectives, the perfor- database recovery. In this paper, we investigate the mance of commit protocols has to be reevaluated for performance implications of supporting transaction the real-time environment_ atomicity in a distributed real-time database system In the real-time domain, there are two major ques- (RTDBS). To the best of our knowledge, this is the tions that need to be explored: First, how do we adapt first quantitative evaluation of this issue. the commit protocols to the real-time domain? Sec- Distributed database systems implement a trans- ond, how do the real-time variants of the commit pro- action commit protocol to ensure transaction atomic- tocols compare in their performance? In this paper, we ‘SERC, Indian Institute of Science, Bangaiore 560012, India address these questions for the “firm-deadline” appli- tCOINS, University of Massachussetts, Amherst 01003, USA cation framework [S], wherein transactions that miss tCSE, Indian Institute of Technology, Bombay 400076, India their deadlines are considered to be worthless and are 220 1052~8’725/96 $5.00 0 1996 IEEE immediately “killed”, that is, aborted and discarded 2.1. tie Phase Commit Protocol from the system without being executed to comple- tion. Using a detailed simulation model of a dii- The master initiates the first phase of the protocol tributed database system, we compare the real-time by sending PREPARE (to commit) messages in par- performance of a representative set of commit proto- allel to all the cohorts. Each cohort that is ready to cols. The performance metric is the steady-state per- commit first force-writes a prepare log record to its lo- centage of transaction deadlines that are missed. cal stable storage and then sends a YES vote to the master. At this stage, the cohort has entered a pre- 1.1. Related Work pared state wherein it cannot unilaterally commit or abort the transaction but has to wait for the final deci- sion from the master. On the other hand, each cohort The design of real-time commit protocols has been that decides to abort force-writes an abort log record investigated earlier in [17, 191. These papers are based and sends a NO vote to the master. Since a NO vote on a common theme of allowing individual sites to uni- acts like a veto, the cohort is permitted to unilaterally laterally commit - the idea is that unilateral commit- abort the transaction without waiting for a response ment results in greater timeliness of actions. If it is from the master. later found that the decision is not consistent glob- ally, “compensation” transactions are executed to rec- After the master receives the votes from all the co- horts, it initiates the second phase of the protocol. If all tify the errors. the votes are YES, it moves to a committing state by While the compensation-based approach certainly forcewriting a commit log record and sending COM- appears to have the potential to improve timeliness, MIT messages to all the cohorts. Each cohort after there are quite a few practical difficulties: First, the receiving a COMMIT message moves to the commit- standard notion of transaction atomicity is not sup- ting state, force-writes a commit log record, and sends ported - instead, a “relaxed” notion of atomicity [9] is an ACK message to the master. provided. Second, the design of a compensating trans- If the master receives even one NO vote, it moves to action is an application-specific task since it is based the aborting state by force-writing an abort log record on application semantics. Third, compensation trans- and sends ABORT messages to those cohorts that are actions need to be designed in advance so that they can in the prepared state. These cohorts, after receiving be executed as soon as errors are detected - this means the ABORT message, move to the aborting state, force- that the transaction workload must be fully character- write an abort log record and send an ACK message ized a priori. Fourth, “real actions” such as firing a to the master. weapon or dispensing cash may not be compensatable Finally, the master, after receiving acknowledge- at all [9]. Finally, no performance studies are available ments from all the prepared cohorts, writes an end log to evaluate the effectiveness of this approach. record and then “forgets” the transaction. Due to the above limitations, we focus here instead on improving the real-time performance of the stan- dard mechanisms for maintaining distributed transac- 2.2. Presumed Abort tion atomicity. A variant of the 2PC protocol, called presumed abort (PA) [lo], tries to reduce the message and log- 2. Distributed Commit Protocols ging overheads by requiring all participants to follow a “in case of doubt, abort” rule. That is, if after coming A common model of a distributed transaction is that up from a failure a site queries the master about the there is one process, called the master, which is exe- final outcome of a transaction and finds no information cuted at the site where the transaction is submitted, available with the master, the transaction is assumed and a set of other processes, called cohorts, which ex- to have been aborted. With this assumption, it is not ecute on behalf of the transaction at the various sites necessary for cohorts to either send acknowledgments that are accessed by the transaction. For this model, for ABORT messages from the master or to force-write a variety of transaction commit protocols have been the abort record to the log. It is also not necessary for devised, most of which are based on the classical two the master to force-write the abort log record or to phase commit (2PC) protocol [S]. In this section, write an end log record after abort. we briefly describe the 2PC protocol and a few popular In short, the PA protocol behaves identically to 2PC variations of this protocol - complete descriptions are for committing transactions, but has reduced message available in [lo, 141. and logging overheads for aborted transactions. 221 2.3. Presumed Commit 3. Real-Time Commit Processing A variation of the presumed abort protocol is based The commit protocols described above were de- on the observation that, in general, the number of com- signed for conventional database systems and do not mitted transactions is much more than the number of take transaction priorities into account. In a real-time aborted transactions. In this variation, called pre- environment, this is clearly undesirable since it may sumed commit (PC) [lo], the overheads are reduced result in priority inversion [12], wherein high priority for committing transactions rather than aborted trans- transactions are made to wait by low priority trans- actions by requiring all participants to follow a “in case actions.