Committed:
Effects are installed to the
database.
Aborted:
Does not execute to completion
and any partial effects on database
are erased.
Consistent
state:
Derived state from serial execution.
Inconsistency caused by:
1. Concurrently executing transaction.
2. Failures causing partial or incorrect execution
of a transaction.
Commit protocols:
Protocols for directing the successful execution
of a simple transaction.
Termination protocols:
Protocols at operational site to commit/abort
an unfinished transaction after a failure.
Distributed Crash Recovery:
• Centralized Protocols
• Hierarchical Protocols
• Linear Protocols
• Decentralized Protocols
Phase:
Consists of a message round where all
Sites exchange messages.
Two Phase Commit Protocol:
ARGUS, LOCUS, INGRES
Four Phase Commit Protocol:
SSD-1
Quorum:
Minimum number of sites needed to
proceed with an action
Commit/Termination Protocols
Two Phase Commit
Three Phase Commit
Four Phase Commit
Linear, Centralized, Hierarchical, Decentralized
Protocols
Two Phase Commit:
Site 1
1.
Site 2
Trans. arrives.
Message to ask for vote
is sent to other site(s)
Message is recorded.
Site votes Y or N (abort)
Vote is sent to site 1
2.
The vote is received.
If vote = Y on both sites,
then Commit
else Abort
Either Commit or Abort
based on the decision of
site 1
Byzantine General Problem:
Two generals are situated on adjacent hills and
enemy is in the valley in between.
Enemy can defeat either general, but not both.
To succeed, both generals must agree to either
attack or retreat.
The generals can communicate via
messengers who are subject to capture or
getting lost.
The general may themselves be traitors or
send inconsistent information.
Byzantine Agreement:
Problem of a set of processors to agree on a
common value for an object. Processors may
fail arbitrarily, die and revive randomly, send
messages when they are not supposed to etc.
Site 1
(co-ordinator)
Site 2
(slave)
q1
q2
w1
no
w2
yes
commit
yes
abort
c1
a1
start xact
no
start xact
yes
xact request
start xact
abort
a2
commit
c2
Figure. The local protocols for the two-phase commit protocol.
qi
xact
yesi1 … yesin
xact
noi1 … noin
no1i| … |noni
ai
wi
yes1i| … |yesni
send
receive
ci
Site i (i = 1,2,…n)
Figure. The decentralized two-phase commit protocol.
Site 1
(co-ordinator)
Site 2
(back-up)
q1
q2
xact2
act2
request
xact2
W1’
act2
xact3xact4
abort2
act2
w2
commit2
act2
c2
a2
yes3yes4
commit2
c1’
ack2
commit3commit4
C1
w1
no3|no4
abort2
a1’
ack2
abort3abort4
a1
Site i (i = 3,4)
(slave)
qi
xacti
…i
yes
aborti
wi
commiti
ci
Figure. The SDD-1 four-phase commit protocol.
xacti
noi
ai
Protocol:
< 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
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.
Global State
1.
2.
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.
Global state graph
q1 q2
xact req
w1 q2
start xact
w1 w2
yes
a1 w2
abort
a1
a2
w1 a2
no
c1 w2
commit
c1
a1
a2
c2
Global state is inconsistent if its state
vector contains both a commit & abort
state.
Two states are potentially concurrent if:
 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) = {V2, 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.
Global state
Inconsistent if it contains both
• local commit state
• local abort state
Final state if:
• all local states are final
Terminal state if:
 an immediately reachable
successor state
 deadlock
Committable state (local) if:
 all sites have voted yes on
committing the transaction
otherwise, non-committable
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 non-blocking iff:
1.  no local state s
C(s) = A (abort) and C (commit)
2.  no non-committable state s
C(s) = C (commit)
Lemma: A protocol that is synchronous
within one state transition is non-blocking
iff:
1. No local state adjacent to both a
commit & an abort state.
2. No non-committable state adjacent
to a commit state.
(initial state)
q1 q2
xact req
w1 q2
start xact
w1 w2
yes
a1 w2
abort
a1
a2
w1 a2
no
c1 w2
commit
p1
c2
c1
c2
a1
a2
Figure. The reachable global state graph for the protocol of
Figure 4.1.
Site 1
(co-ordinator)
Site 2
(slave)
q1
q2
request
xact
no
w1
yes
commit
p2
xact
no
abort/-
a2
commit
ack
yes
abort
a1
xact
yes
p1
c2
c1
failure
time out
Figure. The protocol with failure and timeout transitions obeying
rules 1 & 2.
Theorem: There exists no protocol using
independent recovery that is resilient to
arbitrary failures by two sites.
Same state
exists
for other sites
First global
state
G0  abort
|
G1
|
Gk-1  site j recovers to abort
(only j makes a transition)
other sites recover to abort
Gk  site j recovers to commit
|
Gm  commit
Failure of j  recover to commit
Failure of any other site  recover to abort
Theorem:
There exists no protocol resilient to a
network partitioning when messages are
lost.
Rule 3:
Rule 4:
Isomorphic to
Rule 1:
Rule 2:
undelivered message ↔ timeout
timeout ↔ failure
Theorem:
Rules 3 & 4 are necessary and sufficient
for making protocols resilient to a
partition in a two-site protocol.
Theorem:
There exists no protocol resilient to a
multiple partition.
Simple Termination Protocol
Message sent by an operational site
abort – If trans. state is abort
(If in abort)
committable – If trans. state is committable
(If in p or c)
non-committable – If trans. state is neither
committable nor abort
(If in initial or wait)
 If at least one committable message is
received, then commit the transaction,
else abort it.
Not robust
Site 1 (committable)  site 2
No message
Site 3 (non-committable)  site 2
Site 2 fails
Conclusion
Site 3 confused
Issue 1
OPn. site fails immediately
after making a commit decision
Issue 2
Site does not know the current
operational status (i.e., up or
down) of other sites.
Site 1
Crash
Site 2
Site 3
Commuts
Site 3 does not
know if site 1
was up at
beginning. Does
not know it got
inconsistent
messages
Resilient protocols require at least two rounds
unless no site fails during the execution of the
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
preparei
acki
p1
ack2 … ackn
commit2 … commitn
pi
commiti
c1
ci
Figure. The central site three-phase commit protocol.
xacti
noi
ai
MESSAGES RECEIVED
SITE 1
SITE 2
SITE 3
SITE 4
SITE5
initial
state
Commitable
non
non
non
non
Round 1
(1)
CNNNN
-NNNN
-NNNN
-NNNN
Round 2
FAILED
(1)
-CNNN
--NNN
--NNN
Round 3
FAILED
FAILED
(1)
--CNN
---NN
Round 4
FAILED
FAILED
FAILED
(1)
---CN
Round 5
FAILED
FAILED
FAILED
FAILED
----C
NOTE: (1) site fails after sending a single message.
Figure. Worst case execution of the resilient transition
Protocol.
First message round:
Type of transaction state
Message sent
Final abort state
abort
Committable state
committable
All other states
non-committable
Second and subsequent rounds:
Message received from previous round
Message sent
One or more abort messages
abort
One or more committable messages
committable
All non-committable messages
non-committable
(a) Summary of rules for sending messages.
The transactions is terminated if:
Condition
Final state
Receipt of a single abort message
abort
Receipt of all committable messages
commit
2 successive rounds of messages where all
messages are non-committable
abort
(b) Summary of commit and termination rules.
Figure. Summary of the resilient decentralized termination protocol.
First Message round:
Trans. state
Message Sent
abort
abort
committable
committable
others
non-committable
Second and subsequent rounds:
Message from
previous round:
Message sent
abort
abort
committable
committable
all non-committable
non-commitable
Trans. is terminated if:
abort
all committable
2 successive rounds of
non-committable
(no site failure)



abort
commit
abort
Commit Rule:
A transaction is committed at a site only
after the receipt of a round consisting
entirely of committable messages
Termination Rule:
If a site ever receives two successive
rounds of non-committable messages and
it detects no site failures between rounds,
it can safely abort the transaction.
Lemma: Ni(r+1)  Ni(r)
Set of sites sending
non-committables to
site i during round r.
Lemma: If Ni(r+1) = Ni(r), then all messages
received by site i during r + r + 1 were
non-committable messages.
Recovery Protocols:
Protocols at failed site to complete all
Transactions outstanding at the time of
failure
Classes of failures:
1. Site failure
2. Lost messages
3. Network partitioning
4. Byzantine failures
Effects of failures:
1. Inconsistent database
2. Transaction processing is blocked.
3. Failed component unavailable.
Independent Recovery:
A recovering site makes a transition
directly to a final state without
communicating with other sites.
Lemma:
For a protocol, if a local state’s
concurrency set contains both an abort
and commit, it is not resilient to an
arbitrary failure of a single site.
si  commit because other
site may be in abort
cannot
si  abort
because other site
may be in commit
Rule 1:
s: Intermediate state
If C(s) contains a commit
 failure transition from
s to commit
otherwise failure transition from
s to abort
cannot
Rule 2:
For each intermediate state si:
if tj in s(si) & tj has a failure transition
to a commit (abort), then assign a
timeout transition from si to a
commit (abort).
Theorem:
Rules 1 and 2 are sufficient for
designing protocols resilient to a
single site failure.
p: consistent
site 1 fails
s1
p’: p + Failure + Timeout Transition
s2 = f2  f2  C(si)
si in s(s2)
f1
f2 ← inconsistent