1

1. INTRODUCTION TO DISTRIBUTED DATABASE SYSTEMS

A distributed database is a collection of multiple, logically interrelated databases distributed over a computer network. Like the central database system, it is necessary to ensure the data in a distributed database should be integrity so that all users who access the database can get the correct data and run their program without any error. Distributed databases have become an important area of information processing, and it is easy to foresee that their importance will rapidly grow. A Distributed database is a collection of data which belong logically to the same system but are spread over the sites of computer network. This definition emphasizes on two equally important aspects of distributed database distribution and logical correlation. Distribution is the fact that data are not resident at the same sit, so that we can distinguish a distributed database from a single centralized database. Logical correlation is the fact that the data have some properties which tie them together, so that we can distinguish a distributed database from a set of local databases or files which are resident at different sites of a computer network. 1.1 Advantages of Distributed Database Systems Since organizations tend to be geographically dispersed, a distributed database fits the organizational structure better than traditional centralized database systems. Each location will have its local data as well as the ability to get needed data from other locations via a communication network. Moreover, the failure of one of the servers at one site wont render the distributed database system inaccessible. The affected site will be the only one directly involved with that failed server. In addition, if any data is required from a site exhibiting a failure, such data may be retrieved from other locations containing the replicated data. The performance of the system will improve, since several machines take care of distributing the load of the CPU and the I/O. Also, the expansion of the distributed system is relatively easy, since adding a new location doesnt affect the existing ones.

2 1.2 Disadvantages of Distributed DBS A distributed system usually exhibits more complexity and cost more than a centralized one. This is true because the hardware and software involved need to maintain a reliable and an efficient system. All the replication and data retrieval from all sites should be transparent to the user. The cost of maintaining the system is considerable since technicians and experts are required at every site. Another main disadvantage of distributed database systems is the issue of security. Handling security across several locations is more complicated. In addition, the communication between sites maybe tapped to.

2. FUNDAMENTALS OF TRANSACTION MANAGEMENT

Transaction Management deals with the problems of keeping the database in a consistent state even when concurrent accesses and failures occur. 2.1 What is a Transaction? A transaction consists of a series of operations performed on a database. The important issue in transaction management is that if a database was in a consistent state prior to the initiation of a transaction, then the database should return to a consistent state after the transaction is completed. This should be done irrespective of the fact that transactions were successfully executed simultaneously or there were failures during the execution, thus, a transaction is a unit of consistency and reliability. The properties of transactions will be discussed later in the properties section. Each transaction has to terminate. The outcome of the termination depends on the success or failure of the transaction. When a transaction starts executing, it may terminate with one of two possibilities: 1. The transaction aborts if a failure occurred during its execution 2. The transaction commits if it was completed successfully.

2.2 Properties of Transactions

3 A Transaction has four properties that lead to the consistency and reliability of a distributed data base. These are Consistency, Isolation, and Durability, Atomicity; this refers to the fact that a transaction is treated as a unit of operation. Consequently, it dictates that either all the actions related to a transaction are completed or none of them is carried out. For example, in the case of a crash, the system should complete the remainder of the transaction, or it will undo all the actions pertaining to this transaction. The recovery of the transaction is split into two types corresponding to the two types of failures: the transaction recovery, which is due to the system terminating one of the transactions because of deadlock handling; and the crash recovery, which is done after a system crash or a hardware failure. Consistency, referring to its correctness, this property deals with maintaining consistent data in a database system. Consistency falls under the subject of concurrency control. For example, dirty data is data that has been modified by a transaction that has not yet committed. Thus, the job of concurrency control is to be able to disallow transactions from reading or updating dirty data. Isolation, according to this property, each transaction should see a consistent database at all times. Consequently, no other transaction can read or modify data that is being modified by another transaction. If this property is not maintained, one of two things could happen to the data base, as shown in Durability. This property ensures that once a transaction commits, its results are permanent and cannot be erased from the database. This means that whatever happens after the COMMIT of a transaction, whether it is a system crash or aborts of other transactions, the results already committed are not modified or undone. 2.3 Goals of Transaction management Goals of transaction management are efficiency, reliability and concurrent execution of transactions. These three goals are strongly interrelated moreover, there is a tradeoff between them, because the effort which is required in order to implement in a reliable way the properties of transactions causes an obvious performance penalty. The main aspects which determine the efficiency of an access

