Distributed Transactions:

Distributed deadlocks
Recovery techniques
Distributed Deadlocks

We have talked about deadlocks in a single server

environment
Deadlocks have to be either
Prevented or
Detected and resolved

Distributed deadlock
Detection
Global wait-for graph
Simple idea
Central server takes the role of global deadlock detector
Interleavings of transactions U, V and W

U V W
d.deposit(10) lock D
b.deposit(10) lock B
a.deposit(20) lock A at Y
at X
c.deposit(30) lock C
b.withdraw(30) waitat Y at Z

c.withdraw(20) waitat Z
a.withdraw(20) waitat X
Distributed deadlock
(a) (b)
W
W
Held by Waits for

C D A

Z X V
Held
Waits Held by by
for U
V U

B Waits for
Held
by
Y
Phantom Deadlocks

A deadlock is detected but not really a deadlock

In distributed deadlock detection, servers pass along information about
wait-for relationships => if theres a deadlock itll be eventually detected
at one place
Due to elapsed time, there may be a situation that an object was detected as
locked, which may later on be released.

localwaitforgraph localwaitforgraph globaldeadlockdetector

x T
T U V T

T->U->V->T U V
X Y
Edge-chasing algorithm
Probes transmitted to detect deadlock
W
W U V W Held by Waits for
Deadlock
detected C
A
Z
Initiation X
W U V
Waits
for W U

V
U

Held by Waits for

Y B
Two probes initiated

(a)initialsituation (b)detectioninitiatedatobject (c)detectioninitiatedatobject

requestedbyT requestedbyW

T
Waits for T Waits for T T U W V T
V U W V T U
V U V
T U W U
T U W V
W Waits
for W V
Waits
W W for
Probes travel downhill
.

(a)VstoresprobewhenUstartswaiting (b)ProbeisforwardedwhenVstartswaiting

W
W UV probe
U Waits V W queue
for C
U V U

V Waits for
V Waits for
probe U V B B
queue UV
Recovery

Atomicity property
Durability and failure atomicity
Durability: objects are saved in a permanent storage
Failure: effects of transaction are atomic even when the server
crashes
Assumptions
a running server keeps all its objects in volatile memory and
records of committed transactions in a recovery file.
Recovery:
restoring the server with its latest committed versions of its objects
from the permanent storage
Recovery manager:
save objects in permanent storage for committed transactions
restore servers objects after a crash
reorganize the recovery file to improve performance
reclaim storage space
 Types of entry in a recovery file
To deal with the recovery process:
Object value, status of the transaction, Intentions list (list
of references and values of all objects altered by that
transaction, useful in 2PC)
Typeofentry Descriptionofcontentsofentry
Object Avalueofanobject.
Transactionstatus Transactionidentifier,transactionstatus( prepared , committed
aborted )andotherstatusvaluesusedforthetwophase
commitprotocol.
Intentionslist Transactionidentifierandasequenceofintentions,eachof
whichconsistsof<identifierofobject>,<positioninrecovery
fileofvalueofobject>.
Logging
Logs
Contain history of all transactions performed by a server
Recovery manager is called when a server is
Prepared to commit a transaction
appends all the objects in the intentions list to a
recovery file, followed by the current status of the
transaction
Commits/Aborts
appends the corresponding status of the transaction
After a crash:
any transaction that doesnt have a committed status is
aborted. (so, when a transaction commits, its status is
forced onto the log)
Example: Logging

Wh
en T
Aa com
n mit
upd d B ar s,
at ed e
at P
1, P
2

T commits U prepares
Snapshot of the values of A, B, C for commit
P0 P1 P2 P3 P4 P5 P6 P7
Object:A Object:B Object:C Object:A Object:B Trans:T Trans:T Object:C Object:B Trans:U
100 200 300 80 220 prepared committed 278 242 prepared
<A,P1> <C,P5>
<B,P2> <B,P6>
P0 P3 P4
Checkpoint
End
of log
Recovery
Server restarts after crash
Sets default initial values for objects and starts the recovery
manager.
Two approaches:
Forward:
The recovery manager starts from the beginning and restores all the
object values starting from the most recent checkpoint.
It then reads the values of all the objects and associates them with their
intentions list, for committed transactions replaces the values of the obj.
Like replaying
Backward:
Uses the backward pointers
Committed transactions are used to restore objects that are not
restored.
It continues until all of the servers objects are restored.
Importance of Checkpointing

It saves lots of extra work

What happens if there were no checkpoints?
P0 P1 P2 P3 P4 P5 P6 P7
Object:A Object:B Object:C Object:A Object:B Trans:T Trans:T Object:C Object:B Trans:U
100 200 300 80 220 prepared committed 278 242 prepared
<A,P1> <C,P5>
<B,P2> <B,P6>
P0 P3 P4
Checkpoint
End
To restore of log
the value of C

We have to go up to P0 to restore all objects

Shadow versions

An alternate approach
uses a map to locate versions of objects in a file called version store
map -- Object id to positions of current version in version store
The versions written by each transactions are shadows of committed
transactions
How does it work:
When a transaction is prepared to commit, any of the objects changed
by the transaction is added to the version store => shadow version
When a transaction commits, a new map is made by copying the old
map and entering the positions of the shadow versions.
The new map replaces the old map.

Recovery:
The RM reads the map and uses it to locate the objects in the version
store.
Shadow versions
P0 P0 P0
P1 P2 P3 P4 P5 P6 P7
Object:A Object:B Object:C Object:A Object:B Trans:T Trans:T Object:C Object:B Trans:U
100 200 300 80 220 prepared committed 278 242 prepared
<A,P1> <C,P5>
<B,P2> <B,P6>
P0 P3 P4
Checkpoint
End
of log

Mapatstart MapwhenTcommits
A P 0 A
P 1
B P 0 ' B
P 2
C P 0 " C
P 0 "

P0 P0' P0" P1 P2 P3 P4
Versionstore 100 200 300 80 220 278 242
Checkpoint
Log with entries relating to two-phase commit protocol

Trans:T Coordr:T Trans:T Trans:U Partpant:U Trans:U Trans:U

prepared partpant committed prepared Coordr:.. uncertain committed

list:...
intentions intentions
list list
Recovery of the two-phase commit protocol
Role Status Actionofrecoverymanager
Coordinator prepared Nodecisionhadbeenreachedbeforetheserverfailed.Itsends
abortTransaction toalltheserversintheparticipantlistandaddsthe
transactionstatus abortedinitsrecoveryfile.Sameactionforstate
aborted.Ifthereisnoparticipantlist,theparticipantswilleventually
timeoutandabortthetransaction.
Coordinator committed Adecisiontocommithadbeenreachedbeforetheserverfailed.It
sendsa doCommittoalltheparticipantsinitsparticipantlist(incase
ithadnotdonesobefore)andresumesthetwophaseprotocolatstep4
(Fig13.5).
Participant committed Theparticipantsendsa haveCommitted messagetothecoordinator(in
casethiswasnotdonebeforeitfailed).Thiswillallowthecoordinator
todiscardinformationaboutthistransactionatthenextcheckpoint.
Participant uncertain Theparticipantfailedbeforeitknewtheoutcomeofthetransaction.It
cannotdeterminethestatusofthetransactionuntilthecoordinator
informsitofthedecision.Itwillsenda getDecision tothecoordinator
todeterminethestatusofthetransaction.Whenitreceivesthereplyit
willcommitorabortaccordingly.
Participant prepared Theparticipanthasnotyetvotedandcanabortthetransaction.
Coordinator done Noactionisrequired.