Drawbacks of locking

• Lock maintenance represents an overhead that is not

present in systems that do not support concurrent
access to shared data.

• The use of locks can result in deadlock. Deadlock

prevention reduces concurrency severely.

• To avoid cascading aborts, locks cannot be released

until the end of the transaction. This may reduce
significantly the potential for concurrency.

1
 Optimistic concurrency control
• Optimistic concurrency control (OCC) is
based on the assumption that two
transactions won’t occur at the same time

• OCC is generally used in environments

with low data contention
 OCC phases
• Begin
• Reading phase
• Validation phase
• Writing phase
 OCC phases
• Begin:
Record a timestamp marking the
transaction's beginning

• Reading phase:
Read database values to a copy of the
transaction which is not yet bound to the
object. Several different transactions of
this type may coexist
 OCC phases
• Validate phase:
Controls if the transaction conflicts with
another transaction on the same object

• Writing phase:
– Committed: If there is no conflict, make all
changes part of the official state of the database
– Aborted: If there is a conflict, resolve it, typically
by aborting the transaction, although other
resolution schemes are possible
95-702 Transactions 6
Validation rules
95-702 Transactions 8
OCC merits and demerits

9
 Does this allow for any
concurrency?
In reality, the
Transaction T1 Transaction T2 coordinator
would do the
locking.

Lock_Item(x) Lock_Item(y)
T1 uses x T2 uses y
Unlock_Item(x) Unlock_Item(y)
If x differs from y these two transactions proceed concurrently.
If both want to use x, one waits until the other completes.

10
Distributed Transactions (More than
one server)
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.

11
95-702 Transactions 12
 Interacting with a coordinator
Transaction T
Coordinator Interface:
tid = openTransaction();
openTransaction() -> transID
a.withdraw(tid,100); closeTransaction(transID) ->
commit or abort
b.deposit(tid,100); abortTransaction(TransID)

c.withdraw(tid,200);
d.deposit(tid,200);
closeTransaction(tid) or
Think about atomicity and
abortTransaction(tid) consistency.
13
 Client Talks to a Coordinator
Different servers
Any server
BookPlane Participant
BookTrip Recoverable objects needed
Coordinator to book a plane
BookHotel Participant
Recoverable objects needed
openTrans Unique Transaction ID to book a hotel.
TID
BookRentalCar Participant
Recoverable objects needed
BookTrip Client to rent a car.
TID = openTransaction()

14
95-702 Transactions 15
95-702 Transactions 16
95-702 Transactions 17
 Two-Phase Commit Protocol
BookPlane

Vote_Request
BookTrip Vote_Commit
Coordinator
Vote Request
BookHotel
Vote Commit

Vote Request
BookRentalCar
Vote Commit
Phase 1 BookTrip coordinator
sends a Vote_Request to each
process. Each process returns
a Vote_Commit or Vote_Abort.
18
 Two-Phase Commit Protocol

BookPlane

Global Commit
BookTrip ACK
Coordinator BookHotel
Global Commit
ACK
Global Commit

Phase 2 BookTrip coordinator ACK BookRentalCar

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
19 its part of the
transaction.
 2PC Finite State Machine from
Tanenbaum
BookTrip Coordinator Participant
State has already been saved to permanent
storage.
Init
Init
Vote-request Vote-request
Commit
----------------- -----------------
----------
Vote-abort Vote-commit
Vote-request
Ready
wait
Vote-abort Vote-commit Global-commit
-------------- ---------------- -------------------
Global-abort Global-commit ACK
Global-abort
----------------
Abort Commit
ACK
Commit
Abort
20
 2PC Blocks in Three Places
If waiting too long for a Vote-Request
send a Vote-Abort

Init
Init
Vote-request Vote-request
Commit
----------------- -----------------
----------
Vote-abort Vote-commit
Vote-request
Ready
wait
Vote-abort Vote-commit Global-commit
-------------- ---------------- -------------------
Global-abort Global-commit ACK
Global-abort
----------------
Abort Commit
ACK
Commit
Abort
21
 2PC Blocks in Three Places

Init
Init
Vote-request
Commit If waiting too long
-----------------
---------- After Vote-request
Vote-commit
Vote-request Send a Global-Abort
Vote-request Ready
wait -----------------
Vote-abort Vote-commit Vote-abort Global-commit
-------------- ---------------- -------------------
Global-abort Global-commit ACK
Global-abort
----------------
Abort Commit
ACK
Commit
Abort
22
 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
Commit Vote-request -----------------
---------- ----------------- Vote-commit
Vote-request Vote-abort
Ready
wait
Vote-abort Vote-commit Global-commit
-------------- ---------------- -------------------
Global-abort Global-commit ACK
Global-abort
----------------
Abort Commit
ACK
Commit
Abort
23
 Example
Transfer $1000
From A:$3000
To B:$2000
client

Bank A Bank B

• Clients want all-or-nothing transactions

– Transfer either happens or not at all
 Strawman solution
Transfer $1000 Transaction
From A:$3000
To B:$2000
coordinator
client

Bank A Bank B
 Strawman solution
transaction bank A bank B
client coordinator
start

A=A-1000
done B=B+1000

• What can go wrong?

– A does not have enough money
– B’s account no longer exists
– B has crashed
– Coordinator crashes
 Reasoning about correctness

• TC, A, B each has a notion of committing

• Correctness:
– If one commits, no one aborts
– If one aborts, no one commits
• Performance:
– If no failures, A and B can commit, then
commit
– If failures happen, find out outcome soon
 Correctness first
transaction bank A bank B
client coordinator
start
prepare
prepare
rA
rB
outcome
result outcome

If rA==yes && rB==yes

outcome = “commit”
B commits upon
else
receiving “commit”
outcome = “abort”