4 plan to a distributed database. CPU and main memory utilization common to both centralized and distributed databases. Although typical database applications are I/O bound, the concurrent execution of many of them in a large system can reveal a bottleneck in main memory or in CPU time. If the operating system has to create a process for each active transaction, most of these processes will be swapped in and out of main memory. Control messages, in a distributed database we have to consider also another aspect of efficiency; the number of control messages which are exchanged between sites. A control message is not used to transfer data but is needed in order to control the execution of the application. Response time is an important efficiency aspect. Obtaining an acceptable response time can be more critical for distributed applications than for local applications, because of the additional time which is required for communication between different sites. Availability is another aspect which must be considered by the transaction manager of a distributed database is the availability of the whole system. The algorithms implemented by the transaction manager must not block the execution of those transactions which do not strictly need to access a site which is not operational. The effort of increasing the systems availability in the presence of site failures is a significant characteristic of the algorithms which are used for transaction recovery and concurrency control in distributed databases. 2.5. DISTRIBUTED TRANSACTIONS A transaction is always part of an application. When a user types an application code, he or she requests the execution of an application, which does not have the properties of atomicity, durability, serializability, and isolation. At some time after its invocation by the user, the application issues a begin_transaction primitive; from this moment, all actions which are performed by the application, until a commit or an abort primitive is issued, are to be considered part of the same transaction. In some systems the beginning of a transaction is implicitly associated with the beginning of the application, and to the commit primitive ends a transaction and automatically begins a

5 new one, so that the explicit begin_transaction primitive is not necessary. However, the model with explicit primitives which is assumed here is more general. In order to perform functions at different sites, a distributed application has to execute several processes at these sites. We will call these processes the agents of the application. An agent is therefore a local process which performs some actions on behalf of an application. In order to cooperate in the execution of the global operation required by the application, the agents have to communicate. As they are resident at different sites, the communication between agents is performed through messages. There are different ways in which the agents can be organized to build a structure of cooperating processes. There exists a root agent which starts the whole transaction so that when the user requests the execution of an application, the root agent is started; the site of the root agent is called the site of orgin of the transaction. The root agent has the responsibility of issuing the begin_transaction, commit and abort primitives. Only the root agent can request the creation of new agent. 2.6 Example of Distributed Transaction Let us consider an example of distributed transaction. The transaction performs a fund transfer operation between two accounts. The application starts relation ACCOUNT (ACCOUNT_NUMBER, AMOUNT). The application starts reading from the terminal the amount which has to be transferred and the account numbers from which the amount must be taken and to which it must be credited. Then the application issues a begin_transaction primitive, and from this time on, the properties of transactions must be preserved by the system. The remaining code of transaction is straight forward in the below given code.

FUND TRANSFER AT GLOBAL LEVEL Begin _transaction; select AMOUNT into $FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC;

6 If $FROM_AMOUNT-$AMOUNT<0 then abort else begin Update ACCOUNT set AMOUNT=AMOUNT-$AMOUNT where ACCOUNT=$FROM_ACC; Update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT=$TO_ACC; Commit; end FUND TRANSFER CONSTITUTED BY TWO AGENTS ROOT- AGENT Read (terminal, $AMOUNT, $FROM_ACC, $TO_ACC); Begin _transaction; Select AMOUNT into $FROM_AMOUNT from ACCOUNT Where ACCOUNT_Number=$FROM_ACC; If $FROM_AMOUNT-$AMOUNT<0 then abort Else begin Update ACCOUNT Set AMOUNT=AMOUNT-$AMOUNT Create AGENT1; SEND TO AGENT1 ($AMOUNT, $TO_ACC); Commit End AGENT1 Receive from ROOT_AGENT ($AMOUNT, $TO_ACC); Update ACCOUNT Set AMOUNT=AMOUNT+$AMOUNT Where ACCOUNT=$TO_ACC; where ACCOUNT=$FROM_ACC;

