The document introduces distributed transaction systems, explaining their architecture, including transaction managers and coordinators, and emphasizes the importance of atomicity through commit protocols like two-phase and three-phase commits. It discusses failure handling, including site and coordinator failures, and how to ensure transaction consistency using logs for recovery. Additionally, it covers concurrency control methods in distributed databases, detailing locking protocols and replication strategies to manage data access and consistency across multiple sites.

1. K.Balamurugan
M.Tech-CSE-1st year
ADMS Presentation
Pondicherry university
Distributed Database System
- Distributed Transaction

2. Content:
 Introduction to Distributed transaction
 Distributed Transaction Model
 Commit Protocols
 Handling Failures
 Concurrency control and Recovery in distributed
Environments

3. Once again what is distributed
database?
 A distributed database system consists of
loosely coupled sites that share no physical
component
 Database systems that run on each site are
independent of each other
 Transactions may access data at one or more sites
 Each site has a 1.Transaction Manager
2. transaction coordinator
 transaction coordinator -Starting the execution of
transactions that originate at the site.
 Transaction Manager-Participating in coordinating
the concurrent execution of the transactions
executing at that site.

4. Transaction System
 Access to the various data items in a distributed
system is usually accomplished through
transactions, which must preserve the ACID
properties
 The local transactions are those that access
and update data in only one local database
 The global transactions are those that access
and update data in several local databases.

5. Distributed Transaction System
Architecture

6. Abstract model of a transaction
system
 Each site has its own local transaction manager,
whose function is to ensure the ACID properties of
those transactions that execute at that site
 The transaction manager manages the execution of
