1dt066 distributed information system
DESCRIPTION
1DT066 Distributed Information System. Transactions and Concurrency Control. Outline. Motivation Transaction Concepts Two Phase Commit Distributed Transactions and Deadlocks Summary. 1 Motivation. What happens if a failure occurs during modification of resources? - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/1.jpg)
1DT066DISTRIBUTED INFORMATION SYSTEM
Transactions and Concurrency Control
1
![Page 2: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/2.jpg)
OUTLINE
Motivation Transaction Concepts Two Phase Commit Distributed Transactions and
Deadlocks Summary
2
![Page 3: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/3.jpg)
1 MOTIVATION
What happens if a failure occurs during modification of resources?
Which operations have been completed? Which operations have not (and have to be done
again)? In which states will the resources be?
3
![Page 4: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/4.jpg)
1 REVISIT OF FUNDS TRANSFER EXAMPLE
Funds transfer from Acc1 to Acc2:t0
t1
t2
t3
t4
Time
Balances at t0 Acc1: 7500, Acc2: 0
t5
t6
t7
Acc1->debit(7500): Acc1->lock(write); Acc1.balance=0; Acc1->unlock(write);Acc2->credit(7500): Acc2->lock(write); Acc2.balance=7500; Acc2->unlock(write);
4
![Page 5: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/5.jpg)
1 FUNDS TRANSFER IN CONCURRENCY
Funds transfer from Acc1 Funds transfer to Acc2t0
t1
t2
t3
t4
Time
Balances at t0 Acc1: 7500, Acc2: 0
t5
t6
t7
Acc1->debit(7500): Acc1->lock(write); Acc1.balance=0; Acc1->unlock(write);
Acc2->credit(7500): Acc2->lock(write); Acc2.balance=7500; Acc2->unlock(write);
5
![Page 6: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/6.jpg)
2 TRANSACTION CONCEPTS1 ACID Properties
Atomicity Consistency Isolation Durability
2 Transaction Commit vs. Abort3 Roles of Distributed Components 4 Flat vs. Nested Transactions
6
![Page 7: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/7.jpg)
2.1.1 ATOMICITY Transactions are either performed completely or no
modification is done. Start of a transaction is a continuation point to which
it can roll back. End of transaction is next continuation point.
7
![Page 8: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/8.jpg)
2.1.2 CONSISTENCY Shared resources should always be consistent. Inconsistent states occur during transactions:
hidden for concurrent transactions to be resolved before end of transaction.
Application defines consistency and is responsible for ensuring it is maintained.
Transactions can be aborted if they cannot resolve inconsistencies.
8
![Page 9: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/9.jpg)
2.1.3 ISOLATION Each transaction accesses resources as if there
were no other concurrent transactions. Modifications of the transaction are not visible to
other resources before it finishes. Modifications of other transactions are not visible
during the transaction at all. Implemented through:
two-phase locking or optimistic concurrency control.
9
![Page 10: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/10.jpg)
2.1.4 DURABILITY A completed transaction is always persistent (though
values may be changed by later transactions). Modified resources must be held on persistent
storage before transaction can complete. Wide use of hard disks.
10
![Page 11: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/11.jpg)
2.2 TRANSACTION COMMANDS Begin:
Start a new transaction. Commit:
End a transaction. Store changes made during transaction. Make changes accessible to other transactions.
Abort: End a transaction. Undo all changes made during the transaction.
11
![Page 12: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/12.jpg)
2.3 ROLES OF COMPONENTS
Distributed system components involved in transactions can take role of:Transactional ClientTransactional ServerCoordinator
12
![Page 13: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/13.jpg)
2.3.1 COORDINATOR Coordinator plays key role in managing transaction. Coordinator is the component that handles begin /
commit / abort transaction calls. Coordinator allocates system-wide unique
transaction identifier. Different transactions may have different
coordinators.
13
![Page 14: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/14.jpg)
2.3.2 TRANSACTIONAL SERVER Every component with a resource accessed or
modified under transaction control. Transactional server has to know coordinator. Transactional server registers its participation in
a transaction with the coordinator. Transactional server has to implement a
transaction protocol (two-phase commit).
14
![Page 15: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/15.jpg)
2.3.3 TRANSACTIONAL CLIENT Only sees transactions through the transaction
coordinator. Invokes services from the coordinator to begin,
commit and abort transactions. Implementation of transactions are transparent
for the client. Cannot tell difference between server and
transactional server.
15
![Page 16: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/16.jpg)
2.4 DISTRIBUTED TRANSACTIONS
Client
X
Y
Z
X
Y
M
NT1
T2
T11
Client
P
TT 12
T21
T22
(a) Flat transaction (b) Nested transactions
TT
16
![Page 17: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/17.jpg)
2.4 FLAT TRANSACTIONS
Flat Transaction
Commit
Crash
Flat Transaction
Rollback
BeginTrans.
BeginTrans.
Rollback
BeginTrans.
Flat Transaction
Abort
17
![Page 18: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/18.jpg)
2.4 NESTED TRANSACTIONSMain Transaction
Call Call
Call
Commit
BeginTrans.
BeginTrans.
CommitBeginTrans.
CommitBeginTrans.
Commit
18
![Page 19: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/19.jpg)
3 TWO-PHASE COMMIT Multiple autonomous distributed servers:
For a commit, all transactional servers have to be able to commit.
If a single transactional server cannot commit its changes every server has to abort.
Single phase protocol is insufficient. Two phases are needed:
Phase one: Voting Phase two: Completion.
19
![Page 20: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/20.jpg)
3.1 PHASE ONE Called the voting phase. Coordinator asks all servers if they are able (and
willing) to commit. Servers reply:
Yes: it will commit if asked, but does not yet know if it is actually going to commit.
No: it immediately aborts its operations. Hence, servers can unilaterally abort but not
unilaterally commit a transaction.
20
![Page 21: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/21.jpg)
3.1 PHASE TWO Called the completion phase. Co-ordinator collates all votes, including its own, and
decides to commit if everyone voted ‘Yes’. abort if anyone voted ‘No’.
All voters that voted ‘Yes’ are sent ‘DoCommit’ if transaction is to be committed. Otherwise ‘Abort'.
Servers acknowledge DoCommit once they have committed.
21
![Page 22: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/22.jpg)
3.1 SERVER UNCERTAINTY Period when a server must be able to commit,
but does not yet know if has to. This period is known as server uncertainty. Usually short (time needed for coordinator to
receive and process votes). However, failures can lengthen this process,
which may cause problems.
22
![Page 23: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/23.jpg)
3.2 RECOVERY IN TWO-PHASE COMMIT Failures prior to start of 2PC results in abort. Coordinator failure prior to transmitting commit
messages results in abort. After this point, coordinator will retransmit all commit
messages on restart. If server fails prior to voting, it aborts. If it fails after voting, it sends GetDecision. If it fails after committing it (re)sends HaveCommitted
message.
23
![Page 24: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/24.jpg)
3.2 COMPLEXITYAssuming N participating servers: (N-1) Voting requests from coordinator to servers. (N-1) Votes from servers to coordinator. At most (N-1) Completion requests from coordinator to
servers. (When commit) (N-1) acknowledgement from servers to
coordinator. Hence, complexity of requests is linear in the number of
participating servers.
24
![Page 25: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/25.jpg)
3.3 COMMITTING NESTED TRANSACTIONS Cannot use same mechanism to commit nested
transactions as: subtransactions can abort independent of parent. subtransactions must have made decision to commit or
abort before parent transaction. Top level transaction needs to be able to
communicate its decision down to all subtransactions so they may react accordingly.
25
![Page 26: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/26.jpg)
3.3 PROVISIONAL COMMIT Subtransactions vote either:
aborted or provisionally committed.
Abort is handled as normal. Provisional commit means that coordinator and
transactional servers are willing to commit subtransaction but have not yet done so.
26
![Page 27: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/27.jpg)
3.3 EXAMPLE FOR A NESTED TRANSACTION
1
2
T11
T12
T22
T21
abort (at M)
provisional commit (at N)
provisional commit (at X)
aborted (at Y)
provisional commit (at N)
provisional commit (at P)
T
T
T
27
![Page 28: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/28.jpg)
3.3 INFORMATION HELD BY COORDINATORS
Coordinator oftransaction
Childtransactions
Participant Provisionalcommit list
Abort list
T T1, T2 yes T1, T12 T11, T2T1 T11, T12 yes T1, T12 T11T2 T21, T22 no (aborted) T2T11 no (aborted) T11T12, T21 T12 but notT21 T21, T12T22 no (parent aborted)T22
28
![Page 29: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/29.jpg)
3.3 TWO-PHASE COMMIT FOR NESTED TRANSACTIONS For nested transactions, the top-level
transaction plays as coordinator, while participants are all the provisionally committed subtransaction coordinators without aborted ancestors.
Hierarchic two-phase commit: a multi-level nested protocol where the coordinator communicates to the immediate child transaction coordinator in a hierarchic fashion.
Flat two-phase commit: the coordinator contact all participants with provisional commit directly.29
![Page 30: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/30.jpg)
3.3 LOCKING AND PROVISIONAL COMMITS
Locks cannot be released after provisional commit. Data items remain ‘protected’ until top-level transaction
commits. This may reduce concurrency. Interactions between sibling subtransactions:
should they be prevented as they are different? allowed as they are part of the same transaction?
Generally they are prevented.
30
![Page 31: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/31.jpg)
4 DISTRIBUTED TRANSACTIONS AND DEADLOCKS In distributed transactions, each server is
responsible for applying concurrency control to its own objects, and all the servers jointly ensure the concurrent transactions are performed in a serially equivalent manner.
This means interleavings of two transactions have to be serially equivalent both locally at each server and globally.
31
![Page 32: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/32.jpg)
4.1 INTERLEAVINGS OF TWO TRANSACTIONS
T U
Write (A) at X
Write (B)
Read (B) at Y
Read (A) at X
at Y
Transaction T before Transaction U on server X Transaction U before Transaction T on server Y This is not serially equivalent globally since T before U in one
server and U before T in another. 32
![Page 33: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/33.jpg)
4.1 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 Xc.deposit(30) lock C
b.withdraw(30) wait at Y at Z
c.withdraw(20) wait at Z
a.withdraw(20) wait at X
at Z
33
![Page 34: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/34.jpg)
4.3 DISTRIBUTED DEADLOCK
D
Waits for
Waitsfor
Held by
Heldby
B Waits forHeld
by
X
Y
Z
Held by
W
UV
AC
W
V
U
(a) (b)
34
![Page 35: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/35.jpg)
4.2 LOCAL AND GLOBAL WAIT-FOR GRAPHS
X
T U
Y
V TT
U V
local wait-for graph local wait-for graph global deadlock detector
• Phantom deadlock: A deadlock that is “detected” but is not really a deadlock is called a phantom deadlock.
• E.g.: Transaction U releases an object at server X and requests the one held by V at server Y. Assuming the latter is first received. 35
![Page 36: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/36.jpg)
4.3 PROBES TRANSMITTED TO DETECT DEADLOCK
V
Held byW
Waits forHeld by
Waitsfor
Waits forDeadlockdetected
U
C
A
B
Initiation
W® U ® V ® W
W® U
W ® U ® V
Z
Y
X
36
![Page 37: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/37.jpg)
4.3 TWO PROBES INITIATED(a) initial situation (b) detection initiated at object
requested by T(c) detection initiated at object requested by W
U
T
V
W
Waits for
Waitsfor
V
W
U
T
T ® U ® W ® VT ® U ® W
T ® UWaits for
UV
T
W
W ® V ® T W ® V ® T ® U
W ® V Waits
for
37
![Page 38: 1DT066 Distributed Information System](https://reader035.vdocuments.us/reader035/viewer/2022062323/56816439550346895dd60277/html5/thumbnails/38.jpg)
6 SUMMARY Transaction concepts:
ACID Transaction commands Roles of distributed components in transactions
Two-phase commit phase one: voting phase two: completion
Distributed Transactions and Distributed Deadlocks
Read Textbook Chapter 16.
38