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

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.2
A clients banking transaction

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

Instructors 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.

Instructors 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

Instructors 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

Instructors 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

Instructors 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

Instructors 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()
...

Instructors 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

Instructors 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)

Instructors 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

Instructors 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

Instructors 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

Instructors 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 Ts
lock on B
closeTransaction unlock A, B
lock B
b.setBalance(bal*1.1)
c.withdraw(bal/10) lock C
closeTransaction unlock B, C

Instructors 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

Instructors 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.

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.17
Lock class

public class Lock {

private Object object; // the object being protected by the lock
private Vector holders; // the TIDs of current holders
private LockType lockType; // the current type
public synchronized void acquire(TransID trans, LockType aLockType ){
while(/*another transaction holds the lock in conflicing mode*/) {
try {
wait();
}catch ( InterruptedException e){/*...*/ }
}
if(holders.isEmpty()) { // no TIDs hold lock
holders.addElement(trans);
lockType = aLockType;
} else if(/*another transaction holds the lock, share it*/ ) ){
if(/* this transaction not a holder*/) holders.addElement(trans);
} else if (/* this transaction is a holder but needs a more exclusive lock*/)
lockType.promote();
}
}
Continues on next slide
Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.17
continued

public synchronized void release(TransID trans ){

holders.removeElement(trans); // remove this holder
// set locktype to none
notifyAll();
}
}

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.18
LockManager class

public class LockManager {

private Hashtable theLocks;

public void setLock(Object object, TransID trans, LockType lockType){

Lock foundLock;
synchronized(this){
// find the lock associated with object
// if there isnt one, create it and add to the hashtable
}
foundLock.acquire(trans, lockType);
}
// synchronize this one because we want to remove all entries
public synchronized void unLock(TransID trans) {
Enumeration e = theLocks.elements();
while(e.hasMoreElements()){
Lock aLock = (Lock)(e.nextElement());
if(/* trans is a holder of this lock*/ ) aLock.release(trans);
}
}
}
Instructors 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 Us
a.withdraw(200); waits for Ts
lock on B
lock on A

Instructors 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

Instructors 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

Instructors 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

Instructors 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 Us a.withdraw(200); waits for Ts
lock on B lock on A
(timeout elapses)
Ts lock on A becomes vulnerable,
unlock A, abort T
a.withdraw(200); write locks A
unlock A, B

Instructors 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

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.25
Lock hierarchy for the banking example

Branch

A B C Account

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.26
Lock hierarchy for a diary

Week

Monday Tuesday Wednesday Thursday Friday

time slots
9:0010:00 10:0011:00 11:0012:00 12:0013:00 13:0014:00 14:0015:00 15:0016:00

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.27
Lock compatibility table for hierarchic locks

For one object Lock to be set

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

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Table on page 708
Serializability of transaction T with respect to transaction Ti

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 must not write objects written by Ti

Instructors 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

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Page 709-710
Validation of Transactions

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;
}

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.29
Operation conflicts for timestamp ordering

Rule Tc Ti
1. write read Tc must not write an object that has been read by any Ti where Ti >Tc
this requires that Tc the maximum read timestamp of the object.

2. write write Tc must not write an object that has been written by any Ti where Ti >Tc
this requires that Tc > write timestamp of the committed object.

3. read write Tc must not read an object that has been written by any Ti whereTi >Tc
this requires that Tc > write timestamp of the committed object.

Instructors 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

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Page 713
Timestamp ordering write rule

if (Tc maximum read timestamp on D &&

Tc > write timestamp on committed version of D)
perform write operation on tentative version of D with write timestamp Tc
else /* write is too late */
Abort transaction Tc

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Page 714
Timestamp ordering read rule

if ( Tc > write timestamp on committed version of D) {

let Dselected be the version of D with the maximum write timestamp Tc
if (Dselected is committed)
perform read operation on the version Dselected
else
Wait until the transaction that made version Dselected commits or aborts
then reapply the read rule
} else
Abort transaction Tc

Instructors 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

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.32
Timestamps in transactions T and U

Timestamps and versions of objects

T U A B C
RTS WTS RTS WTS RTS WTS
{} S {} S {} S
openTransaction
bal = b.getBalance() {T}
openTransaction
b.setBalance(bal*1.1) S, T
bal = b.getBalance()
wait for T
a.withdraw(bal/10) S, T
commit T T
bal = b.getBalance() {U}
b.setBalance(bal*1.1) T, U
c.withdraw(bal/10) S, U

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012
Figure 16.33
Late write operation would invalidate a read

T3 read; T3 write; T5 read; T4 write;

T2 T3
T1
T3 T5

Time
T1 < T2 < T3 < T4 < T5

Key: Ti Ti object produced by transaction Ti

Tk Tk (with write timestamp Ti and read
timestamp Tk)
Committed Tentative

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
Pearson Education 2012