Distributed System Transactions

7/28/2019 Distributed System Transactions

1/38

1DT066

DISTRIBUTED INFORMATION SYSTEM

Transactions and Concurrency Control

1


2/38

OUTLINE

Motivation

Transaction Concepts

Two Phase CommitDistributed Transactions and Deadlocks

Summary

2


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


4/38


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


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/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


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


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


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


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


12/38

2.3 ROLESOF COMPONENTS

Distributed system components involved in transactions

can take role of:

Transactional Client

Transactional Server

Coordinator

12


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


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


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


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


17/38

2.4 FLAT TRANSACTIONS

Flat Transaction

Commit

Crash

Flat Transaction

Rollback

BeginTrans.

BeginTrans.

Rollback

BeginTrans.

Flat Transaction

Abort

17


18/38


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

Documents

Distributed System Transactions