3. SUPPORTING ATOMICY OF DISTRIBUTED TRANSACTIONS

The global primitives begin_transaction, commit and abort must be implemented by executing a set of appropriate local actions at the sites where the distributed transaction is executed. In order to build a distributed transaction manager which implements the begin_transaction, commit and abort primitives for distributed transaction manager which implements the above primitives for distributed transactions, it is convenient to assume that we have at each local transaction manager which is capable of implementing transactions. 3.1 Failures in Distributed transactions Several types of failures may occur in distributed database systems: Transaction Failures: When a transaction fails, it aborts. Thereby, the database must be restored to the state it was in before the transaction started. Transactions may fail for several reasons. Some failures may be due to deadlock situations or concurrency control algorithms. Site Failures: Site failures are usually due to software or hardware failures. These failures result in the loss of the main memory contents. In distributed database, site failures are of two types:
1. 2.

Total Failure where all the sites of a distributed system fail, Partial Failure where only some of the sites of a distributed system fail.

Media Failures: Such failures refer to the failure of secondary storage devices. The failure itself may be due to head crashes, or controller failure. In these cases, the media failures result in the inaccessibility of part or the entire database stored on such secondary storage. Communication Failures: Communication failures, as the name implies, are failures in the communication system between two or more sites. This will lead to network partitioning where each site, or several sites grouped together, operates independently. As such, messages from one site wont reach the other sites and will therefore be lost. The reliability protocols then utilize a timeout mechanism in order to detect undelivered

8 messages. A message is undelivered if the sender doesnt receive an acknowledgment. The failure of a communication network to deliver messages is known as performance failure. 3.2 Recovery in centralized systems The basic technique for implementing transactions in presence of failures is based on the use of logs. A log contains information for undoing or redoing all actions which are performed by transactions. To undo the actions of a transaction means to reconstruct the database as prior to its execution. To redo the actions of a transaction means to perform its actions again. UNDO (UNDO (UNDO ( (action)))) = UNDO(action) REDO (REDO (REDO ( (action)))) = REDO(action) 3.2.1 Recovery Procedures When a failure with loss of volatile storage occurs a recovery procedure needs the log and performs the following operations
1.

Determine all interconnected transactions that have to be undone. Non committed transactions are recognized because they have to begin_transaction record in the log file, without having a commit or abort record. 2. Determine all transactions which need to be redone. In principle , this set includes all transactions which have a commit record in the log file. 3. Undo the transaction determined at step1, and redo the transactions determined at step 2. Checkpoints are the operations which are periodically performed inorder to simplify the first two steps of the recovery procedure.

2.

3.

4.

4. Two phase commitment protocol

In transaction processing, databases, and computer networking, the twophase commit protocol is a type of an atomic commitment protocol. It is a distributed algorithm that coordinates all the processes that participate in a distributed atomic transaction on whether to commit or abort the transaction. The protocol achieves its

9 goal even in many cases of system failure involving process, network node, communication, etc. failures, and is thus widely utilized. However, it is not resilient to all possible failure configurations, and in rare cases user intervention is needed to remedy outcome. The two phases of the algorithm are the commit-request phase, in which a coordinator process attempts to prepare all the transaction's participating processes named participants, cohorts, or workers to take the necessary steps for either committing or aborting the transaction, and the commit phase, in which, based on voting either "Yes," commit, or "No," abort of the cohorts, the coordinator decides whether to commit only if all vote "Yes" or abort the transaction otherwise, and notifies the result to the cohorts. The cohorts then follow with the needed actions commit or abort with their transactional resources and their respective portions in the transaction's output if applicable. 4.1 Assumptions The protocol works in the following manner: one node is designated the coordinator, which is the master site, and the rest of the nodes in the network are designated the cohorts. The protocol assumes that there is stable storage at each node with a write-ahead log, that no node crashes forever, that the data in the write-ahead log is never lost or corrupted in a crash, and that any two nodes can communicate with each other. The last assumption is not too restrictive, as network communication can typically be rerouted. The first two assumptions are much stronger; if a node is totally destroyed then data can be lost. The protocol is initiated by the coordinator after the last step of the transaction has been reached. The cohorts then respond with an agreement message or an abort message depending on whether the transaction has been processed successfully at the cohort. 4.2 Basic algorithm

