1

Distribuerede systemer og sikkerhed – 18. marts 2002

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design

Edition 3, © Addison-Wesley 2001

Presentation based on slides for the book:

Slides modified by Jens B Jorgensen, University of Aarhus

2

Chapter 12: Transactions and Concurrency Control

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design

Edition 3, © Addison-Wesley 2001

3

Transactions – basics

System model: One server, multiple clients.Goal: Objects at server remain consistent.Failure model: Server crashes, omission failures,

arbitrary delays.Transaction:

Set of operations on objects to be performed as an indivisible unit by the server.

Server must guarantee that either the entire transaction is carried out and the results recorded in permanent storage or (if crash) its effects are completely erased.

Essential properties: ACID.

4

Transactions – bank server

deposit(amount)deposit amount in the account

withdraw(amount)withdraw amount from the account

getBalance() -> amountreturn the balance of the account

setBalance(amount)set the balance of the account to amount

create(name) -> accountcreate a new account with a given name

lookUp(name) -> account return a reference to the account with the given name

branchTotal() -> amountreturn the total of all the balances at the branch

Operations of the Branch interface

Operations of the Account interface

5

Transactions – a client’s banking transaction

Transaction T:a.withdraw(100);b.deposit(100);c.withdraw(200);b.deposit(200);

6

Transactions – life histories

Successful Aborted by client Aborted by server

openTransaction openTransaction openTransactionoperation operation operation operation operation operation

server abortstransaction

operation operation operation ERRORreported to client

closeTransaction abortTransaction

Coordinator interface:openTransaction() -> trans;closeTransaction(trans) -> (commit,abort);abortTransaction(trans);

7

Concurrent transactions – the lost update problem

Transaction T :

balance = b.getBalance();b.setBalance(balance*1.1);a.withdraw(balance/10)

Transaction U:

balance = b.getBalance();b.setBalance(balance*1.1);c.withdraw(balance/10)

balance = b.getBalance(); $200

balance = b.getBalance(); $200

b.setBalance(balance*1.1); $220

b.setBalance(balance*1.1); $220

a.withdraw(balance/10) $80

c.withdraw(balance/10) $280

8

Concurrent transactions – the inconsistent retrievals problem

Transaction V:

a.withdraw(100)b.deposit(100)

Transaction W:

aBranch.branchTotal()

a.withdraw(100); $100

total = a.getBalance() $100

total = total+b.getBalance() $300

total = total+c.getBalance()

b.deposit(100) $300

9

Concurrent transactions – serial equivalence

If “correct” transactions are done one at a time in some order, the combined effect will also be correct.

A serially equivalent interleaving: An interleaving of the operations of transactions in which the combined effect is the same as if the transactions had been performed one at a time in some order.

Serial equivalence prevents lost updates and inconsistent retrievals.

10

Concurrent transactions – a serially equivalent interleaving of T and U

Transaction T:

balance = b.getBalance()b.setBalance(balance*1.1)a.withdraw(balance/10)

Transaction U:

balance = b.getBalance()b.setBalance(balance*1.1)c.withdraw(balance/10)

balance = b.getBalance() $200

b.setBalance(balance*1.1) $220balance = b.getBalance() $220

b.setBalance(balance*1.1) $242

a.withdraw(balance/10) $80 c.withdraw(balance/10) $278

11

Concurrent transactions – a serially equivalent interleaving of V and W

Transaction V: a.withdraw(100);b.deposit(100)

Transaction W:

aBranch.branchTotal()

a.withdraw(100); $100

b.deposit(100) $300

total = a.getBalance() $100

total = total+b.getBalance() $400

total = total+c.getBalance()...

12

Concurrent transactions – conflicting operations

Two operations conflict iff their combined effect depends on the order in which they are executed.

For two transactions to be executed serially equivalent, it is necessary and sufficient that all pairs of conflicting operations of the two transactions be executed in the same order at all of the objects they both access.

13

Concurrent transactions – read and write operation conflict rules

Operations of differenttransactions

Conflict Reason

read read No Because the effect of a pair of read operationsdoes not depend on the order in which they areexecuted

read write Yes Because the effect of a read and a write operationdepends on the order of their execution

write write Yes Because the effect of a pair of write operationsdepends on the order of their execution

14

Concurrent transactions – interleaving of operations of transactions T and U

Transaction T: Transaction U:

x = read(i)

write(i, 10)y = read(j)

write(j, 30)

write(j, 20)z = read (i)

Serially equivalent?

15

Aborting transactions – dirty read

Transaction T:

a.getBalance()a.setBalance(balance + 10)

Transaction U:

a.getBalance()a.setBalance(balance + 20)

balance = a.getBalance() $100

a.setBalance(balance + 10) $110

balance = a.getBalance() $110

a.setBalance(balance + 20) $130

commit transaction

abort transaction

16

Aborting transactions – premature writes

Transaction T:

a.setBalance(105)

Transaction U:

a.setBalance(110)

$100

a.setBalance(105) $105

a.setBalance(110) $110

17

Aborting transactions – strict execution

A transaction delays both read and write operations on an object, until all transactions that previously wrote that object have either committed or aborted.

Other issues: Cascading aborts. Tentative versions.