those transactions (or sub-transactions) that access
data stored in a local site. Note that each such
transaction may be either a local transaction (that is, a
transaction that executes at (only that site) or part of a
global transaction
 The transaction coordinator coordinates the
execution of the various transactions (both local and
global) initiated at that site.

7. Abstract model of a transaction
system
 Each transaction manager is responsible for
Maintaining a log for recovery purposes
 the coordinator is responsible for
• Starting the execution of the transaction
• Breaking the transaction into a number of sub
transactions and distributing these sub
transactions to the appropriate sites for execution
• Coordinating the termination of the transaction,
which may result in the transaction being
committed at all sites or aborted at all sites

8. System Failure Modes
 A distributed system may suffer from the same
types of failure that a centralized system does (for
example, software errors, hardware errors, or disk
crashes)
 distributed environment have following unique
failures. They are :
• Failure of a site
• Loss of messages
• Failure of a communication link
• Network partition

9. Commit Protocols
 To ensure atomicity property, the transaction
coordinator of T must execute a commit protocol.
 There are 2 types of commit protocols:
 two-phase commit protocol (2PC)
three-phase commit protocol (3PC)

10. Two-Phase Commit protocol
 Normal operation, then describe how it handles
failures and finally how it carries out recovery and
concurrency control.
 Let T be a transaction initiated at site Si, and let the
transaction coordinator at Si be Ci
 Phase 1: Obtaining a Decision
 Coordinator asks all participants to prepare to commit
transaction Ti .
 Ci adds the records <prepare T > to the log and forces log to
stable storage
 sends prepare T messages to all sites at which T executed
 Upon receiving message, transaction manager at site
determines if it can commit the transaction
 if not, add a record <no T > to the log and send abort T
message to Ci
 if the transaction can be committed, then:
 add the record <ready T > to the log
 force all records for T to stable storage

11. Phase 2: Recording the Decision
 T can be committed of Ci received a ready T
message from all the participating sites: otherwise
T must be aborted.
 Coordinator adds a decision record, <commit T >
or <abort T >, to the log and forces record onto
stable storage. Once the record stable storage it is
irrevocable (even if failures occur)
 Coordinator sends a message to each participant
informing it of the decision (commit or abort)
 Participants take appropriate action locally.

12. Handling of Failures - Site Failure
When site Si recovers, it examines its log to determine the fate of
transactions active at the time of the failure.
 Log contain <commit T> record: site executes redo (T)
 Log contains <abort T> record: site executes undo (T)
 Log contains <ready T> record: site must consult Ci to determine the
fate of T.
 If T committed, redo (T)
 If T aborted, undo (T)
 The log contains no control records concerning T
 implies that Sk failed before responding to the prepare T message
from Ci
 Sk must execute undo (T)

13. Handling of Failures- Coordinator
Failure
 If coordinator fails while the commit protocol for T is executing then
participating sites must decide on T ’s fate:
• If an active site contains a <commit T > record in its log, then T must
be committed.
• If an active site contains an <abort T > record in its log, then T must
be aborted.
• If some active participating site does not contain a <ready T > record
in its log, then the failed coordinator Ci cannot have decided to
commit T .
• Can therefore abort T .
• If none of the above cases holds, then all active sites must have a
<ready T > record in their logs, but no additional control records (such
as <abort T > of <commit T >).
• In this case active sites must wait for Ci to recover, to find
decision.
 Blocking problem : active sites may have to wait for failed
coordinator to recover.

14. Recovery and Concurrency
Control
 In-doubt transactions have a <ready T>, but
neither a <commit T>, nor an <abort T> log record.
 The recovering site must determine the commit-
abort status of such transactions by contacting
other sites; this can slow and potentially block
recovery.
 Recovery algorithms can note lock information in
the log.
 Instead of <ready T>, write out <ready T, L> L = list of
locks held by T when the log is written (read locks can be
omitted).
 For every in-doubt transaction T, all the locks noted in the
<ready T, L> log record are reacquired.
 After lock reacquisition, transaction processing can
resume; the commit or rollback of in-doubt
transactions is performed concurrently with the

15. Three-Phase Commit
 The three-phase commit (3PC) protocol is an
extension of the two-phase commit protocol that
avoids the blocking problem.
 protocol avoids blocking by introducing an extra third
phase where multiple sites are involved in the
decision to commit.
 coordinator first ensures that at least k other sites
know that it intended to commit the transaction. If the
coordinator fails, the remaining sites first select a new
coordinator.
 The new coordinator restarts the third phase of the
protocol if some site knew that the old coordinator
intended to commit the transaction. Otherwise the
new coordinator aborts the transaction.

16. Concurrency Control in Distributed
Databases
 commit protocol to ensure global transaction
atomicity.
 The protocols we describe in this section require
updates to be done on all replicas of a data item.
If any site containing a replica of a data item has
failed, updates to the data item cannot be
processed.
 In this we describe protocols that can continue
transaction processing even if some sites or links
have failed, thereby providing high availability

17. Locking Protocols
 The various locking protocols can be used in a
distributed environment. The only change that
needs to be incorporated is in the way the lock
manager deals with replicated data. We present 2
possible schemes:
1. Single Lock-Manager Approach
2. Distributed Lock Manager

18. Single-Lock-Manager Approach
 System maintains a single lock manager that
resides in a single chosen site, say Si
 When a transaction needs to lock a data item, it
sends a lock request to Si and lock manager
determines whether the lock can be granted
immediately
 If yes, lock manager sends a message to the site which
initiated the request
 If no, request is delayed until it can be granted, at which
time a message is sent to the initiating site

19. Single-Lock-Manager
Approach
 The transaction can read the data item from any
one of the sites at which a replica of the data item
resides.
 Writes must be performed on all replicas of a data
item
 Advantages of scheme:
 Simple implementation
 Simple deadlock handling
 Disadvantages of scheme are:
 Bottleneck: lock manager site becomes a bottleneck
 Vulnerability: system is vulnerable to lock manager site
failure.

20. Distributed Lock Manager
 Distributed lock-manager approach, in which the lock-
manager function is distributed over several sites.
 When a transaction wishes to lock data item Q, which
is not replicated and resides at site Si,a message is
sent to the lock manager at site Si requesting a
lock(in a particular lock mode). If data item Q is
locked in an incompatible mode, then the request is
delayed until it can be granted.
 Once it has determined that the lock request can be
granted,the lock manager sends a message back to
the initiator indicating that it has granted the lock
request.
 Advantage: work is distributed and
 Disadvantage: deadlock detection is more complicated

21. Distributed Lock Manager
 There are several alternative ways of dealing with replication of
data items:
 Primary copy
 Majority protocol
 Biased protocol
 Primary Copy:
 Choose one replica of data item to be the primary copy.
 Site containing the replica is called the primary site for that data item
 Different data items can have different primary sites
 When a transaction needs to lock a data item Q, it requests a
lock at the primary site of Q.
 Implicitly gets lock on all replicas of the data item
 Benefit
 Concurrency control for replicated data handled similarly to replicated data
- simple implementation.
 Drawback
 If the primary site of Q fails, Q is inaccessible even though other

22. Majority Protocol
 In case of replicated data
 If Q is replicated at n sites, then a lock request message
must be sent to more than half of the n sites in which Q is
stored.
 The transaction does not operate on Q until it has obtained
a lock on a majority of the replicas of Q.
 When writing the data item, transaction performs writes on
all replicas.
 Benefit
 Can be used even when some sites are unavailable
 Drawback
 Requires 2(n/2 + 1) messages for handling lock requests,
and (n/2 + 1) messages for handling unlock requests.

23. Biased Protocol
 Local lock manager at each site as in majority
protocol, however, requests for shared locks are
handled differently than requests for exclusive
locks.
 Shared locks. When a transaction needs to lock
data item Q, it simply requests a lock on Q from the
lock manager at one site containing a replica of Q.
 Exclusive locks. When transaction needs to lock
data item Q, it requests a lock on Q from the lock
manager at all sites containing a replica of Q.
 Advantage - imposes less overhead on read
operations.
 Disadvantage - additional overhead on writes

24. Timestamp
 Timestamp based concurrency-control protocols
can be used in distributed systems
 Each transaction must be given a unique
timestamp
 Main problem: how to generate a timestamp in a
distributed fashion
 Each site generates a unique local timestamp
using either a logical counter or the local clock.
 Global unique timestamp is obtained by
concatenating the unique local timestamp with
the unique identifier.

25. Timestamp

26. Timestamp
 A site with a slow clock will assign smaller
timestamps
 Still logically correct: serializability not affected
 But: “disadvantages” transactions
 To fix this problem
 Define within each site Si a logical clock (LCi ), which
generates the unique local timestamp
 Require that Si advance its logical clock whenever a
request is received from a transaction Ti with timestamp <
x,y > and x is greater that the current value of LCi.
 In this case, site Si advances its logical clock to the value x
+ 1.