1. Transactions and Concurrency Control

2. Figure 13.2 A client’s banking transaction
Transaction T:
a.withdraw(100);
b.deposit(100);
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

3. Figure 13.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 and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

4. Figure 13.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
If a transaction aborts for any reason (self abort or server abort), it must be guaranteed that future transaction will not see the its effect either in the object or in their copies in permanent storage.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

5. Concurrency Control: the lost update problem
Transaction T :
balance = b.getBalance();
b.setBalance(balance*1.1);
a.withdraw(balance/10) U
c.withdraw(balance/10)
balance = b.getBalance();
$200
$220
$80
$280
a, b and c initially have bank account balance are: 100, 200, and 300. T transfers an amount from a to b. U transfers an amount from c to b.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

6. Concurrency Control: 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
a, b accounts start with 200 both.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

7. We say it is a serially equivalent interleaving.
Serial equivalence
If these transactions are done one at a time in some order, then the final result will be correct.
If we do not want to sacrifice the concurrency, an interleaving of the operations of transactions may lead to the same effect as if the transactions had been performed one at a time in some order.
We say it is a serially equivalent interleaving.
The use of serial equivalence is a criterion for correct concurrent execution to prevent lost updates and inconsistent retrievals.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

8. Figure 13.7 A serially equivalent interleaving of T and U
Transaction T :
balance = b.getBalance()
b.setBalance(balance*1.1)
a.withdraw(balance/10) U
c.withdraw(balance/10)
balance = b.getBalance()
$200
$220
$242
$80
$278
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

9. Conflicting Operations
When we say a pair of operations conflicts we mean that their combined effect depends on the order in which they are executed. E.g. read and write
Three ways to ensure serializability:
Locking
Timestamp ordering
Optimistic concurrency control
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

10. Figure 13.9 Read and write operation conflict rules
Operations of different
transactions
Conflict
Reason
read No
Because the effect of a pair
operations
does not depend on the order in which they are
executed
write
Yes
Because the effect of
and a
operation
depends on the order of their execution
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

11. Server can lock any object that is about to be used by a client.
Locks
A simple example of a serializing mechanism is the use of exclusive locks.
Server can lock any object that is about to be used by a client.
If another client wants to access the same object, it has to wait until the object is unlocked in the end.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

12. Figure 13.14 Transactions T and U with exclusive locks:
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
openTransaction
b.setBalance(bal*1.1)
bal = b.getBalance()
waits for T
a.withdraw(bal/10)
Lock A
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 and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

13. Figure 13.15 Lock compatibility
For one object
Lock requested
read
write
Lock already set
none OK OK
read OK
wait
write
wait
wait
An object can be read and write. From the compatibility table, we know pairs of read operations from different transactions do not conflict. So a simple exclusive lock used for both read and write reduces concurrency more than necessary. (Many readers/Single writer)
Rules;
If T has already performed a read operation, then a concurrent transaction U must not write until T commits or aborts.
If T already performed a write operation, then concurrent U must not read or write until T commits or aborts.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

14. Shared Lock and Exclusive lock
Locks must be obtained before read/write can begin
If a transaction want to read and write the same object, it can either
Obtain an X-lock before reading and unlock it immediately afterwards
Obtain an S-lock before reading, then obtain an X-lock before writing. And unlock it immediately afterwards.
Consider the following examples
A1 <- Read(X)
A1 <- A1 – k
Write(X, A1)
A2 <- Read(Y)
A2 <- A2 + k
Write(Y, A2)
A1 <- Read(X)
A1 <- A1* 1.01
Write(X, A1)
A2 <- Read(Y)
A2 <- A2 * 1.01
Write(Y, A2)
T1 (Transfer)
T2 (Dividend)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

15. Two-phase locking -- motivation
Ensure that T1 does not read/write anything that T2 read/write.
Unrealistic to check in real life
What is a sufficient condition then?
Ensure T1 does not read/write anything after releasing the lock!
 (basic) Two-phase locking

16. Two phase locking – definition
The basic two-phase locking (2PL) protocol
A transaction T must hold a lock on an item x in the appropriate mode before T accesses x.
If a conflicting lock on x is being held by another transaction, T waits.
Once T releases a lock, it cannot obtain any other lock subsequently.
Note: a transaction is divided into two phases:
A growing phase (obtaining locks)
A shrinking phase (releasing locks)
Claim : 2PL ensures conflict serializability