Commit request phase or voting phase, commit phase or Completion phase are the phases, explaining in detail phase 1 1. The coordinator sends a query to commit message to all cohorts and waits until it has received a reply from all cohorts.

10 2. The cohorts execute the transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their redo log. 3. Each cohort replies with an agreement message (cohort votes Yes to commit), if the transaction succeeded, or an abort message (cohort votes No, not to commit), if the transaction failed. If the coordinator received an agreement message from all cohorts during the commitrequest phase: 1. The coordinator sends a commit message to all the cohorts. 2. Each cohort completes the operation, and releases all the locks and resources held during the transaction. 3. Each cohort sends an acknowledgment to the coordinator. 4. The coordinator completes the transaction when acknowledgments have been received. If any cohort sent an abort message during the commit-request phase: 1. The coordinator sends a rollback message to all the cohorts. 2. Each cohort undoes the transaction using the undo log, and releases the resources and locks held during the transaction. 3. Each cohort sends an acknowledgement to the coordinator. 4. The coordinator undoes the transaction when all acknowledgements have been received. For the purpose of building distributed transaction manager we require local transaction manager has the capabilities of ensuring atomicity of a sub transaction and writing some records on stable storage on behalf of the distributed transaction manager.

11

Messages AGENT ROOT Trans AGENT

Messages AGENT

Distributed Transaction

2 DTMAGENT DTM AGENT DTM AGENT

Messages

Messages

DTM

1 LTM at site 1 LTM at site j LTM at site k LTM

12

Messages AGENT ROOT Trans AGENT

Messages AGENT

Distributed Transaction

2 DTMAGENT DTM AGENT DTM AGENT

Messages

Messages

DTM

1 LTM at site 1 LTM at site j LTM at site k LTM

Fig: A reference model of distributed transaction recovery Interface 1: Local_Begin, Local_commit, Local_abort, Local_create

13 Interface 2: Begin_transaction, Commit, Abort, Create

4.3

Two phase commitment protocol

coordinator Write prepare record in the log Send PREPARE message and activate timeout participant Wait for PREPARE message; If the participant is willing to commit then begin write subtransactions records in the log; write ready record in the log; send READY answer message to coordinator end else begin write abort record in the log; send ABORT answer message to cordinator end Coordinator Wait for ANSWER message from all participants or timeout; If timeout expired or some answer message is ABORT then begin write global-abort record in the log Send ABORT command message to all participants end else begin write global-commit record in the log Send COMMIT command message to all participants end

14

Participant wait for command message; write abort or commit record in the log; Send the ACK message to the coordinator Execute command Coordinator Wait for ACK messages from all participants; Write complete record in the log
4.4

Failures analysis The two phase commitment protocol is resilient to all failures in which

no log information is lost. The behavior of the protocol in the presence of different kinds of failures is now analyzed

A participant fails before having written the ready record in the log. In this case timeout expires and it takes abort decision. A participant fails after having written the ready record in the log. In this cases participant asks the coordinator or other participants to know the outcome of the transaction, and then perform appropriate action. The coordinator fails after having written the prepare record in the log, but before having written a global_commit or global_abort. In this case all the participants which have answered ready have to wait for the recovery of the coordinator The coordinator fails after having written a global_commit or global_abort record in the log. In this case coordinator sends the decision once again. The coordinator fails after having written the complete record in the log. In this case no action is required.

