Sie sind auf Seite 1von 38

1DT066 DISTRIBUTED INFORMATION SYSTEM

Transactions and Concurrency Control

OUTLINE
Motivation Transaction Two

Concepts

Phase Commit

Distributed
Summary

Transactions and Deadlocks

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?

1 REVISIT OF FUNDS TRANSFER EXAMPLE


Balances at t0 Acc1: 7500, Acc2: 0 Funds transfer from Acc1 to Acc2:
t0 t1 t2 t3 t4 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

Time

1 FUNDS TRANSFER IN CONCURRENCY


Balances at t0 Acc1: 7500, Acc2: 0 Funds transfer from Acc1
t0 t1 t2 t3 t4 t5 Acc1->debit(7500): Acc1->lock(write); Acc1.balance=0; Acc1->unlock(write); Acc2->credit(7500): Acc2->lock(write); Acc2.balance=7500; Acc2->unlock(write);

Funds transfer to Acc2

t6 t7

Time

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

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.

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.

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.

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

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

2.3 ROLES OF COMPONENTS


Distributed system components involved in transactions can take role of:
Transactional Transactional Coordinator

Client Server

12

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

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

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

2.4 DISTRIBUTED TRANSACTIONS


(a) Flat transaction
X

(b) Nested transactions


M T11 X Client

T
T

T1 T 12 T
21

Client

T2
Y Z T

P
22

16

2.4 FLAT TRANSACTIONS


Begin Trans. Commit

Flat Transaction

Begin Trans.

Crash

Begin Trans.

Abort

Flat Transaction
Rollbac k

Flat Transaction
Rollbac k

17

2.4 NESTED TRANSACTIONS


Begin Trans. Call

Main Transaction
Call

Commit

Begin Trans. Call

Commit

Begin Trans.

Commit

Begin Trans.

Commit

18

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

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

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

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

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

3.2 COMPLEXITY
Assuming 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

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

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

3.3 EXAMPLE FOR A NESTED TRANSACTION


T
T1 T

11

abort (at M)

provisional commit (at X) T provisional commit (at N) provisional commit (at N)

12

T21 T
2

aborted (at Y)

22

provisional commit (at P)

27

3.3 INFORMATION HELD BY COORDINATORS

Coordinator of transaction T T1 T2 T 11 T 12 , T 21 T 22

Child transactions T 1, T 2 T 11 , T 12 T 21 , T 22

Participant

yes yes no (aborted) no (aborted) T 12 but not T 21 T 21 , T 12 no (parent aborted) T 22

Provisional commit list T 1, T 12 T 1, T 12

Abort list T 11 , T 2 T 11 T2 T 11

28

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

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

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

4.1 INTERLEAVINGS OF TWO TRANSACTIONS


T Write (A) at X Write (B) Read (B) at Y Read (A) at X at Y U

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 32 and U before T in another.

4.1 INTERLEAVINGS OF TRANSACTIONS U, V AND W


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

c.deposit(30)
b.withdraw(30)

lock C at Z

33

4.3 DISTRIBUTED DEADLOCK


(a)
W Held by Waits for

(b)
W

A X Held by Held by U B Held by Y 34 Waits for


U

Waits for

4.2 LOCAL AND GLOBAL WAIT-FOR GRAPHS


local wait-for graph local wait-for graph global deadlock detector

T X

V Y

T U

T V

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 35 latter is first received.

4.3 PROBES TRANSMITTED TO DETECT DEADLOCK


W U V W Deadlock detected C Z W U V W Held by

Waits for

A Initiation
W U V X

Waits for

Held by Y

Waits for
36

4.3 TWO PROBES INITIATED


(a) initial situation (b) detection initiated at object requested by T (c) detection initiated at object requested by W

Waits for

T U

Waits for

U
U

T
W

V
V
W

T W

V W

V
TUWV

VTU
U

TUW

Waits for

V
W
Waits for

37

6 SUMMARY

Transaction concepts:

ACID Transaction commands Roles of distributed components in transactions phase one: voting phase two: completion

Two-phase commit

Distributed Transactions and Distributed Deadlocks Read Textbook Chapter 16.

38

Das könnte Ihnen auch gefallen