Description
TABLE OF CONTENTS
1 INTRODUCTION 2
1.1 Purpose……………………………………………………………….. 2
1.2 Objective……………………………………………………………… 2
1.3 Definitions, Acronyms, and Abbreviations. Abbreviations:…….. 2
1.3.1 Acronyms………………………………………………………. 2
1.3.2 Definitions ……………………………………………………… 2
2 Literature Overview 3
2.1 Two Phase Commit …………………………………………………….. 3
2.2 One Phase Commit …………………………………………………….. 3
2.3 Presumed Abort Two Phase Commit…………………………….. … 4
2.4 Presumed Commit Protocol……………………………………………. 4
2.5 1-2 PC Protocol …………………………………………………………. 4
2.6 Three Phase Commit…………………………………………………… 5
2.7 Nonblocking Two phase commit………………………………………. 5
2.8 Utility in case of handheld……………………………………………… 5
3 Implementation Details 5
3.1 Data Structures…………………………………………………………. 5
3.2 Algorithm -Two Phase Commit………………………………………… 7
3.2.1 Coordinating Site…………………………………………………. 7
3.2.2 Participating Site…………………………………………………. 8
3.3 Algorithm – One Phase Commit……………………………………….. 8
3.3.1 Coordinating Site…………………………………………………. 8
3.3.2 Participating Site…………………………………………………. 9
3.4 Directories and Files……………………………………………………. 9
3.4.1 Source Code Organisation………………………………………. 9
3.4.2 Source Files ………………………………………………………. 9
3.4.3 Functions…………………………………………………………. 10
3.5 Interfaces ……………………………………………………………… 11
3.5.1 Transaction Manager ………………………………………….. 11
3.5.2 LogManager……………………………………………………… 12
3.6 Languages Tools and Libraries ……………………………………… 12
3.6.1 Programming Language ………………………………………. 12
3.6.2 RPC Paradigm…………………………………………………… 12
3.6.3 Multi-Threading…………………………………………………. 12
3.6.4 Mutexes and Locks…………………………………………….. 13
4 Testing and Build 13
4.1 Testcases……………………………………………………………….. 13
4.1.1 Two Phase Commit Protocol – Testcases……………………. 14
4.1.2 One Phase Commit Protocol – Testcases……………………. 14
4.2 Compilation ……………………………………………………………. 15
5 Conclusion and Future Work 15
ABSTRACT
A formal model for atomic commit protocols for a distributed database system is introduced. The model is used to prove existence results about resilient protocols for site failures that do not partition the network and then for partitioned networks. For site failures, a pessimistic recovery technique, called independent recovery, is introduced and the class of failures for which resilient protocols exist is identified. For partitioned networks, two cases are studied: the pessimistic case in which messages are lost, and the optimistic case in which no messages are lost. In all cases, fundamental limitations on the resiliency of protocols are derived.
Index Terms-Commit protocols, crash recovery, distributed database systems, distributed systems, fault tolerance, transaction management.
CHAPTER ONE
- INTRODUCTION
A formal model for transaction processing in a distributed database and then extend it to model several classes of failures and crash recovery techniques. These models are used to study whether or not resilient protocols exist for various failure classes.
Crash recovery in distributed systems has been studied extensively in the literature Many protocols have been designed that are resilient in some environments. All have an “ad hoc” flavor to them in the sense that the class of failures they will survive is not clearly delineated.
The purpose of this project is to formalize the crash recovery problem in a distributed database environment and then give some preliminary results concerning the existence of resilient protocols in various well-defined situations.
Consequently, in the next section we give a brief introduction to transactions in a distributed database.
In Section III we indicate the assumed network environment and our model for transaction processing. In Section IV we extend the model to include the possibility of site failure and give results concerning the existence of resilient protocols in this situation. Section V turns to the possibility of network failure and shows the class of failures for which a resilient protocol exists. Section VI summarizes the results in the previous two sections.
1.2 BACKGROUND OF THE STUDY
A distributed database management system supports a database physically distributed over multiple sites interconnected by a communications network. By definition, a transaction in a distributed database system is a (logically) atomic operation: it must be processed at all sites or at none of them. De-signing protocols resilient to various failures, including arbitrary site failures and partitioning of the communications network, is a very difficult task.
Preserving transaction atomicity in the single-site case is a well-understood problem. The processing of a single transaction is viewed as follows. At some time during its execution, a “commit point” is reached where the site decides to commit or to abort the transaction. A commit is an uncon¬ditional guarantee to execute the transaction to completion, even in the event of multiple failures. Similarly, an abort is an unconditional guarantee to back out the transaction so that none of its effects persist. If a failure occurs before the commit point is reached, then immediately upon recovery the site will abort the transaction. Both commit and abort are irreversible.In the multiple site case, it is the task of a commit protocol to enforce global atomicity. Assuming that each site has a recovery strategy that provides atomicity at the local level, the problem becomes one of ensuring that the sites either unanimously abort or unanimously commit the transaction. A mixed decision results in an inconsistent database. In the absence of failures, a unanimous consensus is easily obtained by a simple protocol. The challenge then is to find protocols ensuring atomicity in the presence of inopportune and perhaps repetitive failures.
A basic assumption within this project is that during the initial phase of distributed transaction processing any participating site can unilaterally abort the transaction. A site may choose to abort for any of the following reasons:
1) One or more sites fail,
2) The network fails,
3) The transaction deadlocks with another transaction,
4) The user aborts the transaction.
Clearly, before any site can commit the transaction, all sites must relinquish their right to unilaterally abort it. Once a site has relinquished that right, it can abort the transaction only in concordance with the other sites.
1.2 PURPOSE OF THE STUDY
To design and implement an optimized commit protocol (1 PC and 2 PC) for transactions in
distributed Database Management Systems which ensure atomicity and durability, in particularfor handheld devices.
1.4 OBJECTIVE OF THE STUDY
- The protocol development involves algorithms for the coordinator and participating processes within Transaction Manager to provide global atomicity.
- It guarantees uniform execution of transaction ensuring that all participating sites commit or all abort even when subject to network failures, coordinating and participating site failures.
- The distributed computer system ensures reliability by providing redundant resources on different nodes. It leads to problems like lack of global state information, the possibility of partial failure and performing parallel operations. Hence, to maintain consistency an atomic transaction model is required.
- In D-DBMS, database may be replicated or fragmented on multiple sites. A single transaction may involve the modifications in the database at multiple sites. For maintaining the consistency, more specifically, guarantying the ACID properties it is necessary for the transaction manager to ensure that the transaction gets successfully completed at all the sites participating in the transaction or on none of them. The Commit Protocol is to be designed to handle all these issues.
- This protocol is intended to be applicable in DBMS for handheld devices, e.g. Simputer. It has to handle the issues common to the mobile environment like frequent disconnections, high communication prices etc.
- Both the protocol 2PC and 1PC, have been designed and implemented
DEFINITIONS OF TERM
Coordinating site: The site that initiates the transaction.
Participating sites: The sites at which the transaction gets executed.
Deferred constraints: The constraints checks that are validated only at the time of the commit.
Voting phase: The phase in which the coordinating site communicate with
CHAPTER TWO
2.0 LITERATURE OVERVIEW
The correctness of a distributed protocol lies in its Atomicity. The main issue to be considered is that, a, distributed transaction is a set of independent transactions executing at different sites (being processed by their respective transaction mangers), but the result of transaction should be a consensus among all. To explain it further, when a distributed transaction finishes execution, in addition the local consistency that a usual transaction manager checks, it has to make sure that either all the sites that executed the same transaction commit or all abort. Thus the transaction is initiated by a coordinator, which ensures the above property. The Participating sites execute the transaction initiated by the coordinator independently on their local copies of Database. and commit/abort as per the final verdict of the coordinator.
In addition to maintain the communication between the two, proper Logs have to be generated which are to be later used by the recovery manager, in case a site failure occurs. Several designs have been suggested for the problem.The most relevant of these with their tradeoffs and advantages
Reviews
There are no reviews yet.