18

Nested transactions

T : top-level transactionT1 = openSubTransaction T2 = openSubTransaction

openSubTransaction openSubTransactionopenSubTransaction

openSubTransaction

T1 : T2 :

T11 : T12 :

T211 :

T21 :

prov.commit

prov. commit

abort

prov. commitprov. commit

prov. commit

commit

19

Locks – example

Transaction T: balance = b.getBalance()b.setBalance(bal*1.1)a.withdraw(bal/10)

Transaction U:

balance = b.getBalance()b.setBalance(bal*1.1)c.withdraw(bal/10)

Operations Locks Operations Locks

openTransactionbal = b.getBalance() lock B

b.setBalance(bal*1.1) openTransaction

a.withdraw(bal/10) lock A bal = b.getBalance() waits for T’slock on B

closeTransaction unlock A, B lock B

b.setBalance(bal*1.1)

c.withdraw(bal/10) lock C

closeTransaction unlock B, C

20

Locks – locking schemes

Exclusive locks: The server attempts to lock any object that is about to be used by any

operation of a client’s transaction. If a client requests access to an object that is already locked, the

request is suspended and the client must wait. Two-phase locking:

A transaction is not allowed any new locks after it has released a lock. Growing phase: New locks are acquired. Shrinking phase: Locks are released.

Strict two-phase locking: Any locks acquired during the progress of a transaction are held until the transaction commits or aborts.

Concurrency control granularity an import issue.

21

Locks – read and write locks

Allow several concurrent transactions to read an object.

Ensure exclusive access for writing.

For one object Lock requested read write

Lock already set none OK OK

read OK wait

write wait wait

22

Locks – read and write locks in strict two-phase locking

1. When an operation accesses an object within a transaction:(a) If the object is not already locked, it is locked and the operation

proceeds.(b) If the object has a conflicting lock set by another transaction, the

transaction must wait until it is unlocked.(c) If the object has a non-conflicting lock set by another transaction, the

lock is shared and the operation proceeds.(d) If the object has already been locked in the same transaction, the lock

will be promoted if necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock, rule (b) is used.)

2. When a transaction is committed or aborted, the server unlocks all objects it locked for the transaction.

23

Deadlocks – basics

Transaction T Transaction U

Operations Locks Operations Locks

a.deposit(100); write lock A

b.deposit(200) write lock B

b.withdraw(100)waits for U’s a.withdraw(200); waits for T’s

lock on B lock on A

Deadlock: Each member of a group of transactions is waiting forsome other member to release a lock.

24

Deadlocks – wait-for graphs

B

A

Waits for

Held by

Held by

T UU T

Waits for

Representation of waiting relationship between ongoing transactions.Deadlocks correpond to cycles.To recover from a deadlock, break a cycle.

25

Deadlocks – resolution via timeouts

Transaction T Transaction U

Operations Locks Operations Locks

a.deposit(100); write lock A

b.deposit(200) write lock B

b.withdraw(100)

waits for U’s a.withdraw(200); waits for T’s

lock on B lock on A (timeout elapses) T’s lock on A becomes vulnerable,

unlock A, abort Ta.withdraw(200); write locks A

unlock A, B

26

Optimistic concurrency control – motivation

Locking may result in overhead, deadlocks, and reduced concurrency.

Observation: In most applications, the likelihood of two clients’ transactions accessing the same object is low.

Method: Go ahead, but do check upon closeTransaction!

27

Optimistic concurrency control – transaction phases

Working phase: Each transaction has a tentative version of each of the objects that it

updates. Read set and write set maintained.

Validation phase: When the closeTransaction request is received, the transaction is

validated to establish whether or not its operations on objects conflict with operations of other transactions.

If success the commit. If fail then some transaction must be aborted.

Update phase: Record changes to tentative versions as permanent.

28

Optimistic concurrency control – overall validation strategy

Use read-write conflict rules.For a given transaction, ensure serial equivalence

with all other overlapping transactions.Transactions are assigned increasing numbers when

they enter validation phase.Assumption: At any time, at most one transaction is

in the validation and update phase.

29

Optimistic concurrency control – validation rules

Tv Ti Rule

write read 1. Ti must not read objects written by Tv

read write 2. Tv must not read objects written by Ti

write write 3. Ti must not write objects written by Tv and

Tv mustnot write objects written by Ti

Serializability of transactions Tv and Ti:

30

Optimistic concurrency control – validation algorithms

Backward validation of transaction Tv

boolean valid = true;for (int Ti = startTn+1; Ti <= finishTn; Ti++){

if (read set of Tv intersects write set of Ti) valid = false;}

Forward validation of transaction Tv

boolean valid = true;for (int Tid = active1; Tid <= activeN; Tid++){

if (write set of Tv intersects read set of Tid) valid = false;}

31

Optimistic concurrency control – validation example

Earlier committedtransactions

Working Validation Update

T1

TvTransactionbeing validated

T2

T3

Later activetransactions

active1

active2

32

Summary

Transactions: Concurrent transactions (serial equivalence). Aborting transactions. (Nested transactions).

Locks: Two-phase locking. Strict two phase-locking. Deadlocks.

Optimistic concurrency control: Backward validation. Forward validation.