DOCSLIB.ORG

Commit Processing in Distributed Real-Time Database Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Commit Processing in Distributed Real-Time Database Systems 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.
Load more

Recommended publications
  • Rainblock: Faster Transaction Processing in Public Blockchains
    RainBlock: Faster Transaction Processing in Public Blockchains Soujanya Ponnapalli1, Aashaka Shah1, Souvik Banerjee1, Dahlia Malkhi2, Amy Tai3, Vijay Chidambaram1,3, and Michael Wei3 1University of Texas at Austin, 2Diem Association and Novi Financial, 3VMware Research Abstract Metric No state State: 10M Ratio We present RAINBLOCK, a public blockchain that achieves Time taken to mine txs (s) 1047 6340 6× " high transaction throughput without modifying the proof-of- # Txs per block 2150 833 2.5× # work consensus. The chief insight behind RAINBLOCK is that Tx throughput (txs/s) 28.6 4.7 6× # while consensus controls the rate at which new blocks are added to the blockchain, the number of transactions in each Table 1: Impact of system state on blockchain throughput. block is limited by I/O bottlenecks. Public blockchains like This table shows the throughput of Ethereum with proof-of- Ethereum keep the number of transactions in each block low work consensus when 30K txs are mined using three miners, so that all participating servers (miners) have enough time to in two scenarios: first, there are no accounts on the blockchain, process a block before the next block is created. By removing and in the second, 10M accounts have been added. Despite the I/O bottlenecks in transaction processing, RAINBLOCK al- no other difference, tx throughput is 6× lower in the second lows miners to process more transactions in the same amount scenario; we trace this to the I/O involved in processing txs. of time. RAINBLOCK makes two novel contributions: the RAIN- BLOCK architecture that removes I/O from the critical path of processing transactions (txs), and the distributed, multi- Bitcoin [1] and Ethereum, process only tens of transactions versioned DSM-TREE data structure that stores the system per second, limiting their applications [33, 65].
    [Show full text]
  • Let's Talk About Storage & Recovery Methods for Non-Volatile Memory
    Let’s Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems Joy Arulraj Andrew Pavlo Subramanya R. Dulloor [email protected] [email protected] [email protected] Carnegie Mellon University Carnegie Mellon University Intel Labs ABSTRACT of power, the DBMS must write that data to a non-volatile device, The advent of non-volatile memory (NVM) will fundamentally such as a SSD or HDD. Such devices only support slow, bulk data change the dichotomy between memory and durable storage in transfers as blocks. Contrast this with volatile DRAM, where a database management systems (DBMSs). These new NVM devices DBMS can quickly read and write a single byte from these devices, are almost as fast as DRAM, but all writes to it are potentially but all data is lost once power is lost. persistent even after power loss. Existing DBMSs are unable to take In addition, there are inherent physical limitations that prevent full advantage of this technology because their internal architectures DRAM from scaling to capacities beyond today’s levels [46]. Using are predicated on the assumption that memory is volatile. With a large amount of DRAM also consumes a lot of energy since it NVM, many of the components of legacy DBMSs are unnecessary requires periodic refreshing to preserve data even if it is not actively and will degrade the performance of data intensive applications. used. Studies have shown that DRAM consumes about 40% of the To better understand these issues, we implemented three engines overall power consumed by a server [42]. in a modular DBMS testbed that are based on different storage Although flash-based SSDs have better storage capacities and use management architectures: (1) in-place updates, (2) copy-on-write less energy than DRAM, they have other issues that make them less updates, and (3) log-structured updates.
    [Show full text]
  • Not ACID, Not BASE, but SALT a Transaction Processing Perspective on Blockchains
    Not ACID, not BASE, but SALT A Transaction Processing Perspective on Blockchains Stefan Tai, Jacob Eberhardt and Markus Klems Information Systems Engineering, Technische Universitat¨ Berlin fst, je, [email protected] Keywords: SALT, blockchain, decentralized, ACID, BASE, transaction processing Abstract: Traditional ACID transactions, typically supported by relational database management systems, emphasize database consistency. BASE provides a model that trades some consistency for availability, and is typically favored by cloud systems and NoSQL data stores. With the increasing popularity of blockchain technology, another alternative to both ACID and BASE is introduced: SALT. In this keynote paper, we present SALT as a model to explain blockchains and their use in application architecture. We take both, a transaction and a transaction processing systems perspective on the SALT model. From a transactions perspective, SALT is about Sequential, Agreed-on, Ledgered, and Tamper-resistant transaction processing. From a systems perspec- tive, SALT is about decentralized transaction processing systems being Symmetric, Admin-free, Ledgered and Time-consensual. We discuss the importance of these dual perspectives, both, when comparing SALT with ACID and BASE, and when engineering blockchain-based applications. We expect the next-generation of decentralized transactional applications to leverage combinations of all three transaction models. 1 INTRODUCTION against. Using the admittedly contrived acronym of SALT, we characterize blockchain-based transactions There is a common belief that blockchains have the – from a transactions perspective – as Sequential, potential to fundamentally disrupt entire industries. Agreed, Ledgered, and Tamper-resistant, and – from Whether we are talking about financial services, the a systems perspective – as Symmetric, Admin-free, sharing economy, the Internet of Things, or future en- Ledgered, and Time-consensual.
    [Show full text]
  • Failures in DBMS
    Chapter 11 Database Recovery 1 Failures in DBMS Two common kinds of failures StSystem filfailure (t)(e.g. power outage) ‒ affects all transactions currently in progress but does not physically damage the data (soft crash) Media failures (e.g. Head crash on the disk) ‒ damagg()e to the database (hard crash) ‒ need backup data Recoveryyp scheme responsible for handling failures and restoring database to consistent state 2 Recovery Recovering the database itself Recovery algorithm has two parts ‒ Actions taken during normal operation to ensure system can recover from failure (e.g., backup, log file) ‒ Actions taken after a failure to restore database to consistent state We will discuss (briefly) ‒ Transactions/Transaction recovery ‒ System Recovery 3 Transactions A database is updated by processing transactions that result in changes to one or more records. A user’s program may carry out many operations on the data retrieved from the database, but the DBMS is only concerned with data read/written from/to the database. The DBMS’s abstract view of a user program is a sequence of transactions (reads and writes). To understand database recovery, we must first understand the concept of transaction integrity. 4 Transactions A transaction is considered a logical unit of work ‒ START Statement: BEGIN TRANSACTION ‒ END Statement: COMMIT ‒ Execution errors: ROLLBACK Assume we want to transfer $100 from one bank (A) account to another (B): UPDATE Account_A SET Balance= Balance -100; UPDATE Account_B SET Balance= Balance +100; We want these two operations to appear as a single atomic action 5 Transactions We want these two operations to appear as a single atomic action ‒ To avoid inconsistent states of the database in-between the two updates ‒ And obviously we cannot allow the first UPDATE to be executed and the second not or vice versa.
    [Show full text]
  • What Is a Database Management System? What Is a Transaction
    What is a Database? Collection of data central to some enterprise Overview of Databases and Essential to operation of enterprise Transaction Processing Contains the only record of enterprise activity An asset in its own right Chapter 1 Historical data can guide enterprise strategy Of interest to other enterprises State of database mirrors state of enterprise Database is persistent 2 What is a Database Management What is a Transaction? System? When an event in the real world changes the A Database Management System (DBMS) state of the enterprise, a transaction is is a program that manages a database: executed to cause the corresponding change in the database state Supports a high-level access language (e.g. With an on-line database, the event causes the SQL). transaction to be executed in real time Application describes database accesses using A transaction is an application program that language. with special properties - discussed later - to DBMS interprets statements of language to guarantee it maintains database correctness perform requested database access. 3 4 What is a Transaction Processing Transaction Processing System System? Transaction execution is controlled by a TP monitor s DBMS database n o i Creates the abstraction of a transaction, t c a analogous to the way an operating system s n a r creates the abstraction of a process t DBMS database TP monitor and DBMS together guarantee the special properties of transactions TP Monitor A Transaction Processing System consists of TP monitor, databases, and transactions 5 6 1 System
    [Show full text]
  • What Is Nosql? the Only Thing That All Nosql Solutions Providers Generally Agree on Is That the Term “Nosql” Isn’T Perfect, but It Is Catchy
    NoSQL GREG SYSADMINBURD Greg Burd is a Developer Choosing between databases used to boil down to examining the differences Advocate for Basho between the available commercial and open source relational databases . The term Technologies, makers of Riak. “database” had become synonymous with SQL, and for a while not much else came Before Basho, Greg spent close to being a viable solution for data storage . But recently there has been a shift nearly ten years as the product manager for in the database landscape . When considering options for data storage, there is a Berkeley DB at Sleepycat Software and then new game in town: NoSQL databases . In this article I’ll introduce this new cat- at Oracle. Previously, Greg worked for NeXT egory of databases, examine where they came from and what they are good for, and Computer, Sun Microsystems, and KnowNow. help you understand whether you, too, should be considering a NoSQL solution in Greg has long been an avid supporter of open place of, or in addition to, your RDBMS database . source software. [email protected] What Is NoSQL? The only thing that all NoSQL solutions providers generally agree on is that the term “NoSQL” isn’t perfect, but it is catchy . Most agree that the “no” stands for “not only”—an admission that the goal is not to reject SQL but, rather, to compensate for the technical limitations shared by the majority of relational database implemen- tations . In fact, NoSQL is more a rejection of a particular software and hardware architecture for databases than of any single technology, language, or product .
    [Show full text]
  • Oracle Nosql Database
    An Oracle White Paper November 2012 Oracle NoSQL Database Oracle NoSQL Database Table of Contents Introduction ........................................................................................ 2 Technical Overview ............................................................................ 4 Data Model ..................................................................................... 4 API ................................................................................................. 5 Create, Remove, Update, and Delete..................................................... 5 Iteration ................................................................................................... 6 Bulk Operation API ................................................................................. 7 Administration .................................................................................... 7 Architecture ........................................................................................ 8 Implementation ................................................................................... 9 Storage Nodes ............................................................................... 9 Client Driver ................................................................................. 10 Performance ..................................................................................... 11 Conclusion ....................................................................................... 12 1 Oracle NoSQL Database Introduction NoSQL databases
    [Show full text]
  • The Integration of Database Systems
    Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1993 The Integration of Database Systems Tony Schaller Omran A. Bukhres Ahmed K. Elmagarmid Purdue University, [email protected] Xiangning Liu Report Number: 93-046 Schaller, Tony; Bukhres, Omran A.; Elmagarmid, Ahmed K.; and Liu, Xiangning, "The Integration of Database Systems" (1993). Department of Computer Science Technical Reports. Paper 1061. https://docs.lib.purdue.edu/cstech/1061 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. The Integration of Database Systems Tony Schaller, Omran A. Bukhres, Ahmed K. Elmagarmid and Xiangning Liu CSD-TR-93-046 July 1993 I I The Integration of Database Systems Tony Schaller Molecular Design Ltd. 2132 Farallon Drive San Leandro, CA 94577 Omran A. Bukhres, Ahmed K. Elmagarmid and Xiangning Liu DeparLment of Computer Sciences Purdue University West Lafayette, IN 47907 eJIlail: {bukhres,ake,xl} .es.purdue.edu 1 Introduction A database system is composed of two elements: a software program, called a database management system, and a set of data, called a database. The data in a database is organized according to some data model, such as the relational model used in a DB2 database [DW88] or the hierarchical model found with IMS databases [Dat77] . Users access the data through an interface (the query language) provided by the database management system. A schema describes the actual data structures and organization within the system. During the decade ofthe nineteen-seventies, centralized databases were predominant, but recent innovations in communications and database technologies have engendered a revolution in data processing, giving rlse to a new generation of decentralized database systems.
    [Show full text]
  • Transaction Processing Monitors
    Chapter 24: Advanced Transaction Processing ! Transaction-Processing Monitors ! Transactional Workflows ! High-Performance Transaction Systems ! Main memory databases ! Real-Time Transaction Systems ! Long-Duration Transactions ! Transaction management in multidatabase systems 1 Database System Concepts 24.1 ©Silberschatz, Korth and Sudarshan Transaction Processing Monitors ! TP monitors initially developed as multithreaded servers to support large numbers of terminals from a single process. ! Provide infrastructure for building and administering complex transaction processing systems with a large number of clients and multiple servers. ! Provide services such as: ! Presentation facilities to simplify creating user interfaces ! Persistent queuing of client requests and server responses ! Routing of client messages to servers ! Coordination of two-phase commit when transactions access multiple servers. ! Some commercial TP monitors: CICS from IBM, Pathway from Tandem, Top End from NCR, and Encina from Transarc 2 Database System Concepts 24.2 ©Silberschatz, Korth and Sudarshan 1 TP Monitor Architectures 3 Database System Concepts 24.3 ©Silberschatz, Korth and Sudarshan TP Monitor Architectures (Cont.) ! Process per client model - instead of individual login session per terminal, server process communicates with the terminal, handles authentication, and executes actions. ! Memory requirements are high ! Multitasking- high CPU overhead for context switching between processes ! Single process model - all remote terminals connect to a single server process. ! Used in client-server environments ! Server process is multi-threaded; low cost for thread switching ! No protection between applications ! Not suited for parallel or distributed databases 4 Database System Concepts 24.4 ©Silberschatz, Korth and Sudarshan 2 TP Monitor Architectures (Cont.) ! Many-server single-router model - multiple application server processes access a common database; clients communicate with the application through a single communication process that routes requests.
    [Show full text]
  • High-Performance Transaction Processing in SAP HANA
    High-Performance Transaction Processing in SAP HANA Juchang Lee1, Michael Muehle1, Norman May1, Franz Faerber1, Vishal Sikka1, Hasso Plattner2, Jens Krueger2, Martin Grund3 1SAP AG 2Hasso Plattner Insitute, Potsdam, Germany, 3eXascale Infolab, University of Fribourg, Switzerland Abstract Modern enterprise applications are currently undergoing a complete paradigm shift away from tradi- tional transactional processing to combined analytical and transactional processing. This challenge of combining two opposing query types in a single database management system results in additional re- quirements for transaction management as well. In this paper, we discuss our approach to achieve high throughput for transactional query processing while allowing concurrent analytical queries. We present our approach to distributed snapshot isolation and optimized two-phase commit protocols. 1 Introduction An efficient and holistic data management infrastructure is one of the key requirements for making the right deci- sions at an operational, tactical, and strategic level and is core to support all kinds of enterprise applications[12]. In contrast to traditional architectures of database systems, the SAP HANA database takes a different approach to provide support for a wide range of data management tasks. The system is organized in a main-memory centric fashion to reflect the shift within the memory hierarchy[2] and to consistently provide high perfor- mance without prohibitively slow disk interactions. Completely transparent for the application, data is orga- nized along its life cycle either in column or row format, providing the best performance for different workload characteristics[11, 1]. Transactional workloads with a high update rate and point queries can be routed against a row store; analytical workloads with range scans over large datasets are supported by column oriented data struc- tures.
    [Show full text]
  • High Volume Transaction Processing Without Concurrency Control, Two Phase Commit, SQL Or
    High Volume Transaction Pro cessing Without Concurrency Control Two Phase Commit SQL or C Arthur Whitney Dennis Shasha Stevan Apter KX Systems Courant Institute NYU Union Bank of Switzerland Harker Avenue Mercer Street Park Avenue Palo Alto CA New York NY New York NY Abstract Imagine an application environment in which subsecond response to thousands of events gives the user a distinct competitive advantage yet transactional guarantees are important Imag ine also that the data ts comfortably into a few gigabytes of Random Access Memory These attributes characterize many nancial trading applications Which engine should one use in such a case IBM FastPath Sybase Oracle or Object Store We argue that an unconventional approach is cal led for we use a listbased language cal led K having optimized support for bulk array operators and that integrates networking and a graphical user interface Locking is unnecessary when singlethreading such applications because the data ts into memory obviating the need to go to disk except for logging purposes Multithreading can be hand led for OLTP applications by analyzing the arguments to transactions The result is a private sizereduced TPCB benchmark that achieves transactions per second with ful l recoverability and TCPIP overhead on an Megahertz UltraSparc I Further hot disaster recovery can be done with far less overhead than required by two phase commit by using a sequential state machine approach We show how to exploit multiple processors without complicating the language or our basic framework
    [Show full text]
  • A Transaction Processing Method for Distributed Database
    Advances in Computer Science Research, volume 87 3rd International Conference on Mechatronics Engineering and Information Technology (ICMEIT 2019) A Transaction Processing Method for Distributed Database Zhian Lin a, Chi Zhang b School of Computer and Cyberspace Security, Communication University of China, Beijing, China [email protected], [email protected] Abstract. This paper introduces the distributed transaction processing model and two-phase commit protocol, and analyses the shortcomings of the two-phase commit protocol. And then we proposed a new distributed transaction processing method which adds heartbeat mechanism into the two- phase commit protocol. Using the method can improve reliability and reduce blocking in distributed transaction processing. Keywords: distributed transaction, two-phase commit protocol, heartbeat mechanism. 1. Introduction Most database services of application systems will be distributed on several servers, especially in some large-scale systems. Distributed transaction processing will be involved in the execution of business logic. At present, two-phase commit protocol is one of the methods to distributed transaction processing in distributed database systems. The two-phase commit protocol includes coordinator (transaction manager) and several participants (databases). In the process of communication between the coordinator and the participants, if the participants without reply for fail, the coordinator can only wait all the time, which can easily cause system blocking. In this paper, heartbeat mechanism is introduced to monitor participants, which avoid the risk of blocking of two-phase commit protocol, and improve the reliability and efficiency of distributed database system. 2. Distributed Transactions 2.1 Distributed Transaction Processing Model In a distributed system, each node is physically independent and they communicates and coordinates each other through the network.
    [Show full text]