Slides for Chapter 16:

Transactions and Concurrency

Control

From Coulouris, Dollimore, Kindberg and Blair

Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
Figure 16.1
Operations of the Account interface

deposit(amount)
deposit amount in the account
withdraw(amount)
withdraw amount from the account
getBalance() -> amount
return the balance of the account
setBalance(amount)
set the balance of the account to amount

Operations of the Branch interface

create(name) -> account
create a new account with a given name
lookUp(name) -> account
return a reference to the account with the given name
branchTotal() -> amount
return the total of all the balances at the branch

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.2
A client’s banking transaction

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

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.3
Operations in Coordinator interface

openTransaction() -> trans;

starts a new transaction and delivers a unique TID trans. This
identifier will be used in the other operations in the transaction.

closeTransaction(trans) -> (commit, abort);

ends a transaction: a commit return value indicates that the
transaction has committed; an abort return value indicates that it
has aborted.

abortTransaction(trans);
aborts the transaction.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.4
Transaction life histories

Successful Aborted by client Aborted by server

openTransaction openTransaction openTransaction

operation operation operation
operation operation operation
server aborts
transaction
operation operation operation ERROR
reported to client
closeTransaction abortTransaction

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.5
The lost update problem

Transaction T : Transaction U:
balance = b.getBalance(); balance = b.getBalance();
b.setBalance(balance*1.1); b.setBalance(balance*1.1);
a.withdraw(balance/10) 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

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.6
The inconsistent retrievals problem

Transaction V: Transaction W:
a.withdraw(100)
aBranch.branchTotal()
b.deposit(100)

a.withdraw(100); $100
total = a.getBalance() $100
total = total+b.getBalance() $300
total = total+c.getBalance()
b.deposit(100) $300

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.7
A serially equivalent interleaving of T and U

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

balance = b.getBalance() $200

b.setBalance(balance*1.1) $220
balance = b.getBalance() $220
b.setBalance(balance*1.1) $242
a.withdraw(balance/10) $80
c.withdraw(balance/10) $278

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.8
A serially equivalent interleaving of V and W

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

a.withdraw(100); $100
b.deposit(100) $300
total = a.getBalance() $100
total = total+b.getBalance() $400
total = total+c.getBalance()
...

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.9
Read and write operation conflict rules

Operations of different Conflict Reason

transactions
read read No Because the effect of a pair of read operations
does not depend on the order in which they are
executed
read write Yes Because the effect of a read and a write operation
depends on the order of their execution
write write Yes Because the effect of a pair of write operations
depends on the order of their execution

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.10
A non-serially equivalent 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)

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.11
A dirty read when transaction T aborts

Transaction T: Transaction U:
a.getBalance() a.getBalance()
a.setBalance(balance + 10) 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

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.12
Overwriting uncommitted values

Transaction T: Transaction U:
a.setBalance(105) a.setBalance(110)
$100
a.setBalance(105) $105
a.setBalance(110) $110

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.13
Nested transactions

T : top-level transaction
T1 = openSubTransaction T2 = openSubTransaction
commit
T1 : T2 :
openSubTransaction openSubTransaction openSubTransaction
prov. commit abort
T11 : T12 : T21 :
openSubTransaction
prov. commit prov. commit prov. commit
T211 :

prov.commit

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.14
Transactions T and U with exclusive locks

Transaction T: Transaction U:
balance = b.getBalance() balance = b.getBalance()
b.setBalance(bal*1.1) b.setBalance(bal*1.1)
a.withdraw(bal/10) c.withdraw(bal/10)
Operations Locks Operations Locks
openTransaction
bal = b.getBalance() lock B
b.setBalance(bal*1.1) openTransaction
a.withdraw(bal/10) lock A bal = b.getBalance() waits for T’s
lock on B
closeTransaction unlock A, B
lock B
b.setBalance(bal*1.1)
c.withdraw(bal/10) lock C
closeTransaction unlock B, C

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.15
Lock compatibility

For one object Lock requested

read write
Lock already set none OK OK
read OK wait
write wait wait

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.16
Use of 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.

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.19
Deadlock with write locks

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

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.20
The wait-for graph for Figure 16.19

Held by Waits for

A
T U T U

Waits for B
Held by

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.21
A cycle in a wait-for graph

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.22
Another wait-for graph

V T
Held by W

T Held by Held by
C
U
Held by B
U
W V
Waits for

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.23
Resolution of the deadlock in Figure 15.19

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 T
a.withdraw(200); write locks A
unlock A, B

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.24
Lock compatibility (read, write and commit locks)

For one object Lock to be set

read write commit
Lock already set none OK OK OK
read OK OK wait
write OK wait
commit wait wait

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.28
Validation of transactions

Working Validation Update

T1
Earlier committed
transactions
T2

T3

Transaction
being validated Tv

active
1
Later active
active
transactions 2

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.30
Write operations and timestamps

(a) T3 write (b) T3 write

T2 T1 T2 Key:
Before Before Ti

Committed
After T2 T3 After T1 T2 T3
Ti
Time Time
Tentative

object produced
(c) T3 write (d) T3 write by transaction Ti
Transaction (with write timestamp Ti)
T1 T4 T4 aborts T1<T2<T3<T4
Before Before

After T1 T3 T4 After T4

Time Time

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012
Figure 16.31
Read operations and timestamps

(b) T3 read
(a) T3 read
Key:

read read
T2 T2 T4 proceeds
proceeds Ti

Selected Committed
Selected Time
Time
Ti
(c) T3 read (d) T3 read
Tentative

read waits Transaction object produced

T1 T2 T4 aborts by transaction Ti
(with write timestamp Ti)
T1 < T2 < T3 < T4
Selected
Time Time

Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
© Pearson Education 2012