of 38
7/28/2019 Distributed System Transactions
1/38
1DT066
DISTRIBUTED INFORMATION SYSTEM
Transactions and Concurrency Control
1
7/28/2019 Distributed System Transactions
2/38
OUTLINE
Motivation
Transaction Concepts
Two Phase CommitDistributed Transactions and Deadlocks
Summary
2
7/28/2019 Distributed System Transactions
3/38
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
7/28/2019 Distributed System Transactions
4/38
7/28/2019 Distributed System Transactions
5/38
1 FUNDS TRANSFERIN CONCURRENCY
Funds transfer from Acc1 Funds transfer to Acc2t0
t1
t2
t3
t4
Time
Balances at t0Acc1: 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
7/28/2019 Distributed System Transactions
6/38
2 TRANSACTION CONCEPTS
1 ACID Properties
Atomicity
Consistency
Isolation
Durability
2 Transaction Commit vs. Abort
3 Roles of Distributed Components
4 Flat vs. Nested Transactions
6
7/28/2019 Distributed System Transactions
7/38
2.1.1 ATOMICITY
Transactions are either performed completely or nomodification is done.
Start of a transaction is a continuation point to which it can
roll back.
End of transaction is next continuation point.
7
7/28/2019 Distributed System Transactions
8/38
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 ensuringit is maintained.
Transactions can be aborted if they cannot resolve
inconsistencies.
8
7/28/2019 Distributed System Transactions
9/38
2.1.3 ISOLATION
Each transaction accesses resources as if there wereno other concurrent transactions.
Modifications of the transaction are not visible to other
resources before it finishes.
Modifications of other transactions are not visible duringthe transaction at all.
Implemented through:
two-phase locking or
optimistic concurrency control.
9
7/28/2019 Distributed System Transactions
10/38
2.1.4 DURABILITY
A completed transaction is always persistent (though valuesmay be changed by later transactions).
Modified resources must be held on persistent storage
before transaction can complete.
Wide use of hard disks.
10
7/28/2019 Distributed System Transactions
11/38
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
7/28/2019 Distributed System Transactions
12/38
2.3 ROLESOF COMPONENTS
Distributed system components involved in transactions
can take role of:
Transactional Client
Transactional Server
Coordinator
12
7/28/2019 Distributed System Transactions
13/38
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
7/28/2019 Distributed System Transactions
14/38
2.3.2 TRANSACTIONAL SERVER
Every component with a resource accessed or modifiedunder 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
7/28/2019 Distributed System Transactions
15/38
2.3.3 TRANSACTIONAL CLIENT
Only sees transactions through the transactioncoordinator.
Invokes services from the coordinator to begin, commit
and abort transactions.
Implementation of transactions are transparent for theclient.
Cannot tell difference between server and transactional
server.
15
7/28/2019 Distributed System Transactions
16/38
2.4 DISTRIBUTED TRANSACTIONS
Client
X
Y
Z
X
Y
M
NT1
T2
T11
Client
P
TT12
T21
T22
(a) Flat transaction (b) Nested transactions
TT
16
7/28/2019 Distributed System Transactions
17/38
2.4 FLAT TRANSACTIONS
Flat Transaction
Commit
Crash
Flat Transaction
Rollback
BeginTrans.
BeginTrans.
Rollback
BeginTrans.
Flat Transaction
Abort
17
7/28/2019 Distributed System Transactions
18/38
7/28/2019 Distributed System Transactions
19/38
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
7/28/2019 Distributed System Transactions
20/38
3.1 PHASE ONE
Called the votingphase. 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 isactually going to commit.
No: it immediately aborts its operations.
Hence, servers can unilaterally abort but not unilaterally
commit a transaction.
20
7/28/2019 Distributed System Transactions
21/38
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
7/28/2019 Distributed System Transactions
22/38
3.1 SERVER UNCERTAINTY
Period when a server must be able to commit, but doesnot 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
7/28/2019 Distributed System Transactions
23/38
3.2 RECOVERYIN 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 messageson 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
7/28/2019 Distributed System Transactions
24/38
3.2 COMPLEXITY
Assuming Nparticipating 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 tocoordinator.
Hence, complexity of requests is linear in the number ofparticipating servers.
24
7/28/2019 Distributed System Transactions
25/38
3.3 COMMITTING NESTED TRANSACTIONS
Cannot use same mechanism to commit nested transactionsas:
subtransactions can abort independent of parent.
subtransactions must have made decision to commit or abortbefore parent transaction.
Top level transaction needs to be able to communicate its
decision down to all subtransactions so they may react
accordingly.
25
7/28/2019 Distributed System Transactions
26/38
3.3 PROVISIONAL COMMIT
Subtransactions vote either: aborted or
provisionally committed.
Abort is handled as normal.
Provisional commit means that coordinator andtransactional servers are willing to commit
subtransaction but have not yet done so.
26
7/28/2019 Distributed System Transactions
27/38
3.3 EXAMPLEFOR A NESTED TRANSACTION
1
2
T11
T12
T
22
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
7/28/2019 Distributed System Transactions
28/38
3.3 INFORMATION HELDBY COORDINATORS
Coordinator of
transaction
Child
transactions
Participant Provisional
commit list
Abort list
T T1, T2 yes T1, T12 T11, T2T1 T11, T12 yes T1, T12 T11
T2 T21, T22 no (aborted) T2
T11 no (aborted) T11
T12, T21 T12but notT21 T21, T12
T22 no (parent aborted)T22
28
7/28/2019 Distributed System Transactions
29/38
3.3 TWO-PHASE COMMITFOR NESTED
TRANSACTIONS
For nested transactions, the top-level transaction playsas coordinator, while participants are all the
provisionally committed subtransaction coordinators
without aborted ancestors.
Hierarchic two-phase commit: a multi-level nestedprotocol where the coordinator communicates to the
immediate child transaction coordinator in a hierarchic
fashion.
Flat two-phase commit: the coordinator contact allparticipants with provisional commit directly.
29
7/28/2019 Distributed System Transactions
30/38
3.3 LOCKINGAND 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
7/28/2019 Distributed System Transactions
31/38
4 DISTRIBUTED TRANSACTIONSAND DEADLOCKS
In distributed transactions, each server is responsible forapplying 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 locallyat each server and
globally.
31
7/28/2019 Distributed System Transactions
32/38
4.1 INTERLEAVINGSOF 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 serverand U before T in another.
32
7/28/2019 Distributed System Transactions
33/38
4.1 INTERLEAVINGSOF TRANSACTIONSU, VANDW
U V W
d.deposit(10) lockD
b.deposit(10) lockB
a.deposit(20) lockA at Y
at X
c.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
7/28/2019 Distributed System Transactions
34/38
4.3 DISTRIBUTED DEADLOCK
D
Waits for
Waits
for
Held by
Held
by
B Waits for
Heldby
X
Y
Z
Held by
W
UV
AC
W
V
U
(a) (b)
34
7/28/2019 Distributed System Transactions
35/38
4.2 LOCALAND 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 andrequests the one held by V at server Y. Assuming the
latter is first received. 35
4 3 P T D D
7/28/2019 Distributed System Transactions
36/38
4.3 PROBES TRANSMITTEDTO DETECT DEADLOCK
V
Held by
W
Waits forHeld by
Waitsfor
Waits forDeadlock
detected
U
C
A
B
Initiation
W
U
V
W
WU
WU V
Z
Y
X
36
7/28/2019 Distributed System Transactions
37/38
4.3 TWO PROBES INITIATED
(a) initial situation (b) detection initiated at objectrequested by T
(c) detection initiated at object
requested by W
U
T
V
W
Waits for
Waitsfor
V
W
U
T
TUWVTUW
TUWaits for
U
V
T
W
WVTWVTU
WVWaitsfor
37
7/28/2019 Distributed System Transactions
38/38
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