DISTRIBUTED COMMITMENT AND RECOVERY: TWO PHASE COMMIT

651

DISTRIBUTED COMMITMENT AND RECOVERY: TWO PHASE COMMIT
 

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

 

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 particular for handhold devices.

 

DOWNLOAD COMPLETE PROJECT MATERIAL 

DISTRIBUTED COMMITMENT AND RECOVERY: TWO PHASE COMMIT

Leave a Reply