Outline

 Introduction
 Background
 Distributed DBMS Architecture
 Distributed Database Design
 Distributed Query Processing
 Distributed Transaction Management
 Deadlocks
 Building Distributed Database Systems (RAID)
 Mobile Database Systems
 Privacy, Trust, and Authentication
 Peer to Peer Systems

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 1
Useful References
 Textbook Principles of Distributed
Database Systems,
Chapter 11.6
 J. Gray, R. Lorie, G. Putzolu, I. Traiger,
Granularity of Locks and Degrees of
Consistency in a Shared Data Base,
Modelling in Data Base Management
Systems, G.M. Nijssen (ed). North Holland
Publishing Company, 1976.

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 2
Deadlock
 A transaction is deadlocked if it is blocked and will
remain blocked until there is intervention.
 Locking-based CC algorithms may cause deadlocks.
 TO-based algorithms that involve waiting may cause
deadlocks.
 Wait-for graph
 If transaction Ti waits for another transaction Tj to release a
lock on an entity, then Ti  Tj in WFG.

Ti Tj

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 3
Local versus Global WFG
Assume T1 and T2 run at site 1, T3 and T4 run at site 2. Also assume
T3 waits for a lock held by T4 which waits for a lock held by T1 which
waits for a lock held by T2 which, in turn, waits for a lock held by T3.
Local WFG

Site 1 Site 2
T1 T4

T2 T3
Global WFG
T1 T4

T2 T3

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 4
Deadlock Management
 Ignore
 Let the application programmer deal with it, or
restart the system
 Prevention
 Guaranteeing that deadlocks can never occur in
the first place. Check transaction when it is
initiated. Requires no run time support.
 Avoidance
 Detecting potential deadlocks in advance and
taking action to insure that deadlock will not
occur. Requires run time support.
 Detection and Recovery
 Allowing deadlocks to form and then finding and
breaking them. As in the avoidance scheme, this
requires run time support.

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 5
Deadlock Prevention
 All resources which may be needed by a
transaction must be predeclared.
 The system must guarantee that none of the
resources will be needed by an ongoing transaction.
 Resources must only be reserved, but not necessarily
allocated a priori
 Unsuitability of the scheme in database environment
 Suitable for systems that have no provisions for
undoing processes.
 Evaluation:
– Reduced concurrency due to preallocation
– Evaluating whether an allocation is safe leads to
added overhead.
– Difficult to determine (partial order)
+ No transaction rollback or restart is involved.
Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 6
Deadlock Avoidance
 Transactions are not required to request
resources a priori.
 Transactions are allowed to proceed unless
a requested resource is unavailable.
 In case of conflict, transactions may be
allowed to wait for a fixed time interval.
 Order either the data items or the sites and
always request locks in that order.
 More attractive than prevention in a
database environment.

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 7
Deadlock Avoidance –
Wait-Die & Wound-Wait
Algorithms
WAIT-DIE Rule: If Ti requests a lock on a data item
which is already locked by Tj, then Ti is permitted to
wait iff ts(Ti)<ts(Tj). If ts(Ti)>ts(Tj), then Ti is aborted
and restarted with the same timestamp.
 if ts(Ti)<ts(Tj) then Ti waits else Ti dies
 non-preemptive: Ti never preempts Tj
 prefers younger transactions
WOUND-WAIT Rule: If Ti requests a lock on a data
item which is already locked by Tj , then Ti is permitted
to wait iff ts(Ti)>ts(Tj). If ts(Ti)<ts(Tj), then Tj is aborted
and the lock is granted to Ti.
 if ts(Ti)<ts(Tj) then Tj is wounded else Ti waits
 preemptive: Ti preempts Tj if it is younger
 prefers older transactions
Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 8
Deadlock Detection

 Transactions are allowed to wait freely.

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 9
Centralized Deadlock
Detection
 One site is designated as the deadlock detector for
the system. Each scheduler periodically sends its
local WFG to the central site which merges them to
a global WFG to determine cycles.
 How often to transmit?
 Too often  higher communication cost but lower delays
due to undetected deadlocks
 Too late  higher delays due to deadlocks, but lower
communication cost
 Would be a reasonable choice if the concurrency
control algorithm is also centralized.
 Proposed for Distributed INGRES

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 10
Hierarchical Deadlock
Detection
Build a hierarchy of detectors

DDox

DD11 DD14

Site 1 Site 2 Site 3 Site 4

Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 11
Distributed Deadlock Detection
 Sites cooperate in detection of deadlocks.
 One example:
 The local WFGs are formed at each site and passed on to
other sites. Each local WFG is modified as follows:
 Since each site receives the potential deadlock cycles from
other sites, these edges are added to the local WFGs
 The edges in the local WFG which show that local
transactions are waiting for transactions at other sites are
joined with edges in the local WFGs which show that remote
transactions are waiting for local ones.
 Each local deadlock detector:
 looks for a cycle that does not involve the external edge. If it
exists, there is a local deadlock which can be handled
locally.
 looks for a cycle involving the external edge. If it exists, it
indicates a potential global deadlock. Pass on the
information to the next site.
Distributed DBMS © 1998 M. Tamer Özsu & Patrick Valduriez Page 10-12. 12