17. Two phase locking – Serializability
Lock-point: the point where the transaction obtains all the locks
With 2PL, a schedule is conflict equivalent to a serial schedule ordered by the lock-point of the transactions

18. 2-phase locking -- example
S-lock(X)
A1 <- Read(X)
A1 <- A1 – k
X-lock(X)
Write(X, A1)
S-lock(Y)
A2 <- Read(Y)
A2 <- A2 + k
X-lock(Y)
Write(Y, A2)
Unlock(X)
Unlock(Y)
S-lock(X)
1. S-lock(X)
A1 <- Read(X)
A1 <- A1* 1.01
X-lock(X)
Write(X, A1)
S-lock(Y)
A2 <- Read(Y)
A2 <- A2 * 1.01
X-lock(Y)
Write(Y, A2)
Unlock(Y)
Unlock(X)
T2 waits
Lock point for T1
T2 waits
Lock point for T2 T1 T2

19. Recoverability from aborts
Servers must record the effect of all committed transactions and none of the effects of the aborted transactions.
A transaction may abort by preventing it affecting other concurrent transactions if it does so.
Two problems associated with aborting transactions that may occur in the presence of serially equivalent execution of transactions:
Dirty reads
Premature writes
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

20. Figure 13.11 A dirty read when transaction T aborts:
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
Dirty reads caused by a read in one transaction U and an earlier unsuccessful write in another transaction T on the same object.
T will be rolled back and restore the original a value, thus U will have seen a value that never existed. U is committed, so cannot be undone. U performs a dirty read.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

21. Figure 13.12 Premature Write: Overwriting uncommitted values
Transaction T :
Transaction U :
a.setBalance(105)
a.setBalance(110)
$100
a.setBalance(105)
$105
a.setBalance(110)
$110
Premature write: related to the interaction between write operations on the same object belonging to different transactions.
a. If U aborts and then T commit, we got a to be correct 105.
Some systems restore value to “Before images” value for abort action, namely the value before all the writes of a transaction. a is 100, which is the before image of T’s write is the before image of U’s write.
b. Consider if U commits and then T aborts, we got wrong value of 100.
c. Similarly if T aborts then U aborts, we got 105, which is wrong and should be 100.
So to ensure correctness, write operations must be delayed until earlier transactions that updated the same object have either committed or aborted.

22. Recover problem with 2PL
X-lock(X)
A1 <- Read(X)
A1 <- A1 * 10
Write(X, A1)
Unlock(X)
Abort!
Dirty Read problem!
There is a gap between releasing locks and the decision to commit/abort
Other transactions can still access data written by a uncomitted transaction
X-lock(X)
A2 <- Read(X)
A2 <- A2 + 1
Write(X, A2)
Unlock(X)
Commit
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

23. Strict two-phase Locking Protocol
Because transaction may abort, strict execution are needed to prevent dirty reads and premature writes, which are caused by read or write to same object accessed by another earlier unsuccessful transaction that already performed an write operation.
So to prevent this problem, a transaction that needs to read or write an object must be delayed until other transactions that wrote the same object have committed or aborted.
Rule:
Any locks applied during the progress of a transaction are held until the transaction commits or aborts.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

24. Strict two-phase Locking Protocol
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

25. Figure 13.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.
A transaction with a read lock that is shared by other transactions cannot promote its read lock to a write lock, because write lock will conflict with other read locks.

26. Continues on next slide
Figure 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

