Transcript Outline           Distributed DBMS Introduction Background Distributed DBMS Architecture Distributed Database Design Distributed Query Processing Distributed Transaction Management  Transaction Concepts and Models  Distributed Concurrency Control  Distributed Reliability Building Distributed.

Outline










Distributed DBMS
Introduction
Background
Distributed DBMS Architecture
Distributed Database Design
Distributed Query Processing
Distributed Transaction Management
 Transaction Concepts and Models
 Distributed Concurrency Control
 Distributed Reliability
Building Distributed Database Systems (RAID)
Mobile Database Systems
Privacy, Trust, and Authentication
Peer to Peer Systems
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 1
2PC Recovery Protocols –Additional
Cases (see book)
Arise due to non-atomicity of log and message send
actions
 Coordinator site fails after writing “begin_commit”
log and before sending “prepare” command
 treat it as a failure in WAIT state; send “prepare”
command

Participant site fails after writing “ready” record in
log but before “vote-commit” is sent
 treat it as failure in READY state
 alternatively, can send “vote-commit” upon recovery

Participant site fails after writing “abort” record in
log but before “vote-abort” is sent
 no need to do anything upon recovery
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 2
2PC Recovery Protocols –Additional
Case (see book)

Coordinator site fails after logging its final
decision record but before sending its decision to
the participants
 coordinator treats it as a failure in COMMIT or
ABORT state
 participants treat it as timeout in the READY state

Participant site fails after writing “abort” or
“commit” record in log but before
acknowledgement is sent
 participant treats it as failure in COMMIT or ABORT
state
 coordinator will handle it by timeout in COMMIT or
ABORT state
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 3
Problem With 2PC

Blocking
 Ready implies that the participant waits for the
coordinator
 If coordinator fails, site is blocked until recovery
 Blocking reduces availability


Independent recovery is not possible
However, it is known that:
 Independent recovery protocols exist only for single
site failures; no independent recovery protocol exists
which is resilient to multiple-site failures.

So we search for these protocols – 3PC
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 4
Three-Phase Commit


3PC is non-blocking.
A commit protocols is non-blocking iff
 it is synchronous within one state
transition, and
 its state transition diagram contains
no state which is “adjacent” to both a commit
and an abort state, and
 no non-committable state which is “adjacent”
to a commit state



Adjacent: possible to go from one stat to
another with a single state transition
Committable: all sites have voted to
commit a transaction
 e.g.: COMMIT state
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 5
State Transitions in 3PC
Coordinator
INITIAL
INITIAL
Commit command
Prepare
Prepare
Vote-commit
Prepare
Vote-abort
WAIT
Vote-abort
Global-abort
ABORT
READY
Vote-commit
Prepare-to-commit
PRECOMMIT
Ready-to-commit
Global commit
Global-abort
Ack
ABORT
Prepared-to-commit
Ready-to-commit
PRECOMMIT
Global commit
Ack
COMMIT
Distributed DBMS
Participants
© 1998 M. Tamer Özsu & Patrick Valduriez
COMMIT
Page 10-12. 6
Communication Structure (see
book)
P
P
P
P
P
P
C
C
C
P
P
P
P
P
P
ready?
yes/no
Phase 1
Distributed DBMS
C
pre-commit/
pre-abort?
yes/no
Phase 2
© 1998 M. Tamer Özsu & Patrick Valduriez
commit/abort
ack
Phase 3
Page 10-12. 7
Formalism for Commit
Protocols
< Q, I, 0, , V, A, C >
Q:
Finite set of states
Messages addressed to the site
Σ I:
Messages sent by the site
Σ0:
) (Q,)
(
,

Q
δ:
I
0
V i Q: Initial state
A  Q: Abort states
C  Q: Commit states
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 8
Formalism for Commit
Protocols
Properties:
1. AC  
2. V  A and
i
V i C
Protocols are non-deterministic:
• Sites make local decisions.
• Messages can arrive in any order.
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 9
Global State Definition




Global state vector containing the states of
the local protocols.
Outstanding messages in the network
A global state transition occurs whenever a
local state transition occurs at a participating
site.
Exactly one global transition occurs for each
local transition.
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 10
Global Sate Graph
q1 q2
xact req
Global state is inconsistent if its
state vector contains both a
commit and abort state.
w1 q2
start xact
w1 w2
yes
a1 w2
abort
a1
a2
Distributed DBMS
w1 a2
no
c1 w2
commit
c1
a1
a2
c2
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 11
Two states are potentially concurrent if there exists a reachable
global state that contains both local states.
Concurrency set of s is set of all local states that are potentially
concurrent with it. C(s)
C(w1) = {q2, a2 , w2}
The sender set for s,
S(s) = {t/t sends message m & m  M}
where M be the set of messages that are received by s.
t is a local state.
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 12
States of Various States in the
Commit Protocol

Global state inconsistent if it contains both
 local commit state
 local abort state

Final state if
 All local states are final

Terminal state if:
 there exists an immediately reachable successor
state
  deadlock

Committable state (local) if:
 all sites have voted yes on committing the
transaction

Otherwise, non-committable
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 13
An Example when Only a Single
Site Remains Operational


This site can safely abort the transaction if and only if the
concurrency set for its local state does not contain a commit
state
This site can safely commit only if
 Its local state must be “committable”
 And the concurrency set for its state must not contain an abort
state.

A blocking situation arises when
 The concurrency set for the local state contains both a commit and
an abort state
 Or the site is in a “noncommittable” state and the concurrency set
for that state contains a commit state



The site can not commit because it can not infer that all sites have
voted yes on committing
It can not abort because another site may have committed the
transaction before crashing.
There observations
imply the simple but power result in thePage 10-12. 14
© 1998 M. Tamer Özsu & Patrick Valduriez
Distributed DBMS
Fundamental Non-blocking
Theorem


Definition: protocol is synchronous within one state transition
if one site never leads another site by more than one state
transition.
Theorem Fundamental non-blocking: A protocol is nonblocking iff
 There exists no local state s
C(s) = A (abort) and C (commit)
 And there exists no non-committable state s
C(s) = C (commit)

Lemma: A protocol that is synchronous within one state
transition is non-blocking iff:
 No local state is adjacent to both a commit & an abort state
 No non-committable state is adjacent to a commit state
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 15
Three-Phase Commit
Protocol
Site I
(co-ordinator)
Site i (i = 2,3,…n)
(slave)
q1
request
xact2…xact4
no2| … |non
abort2 … abortn
a1
w1
yes2 … yesn
prepare2 … preparen
qi
xacti
…i
yes
aborti
wi
ai
preparei
acki
p1
ack2 … ackn
commit2 … commitn
xacti
noi
pi
commiti
c1
ci
Distributed DBMS
© 1998 M. Tamer Özsu & Patrick Valduriez
Page 10-12. 16