15

5. Distributed Concurrency control

Distributed concurrency control is the concurrency control of a system distributed over a computer network. In database systems and transaction processing distributed concurrency control refers primarily to the concurrency control of a distributed database. It also refers to the concurrency control in a multidatabase and other multi-transactional object environment e.g., federated database, Grid computing, and Cloud computing environments; see also global concurrency control. A major goal for distributed concurrency control is distributed serializability or global serializability for multidatabase systems. Distributed concurrency control poses special challenges beyond centralized one, primarily due to communication and computer latency. It often requires special techniques, like distributed lock manager over fast computer networks with low latency, like switched fabric e.g., Infinite Band. Commitment ordering or Commit ordering; CO is a general serializability technique that allows to achieve distributed serializability and global serializability in particular effectively on large scale, without performance penalties that are typical to other serializability techniques. The most common distributed concurrency control technique is strong strict two-phase locking SS2PL, also named rigorousness, which is also a common centralized concurrency control technique. SS2PL provides the serializability, strictness, and commitment ordering properties. Strictness, a special case of recoverability, is utilized for effective recovery from failure, and commitment ordering allows participating in a general solution for global serializability. For large-scale distribution and complex transactions, distributed locking's typical heavy performance penalty due to delays, latency can be saved by using the atomic commitment protocol, which is needed in a distributed database for distributed transactions' atomicity (e.g., 2PC, or a simpler one in a reliable system, together with some local commitment ordering variant e.g., local SS2PL instead of distributed locking, to achieve global serializability in the entire system.

5.2 Basic Locking

16 A lock is an object associated with a shared resource such as a data item of an elementary type, a row in a database, or a page of memory. In a database, a lock on a database object a data-access lock may need to be acquired by a transaction before accessing the object. Correct use of locks prevents undesired, incorrect or inconsistent operations on shared resources by other concurrent transactions. When a database object with an existing lock acquired by one transaction needs to be accessed by another transaction, the existing lock for the object and the type of the intended access is checked by the system.

Messages AGENT ROOT Trans AGENT

Messages AGENT

Distributed Transaction

2 DTMAGENT DTM AGENT DTM AGENT

Messages

Messages

DTM

1 LTM at site 1 LTM at site j LTM at site k LTM

17

Messages AGENT ROOT Trans AGENT

Messages AGENT

Distributed Transaction

2 DTMAGENT DTM AGENT DTM AGENT

Messages

Messages

DTM

1 LTM at site 1 LTM at site j LTM at site k LTM

18

Fig: A reference model for distribute concurrency control Interface1: Local_lock_shared, Local_lock_exclusive, Local_unlock Interface 2: Lock_shared, Lock_exclsive, Lock_unlock If the existing lock type does not allow this specific attempted concurrent access type, the transaction attempting access is blocked according to a predefined agreement/scheme. In practice a lock on an object does not directly block a transaction' operation upon the object, but rather blocks that transaction from acquiring another lock on the same object, needed to be held/owned by the transaction before performing this operation. Thus, with a locking mechanism, needed operation blocking is controlled by a proper lock blocking scheme, which indicates which lock type blocks which lock type. Two major types of locks are utilized: Write-lock (exclusive lock) is associated with a database object by a transaction (the transaction locks it; acquires lock for it) before writing (inserting/modifying/deleting) this object. Read-lock (shared lock) is associated with a database object by a transaction before reading (retrieving the state of) this object. The common interactions between these lock types are defined by blocking behavior as follows: An existing write-lock on a database object blocks an intended write upon the same object (already requested/issued) by another transaction by blocking a respective write-lock from being acquired by the other transaction. The second write-lock will be acquired and the requested write of the object will take place (materialize) after the existing write-lock is released. A write-lock blocks an intended (already requested/issued) read by another transaction by blocking the respective read-lock .

19 A read-lock blocks an intended write by another transaction by blocking the respective write-lock . A read-lock does not block an intended read by another transaction. The respective read-lock for the intended read is acquired (shared with the previous read) immediately after the intended read is requested, and then the intended read itself takes place. Several variations and refinements of these major lock types exist, with respective variations of blocking behavior. If a first lock blocks another lock the two locks are incompatible; otherwise the locks are compatible. Often lock types blocking interactions are presented in the technical literature by a Lock compatibility table. 5.3 Two Phase Locking A transaction locks a data item in shared mode if it wants only to read the data item and in exclusive mode if it wants to write the data item. Compatibility rules A transaction can lock a data item in shared mode if it is not locked at all or it is locked in shared mode by another transaction. A transaction can lock a data item in exclusive mode only if it is not locked at all. Concurrent execution of transactions is correct provided that the following rules are observed: Transactions are well formed Compatibility rules for locking are observed Each transaction does not request new locks after it has released a lock

According to the two-phase locking protocol, a transaction handles its locks in two distinct, consecutive phases during the transaction's execution:

20 1. Expanding phase or Growing phase: locks are acquired and no locks are released. 2. Shrinking phase: locks are released and no locks are acquired. The serializability property is guaranteed for a schedule with transactions that obey the protocol. The 2PL schedule class is defined as the class of all the schedules comprising transactions with data access orders that could be generated by the 2PL protocol. Typically, without explicit knowledge in a transaction on end of phase-1, it is safely determined only when a transaction has entered its ready state in all its processes. In this case phase-2 can end immediately (no additional processing is needed), and actually no phase-2 is needed. Also, if several processes are involved, then a synchronization point among them is needed to determine end of phase-1 for all of them i.e., in the entire distributed transaction, to start releasing locks in phase-2. Such synchronization point is usually too costly, and end of phase-1 is usually postponed to be merged with transaction end, and again phase-2 is not needed. 5.4 Analysis Write locks all, read locks one. In this scheme exclusive locks are acquired on all copies, while shared locks are acquired only on one arbitrary copy. Majority locking. Both shared and exclusive locks are requested at a majority of the copies of the data item, in this way if two transactions are required to lock the same item, there is at least one copy of it where the conflict is discovered.

6. Extreme Transaction Processing

Extreme Transaction Processing is an exceptionally demanding form of transaction processing. Transactions of 10,000 concurrent accesses 500 transaction per second or more would require this form of processing. XTP applications are designed, developed, deployed, managed, and maintained on computer clusters and/or distributed grid computing networks. As a result, XTP applications feature vast improvements in: performance scalability availability

21 security manageability dependability These applications generate orders of magnitude more transactions than those created by traditional transaction processing systems because of their wider often multienterprise, national and global reach.

7. Conclusion
Distributed transaction manager must ensure that all transactions have the atomicity, durability, seriability and isolation properties. In most systems this is obtained by implementing on top of existing local transaction managers the two phase commitment for reliability and two phase locking for concurrency control and time out for deadlock detection. The two phase commitment protocol ensures that the sub transactions of the same transaction will either all commit or all abort, in spite of the possible failures; the two phase commitment is resilient to any failure in which no log information is lost. The two phase locking mechanism requires that all sub transactions acquires locks in the growing phase and release locks in the shrinking phase. Timeouts mechanisms for deadlock detection simply abort those transactions which are in wait, possibly for a deadlock. 8. REFERENCES 1. Connolly, Thomas; Begg, Carolyn; and Strachan, Anne , Database Systems 2. Mohan, C.; Lindsay, B.; and Obermarck, A Practical Approach to Design, Implementation and Management , Addison-Wesley. 3. G. Wiederhold, Transaction Management in the R* Distributed Database Management System. ACM Transactions on Database Systems, Vol. 11, No. 4 McGraw Hill. 4. Oracle8 Server Distributed Database Systems, Oracle, 3-1 3-35 5. Ozsu, Tamer M., and Valduriez, Patrick, Principles of Distributed Database Systems, Prentice Hall.

22 6. C J date, An introduction to database systems, 3rd edition Addison Wesley,