27. public synchronized void release(TransID trans ){
Figure continued
public synchronized void release(TransID trans ){
holders.removeElement(trans); // remove this holder
// set locktype to none
notifyAll(); }
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

28. Optimistic Concurrency Control
Kung and Robinson [1981] identified a number of inherent disadvantages of locking and proposed an alternative optimistic approach to the serialization of transaction that avoids these drawbacks. Disadvantages of lock-based:
Lock maintenance represents an overhead that is not present in systems that do not support concurrent access to shared data. Locking sometimes are only needed for some cases with low probabilities.
The use of lock can result in deadlock. Deadlock prevention reduces concurrency severely. The use of timeout and deadlock detection is not ideal for interactive programs.
To avoid cascading aborts, locks cannot be released until the end of the transaction. This may reduce the potential for concurrency.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

29. Optimistic Concurrency Control
It is based on observation that, in most applications, the likelihood of two clients’ transactions accessing the same object is low. Transactions are allowed to proceed as though there were no possibility of conflict with other transactions until the client completes its task and issues a closeTransaction request.
When conflict arises, some transaction is generally aborted and will need to be restarted by the client.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

30. Optimistic Concurrency Control
Each transaction has the following phases:
Working phase: Each transaction has a tentative version of each of the objects that it updates. This is a copy of the most recently committed version of the object. The tentative version allows the transaction to abort with no effect on the object, either during the working phase or if it fails validation due to other conflicting transaction. Several different tentative values of the same object may coexist. In addition, two records are kept of the objects accessed within a transaction, a read set and a write set containing all objects either read or written by this transaction. Read are performed on committed version ( no dirty read can occur) and write record the new values of the object as tentative values which are invisible to other transactions.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

31. Optimistic Concurrency Control
Validation phase: When closeTransaction request is received, the transaction is validated to establish whether or not its operations on objects conflict with operations of other transaction on the same objects. If successful, then the transaction can commit. If fails, then either the current transaction or those with which it conflicts will need to be aborted.
Update phase: If a transaction is validated, all of the changes recorded in its tentative versions are made permanent. Read-only transaction can commit immediately after passing validation. Write transactions are ready to commit once the tentative versions have been recorded in permanent storage.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

32. Validation of Transactions
Validation uses the read-write conflict rules to ensure that the scheduling of a particular transaction is serially equivalent with respect to all other overlapping transactions- that is, any transactions that had not yet committed at the time this transaction started. Each transaction is assigned a number when it enters the validation phase (when the client issues a closeTransaction). Such number defines its position in time. A transaction always finishes its working phase after all transactions with lower numbers. That is, a transaction with the number Ti always precedes a transaction with number Tj if i < j.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

33. Table on page 547 Serializability of transaction T with respect to transaction TiTv 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
The validation test on transaction Tv is based on conflicts between operations in pairs of transaction Ti and Tv, for a transaction Tv to be serializable with respect to an overlapping transaction Ti, their operations must conform to the above rules.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

34. Figure 13.28 Validation of transactions
Earlier committed
transactions
Working
Validation
Update T 1 v
Transaction
being validated 2 3
Later active
active
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

35. Validation
Backward Validation: checks the transaction undergoing validation with other preceding overlapping transactions- those that entered the validation phase before it.
Forward Validation: checks the transaction undergoing validation with other later transactions, which are still active.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

36. Page 547-548 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
for (int Tid = active1; Tid <= activeN; Tid++){
if (write set of Tv intersects read set of Tid) valid = false;
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

37. Timestamp based concurrency control
Each transaction is assigned a unique timestamp value when it starts, which defines its position in the time sequence of transactions.
The basic timestamp ordering rule is based on operation conflicts and is very simple:
A transaction’s request to write an object is valid only if that object was last read and written by earlier transactions. A transaction’s request to read an object is valid only if that object was last written by an earlier transaction.
This rule assume that there is only one version of each object and restrict access to one transaction at a time.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

38. Timestamp ordering
Timestamps may be assigned from the server’s clock or a counter that is incremented whenever a timestamp value is issued.
Each object has a write timestamp and a set of tentative versions, each of which has a write timestamp associated with it; and a set of read timestamps.
The write timestamps of the committed object is earlier than that of any of its tentative versions, and the set of read timestamps can be represented by its maximum member.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

39. Timestamp ordering
Whenever a transaction’s write operation on an object is accepted, the server creates a new tentative version of the object with write timestamp set to the transaction timestamp. Whenever a read operation is accepted, the timestamp of the transaction is added to its set of read timestamps.
When a transaction is committed, the values of the tentative version become the values of the object, and the timestamps of the tentative version become the write timestamp of the corresponding object.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

40. Figure 13.29 Operation conflicts for timestamp ordering
Rule Tc Ti 1.
write
read
must not
an object that
by any
where
this requires that
≥ the maximum read timestamp of the object. 2.
written
>
this requires
> write timestamp of the committed
object. 3.
> write timestamp of the committed object.
Each request from a transaction is checked to see whether it conforms to the operation conflict rules. Conflict may occur when previous done operation from other transaction Ti is later than current transaction Tc.
It means the request is submitted too late.

41. Figure 13.30 Write operations and timestamps
(b) T3
write T
Key:
Before 2
Before T T 1 2 T i
Committed
After T T 2 3
After T T T 1 2 3 T i
Time
Time
Tentative
object produced
by transaction Ti
(c) T3
write
(d) T3
write
(with write timestamp Ti)
Transaction T T
T1<T2<T3<T4
Before 1 4 T
aborts
Before 4
After T T T
After T 1 3 4 4
Time
Time
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

42. Page 551 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

43. Page 551 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

44. Figure 13.31 Read operations and timestamps
(b) T3 read
(a) T3 read
Key:
read
read T T T 2
proceeds 2 4
proceeds T i
Selected
Committed
Selected
Time
Time T
(d) T3 read i
(c) T3 read
Tentative
Transaction
read waits
object produced
by transaction Ti
(with write timestamp Ti)
T1 < T2 < T3 < T4 T T T 1 2 4
aborts
Selected
Time
Time
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

45. S<T<U Exercise Timestamps and versions of objects T U A B C RTS
WTS {} S
openTransaction
bal = b.getBalance()
b.setBalance(bal*1.1)
a.withdraw(bal/10)
commit
c.withdraw(bal/10)
S<T<U
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

46. Figure 13.32 Timestamps in transactions T and U
Timestamps and versions of objects T U A B C
RTS
WTS {} S
openTransaction
bal = b.getBalance()
{T}
b.setBalance(bal*1.1)
wait for T
a.withdraw(bal/10)
commit
c.withdraw(bal/10)
S, U
T, U
S, T
{U}
S<T<U
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005

47. Distributed Transactions
Begin transaction BookTrip
book a plane from Qantas
book hotel from Hilton
book rental car from Hertz
End transaction BookTrip
The Two Phase Commit Protocol is a classic solution for atomicity and
consistency.
Transactions

48. Interacting with a coordinator
Transaction T tid = openTransaction(); a.withdraw(tid,100); b.deposit(tid,100); c.withdraw(tid,200); b.deposit(tid,200); closeTransaction(tid) or abortTransaction(tid)
Coordinator Interface:
openTransaction() -> transID
closeTransaction(transID) ->
commit or abort
abortTransaction(TransID)
Think about atomicity and
consistency.
Transactions 48
Transactions

49. Client Talks to a Coordinator
Different servers
Any server
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
openTrans
Unique Transaction ID
TID
BookRentalCar Participant
Recoverable objects needed
to rent a car.
BookTrip Client
TID = openTransaction()
Transactions

50. Client Uses Services BookPlane Participant BookTrip Coordinator
Different servers
Any server
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
Call + TID
BookRentalCar Participant
Recoverable objects needed
to rent a car.
BookTrip Client
plane.bookFlight(111,”Seat32A”,TID)
Transactions

51. What is a Recoverable Object?
Different servers
BookPlane Participant
Recoverable objects needed
to book a plane
BookHotel Participant
A recoverable object follows the
Golden Rule of Recoverability:
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
Never modify the only copy.
Recoverable objects needed
to rent a car.
The servers make changes
to local copies of locked
resources until a commit
or rollback.
Transactions

52. Participants Talk to Coordinator
The participant only
calls join if it has not
already done so.
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
join(TID,ref to participant)
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
The participant knows where the
coordinator is because that
information can be included in
the TID (eg. an IP address.)
The coordinator now has a pointer to the
participant.

53. Suppose All Goes Well (1)
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
Recoverable objects needed
to rent a car.
OK returned
OK returned
OK returned
Transactions

54. Suppose All Goes Well (2)
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Coordinator begins
2PC and this results in
a GLOBAL COMMIT
sent to each participant.
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
Recoverable objects needed
to rent a car.
BookTrip Client
OK returned
OK returned
OK returned
CloseTransaction(TID) Called

55. This Time No Cars Available (1)
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
Recoverable objects needed
to rent a car.
BookTrip Client
OK returned
OK returned
NO CARS AVAIL
abortTransaction(TID) called

56. This Time No Cars Available (2)
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Coordinator sends a
GLOBAL_ABORT to all
particpants
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
Recoverable objects needed
to rent a car.
BookTrip Client
OK returned
OK returned
NO CARS AVAIL
abortTransaction(TID) called

57. This Time No Cars Available (3)
Different servers
BookPlane Participant
BookTrip
Coordinator
ROLLBACK CHANGES
BookHotel Participant
abortTransaction
ROLLBACK CHANGES
Each participant
Gets a GLOBAL_ABORT
BookRentalCar Participant
ROLLBACK CHANGES
BookTrip Client
OK returned
OK returned
NO CARS AVAIL
abortTransaction(TID)

58. BookPlane Server Crashes After Returning ‘OK’ (1)
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
BookTrip Client
Recoverable objects needed
to rent a car.
OK returned
OK returned
OK returned
Transactions

59. BookPlane Server Crashes After Returning ‘OK’ (2)
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
Coordinator excutes 2PC:
Ask everyone to vote.
No news from the BookPlane
Participant so multicast a
GLOBAL ABORT
Recoverable objects needed
to book a hotel.
BookRentalCar Participant
Recoverable objects needed
to rent a car.
BookTrip Client
OK returned
OK returned
OK returned
CloseTransaction(TID) Called

60. BookPlane Server Crashes after returning ‘OK’ (3)
Different servers
BookPlane Participant
BookTrip
Coordinator
Recoverable objects needed
to book a plane
BookHotel Participant
GLOBAl ABORT
ROLLBACK
BookRentalCar Participant
ROLLBACK
BookTrip Client
OK returned
OK returned
ROLLBACK
OK returned
CloseTransaction(TID) Called

61. Two-Phase Commit Protocol
BookPlane
Vote_Request
BookTrip
Coordinator
Vote_Commit
Vote Request
BookHotel
Vote Commit
Vote Request
BookRentalCar
Phase 1 BookTrip coordinator
sends a Vote_Request to each
process. Each process returns
a Vote_Commit or Vote_Abort.
Vote Commit
Transactions

62. Two-Phase Commit Protocol
BookPlane
Global Commit
BookTrip
Coordinator
ACK
BookHotel
Global Commit
ACK
Global Commit
BookRentalCar
Phase 2 BookTrip coordinator
checks the votes. If every process
votes to commit then so will the coordinator.
In that case, it will send a Global_Commit to each process.
If any process votes to abort the coordinator sends a GLOBAL_ABORT.
Each process waits for a Global_Commit message before committing its part of the
transaction.
ACK

63. 2PC Finite State Machine from Tanenbaum
BookTrip Coordinator
Participant
State has already been saved to permanent
storage.
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
Vote-request
Vote-abort
Ready
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

64. 2PC Blocks in Three Places
If waiting too long for a Vote-Request
send a Vote-Abort
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
Vote-request
Vote-abort
Ready
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

65. 2PC Blocks in Three Places
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
If waiting too long
After Vote-request
Send a Global-Abort
Ready
Vote-request
Vote-abort
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

66. 2PC Blocks in Three Places
If waiting too long we can’t simply abort! We must wait
until the coordinator recovers. We might also make queries
on other participants.
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
Vote-request
Vote-abort
Ready
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

67. 2PC Blocks in Three Places
If this process learns that another has committed then this
process is free to commit. The coordinator must have sent out
a Global-commit that did not get to this process.
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
Vote-request
Vote-abort
Ready
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

68. 2PC Blocks in Three Places
If this process learns that another has aborted then it too
is free to abort.
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
Vote-request
Vote-abort
Ready
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

69. 2PC Blocks in Three Places
Suppose this process learns that another
process is still in its init state. The coordinator must have
crashed while multicasting the Vote-request. It’s safe for
this process (and the queried process) to abort.
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
Vote-request
Vote-abort
Ready
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

70. 2PC Blocks in Three Places
Tricky case: If the queried processes are all still in their ready
state what do we know? We have to block and wait until the
Coordinator recovers.
Init
Init
Vote-request
Vote-commit
Commit
Vote-request
Vote-request
Vote-abort
Ready
wait
Vote-abort
Global-abort
Vote-commit
Global-commit
Global-commit
ACK
Global-abort
ACK
Commit
Abort
Commit
Abort
Transactions

71. The transactions T and U are defined as follows:
Exercises
A server manages the objects a1, a2, ... an. The server provides two operations for its clients:
read (i) returns the value of ai;
write(i, Value) assigns Value to ai.
The transactions T and U are defined as follows:
T: x = read(j); y = read (i); write(j, 44); write(i, 33);
U: x = read(k); write(i, 55); y = read (j); write(k, 66).
Give three serially equivalent interleavings of the transactions T and U.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2005