1. CSE 486/586 Distributed Systems Concurrency Control --- 2
Steve Ko
Computer Sciences and Engineering
University at Buffalo

2. Recap Question: How to support transactions?
Multiple transactions share data.
Complete serialization is correct
Use locks to serialize transactions.
But performance and abort are two issues.
For performance: Interleaving transactions

3. Handling Abort()
For serialized transactions, abort() can be done if we only store temporary results in memory.
When commit() is invoked at the end of each transaction, we write it to permanent storage, making the final outcomes visible to other transactions.
But for interleaving, intermediate results are used
Transaction T Transaction T2
begin() begin()
balance = b.getBalance() bal = b.getBalance()
b.setBalance = (balance*1.1) b.setBalance(bal*1.1)
a.withdraw(balance* 0.1) c.withdraw(bal*0.1)
commit() commit() a:
100 b:
200 c:
300

4. Handling Abort() with Interleaving
What can go wrong?
Transaction V :
a.withdraw(100);
b.deposit(100) W
aBranch.branchTotal()
$100
$300
total = a.getBalance()
total = total+b.getBalance()
$400
total = total+c.getBalance()
...
A, after withdrawal it’s $100.
B, before deposit it’s $300.

5. Strict Executions of Transactions
Problem of interleaving for abort()
Intermediate state visible to other transactions, i.e., other transactions could have used some results already.
For abort(), transactions should delay both their read and write operations on an object (until commit time)
Until all transactions that previously wrote that object have either committed or aborted
This way, we avoid making intermediate states visible before commit, just in case we need to abort.
This is called strict executions.
This further restricts which interleavings of transactions are allowed.
Thus, correctness criteria for transactions:
Serial equivalence
Strict execution

6. Story Thus Far Question: How to support transactions?
With multiple transactions sharing data
First strategy: Complete serialization
One transaction at a time with one big lock
Correct, but at the cost of performance
How to improve performance?
Let’s see if we can interleave different transactions.
Problem: Not all interleavings produce a correct outcome
Serial equivalence & strict execution must be met.
Now, how do we meet the requirements?
Overall strategy: using more and more fine-grained locking
No silver bullet. Fine-grained locks have their own implications.

7. Transaction T1 Transaction T2
Using Exclusive Locks
Exclusive Locks (Avoiding One Big Lock)
Transaction T Transaction T2
begin()
balance = b.getBalance() begin()
balance = b.getBalance()
b.setBalance = (balance*1.1)
a.withdraw(balance* 0.1)
commit()
b.setBalance = (balance*1.1) c.withdraw(balance*0.1)
Lock B
WAIT on B …
Lock A …
UnLock B
Lock B
UnLock A
Lock C
UnLock B
UnLock C

8. How to Acquire/Release Locks
Can’t do it naively
Serially equivalent?
Strict execution?
Transaction T Transaction T2
x= a.read()
a.write(20) y = b.read()
b.write(30)
b.write(x)
z = a.read()
Lock A
Lock B
UnLock A
UnLock B
Lock B
Lock A
UnLock B
UnLock A

9. Using Exclusive Locks Two phase locking Strict two phase locking
To satisfy serial equivalence
First phase (growing phase): new locks are acquired
Second phase (shrinking phase): locks are only released
A transaction is not allowed to acquire any new lock, once it has released any one lock
Strict two phase locking
To further satisfy strict execution, i.e., to handle abort() & failures
Locks are only released at the end of the transaction, either at commit() or abort(), i.e., the second phase is only executed at commit() or abort().
The first example shown before does both. But the second example does neither.
Better than one big lock, but still losing the interleaving benefits

10. CSE 486/586 Administrivia
Midterm re-grading: This Friday 4 pm – 6 pm during my office hours

11. Can We Do Better? What we saw was “exclusive” locks.
Non-exclusive locks: break a lock into a read lock and a write lock
Allows more concurrency
Read locks can be shared (no harm to share)
Write locks should be exclusive

12. non-exclusive lock compatibility
Non-Exclusive Locks
non-exclusive lock compatibility
Lock already Lock requested
set read write
none OK OK
read OK WAIT
write WAIT WAIT
A read lock is promoted to a write lock when the transaction needs write access to the same object.
A read lock shared with other transactions’ read lock(s) cannot be promoted. Transaction waits for other read locks to be released.
Cannot demote a write lock to read lock during transaction – violates the strict 2P principle

13. Example: Non-Exclusive Locks
Transaction T Transaction T2
begin()
balance = b.getBalance() begin()
… balance = b.getBalance()
… b.setBalance =balance*1.1
Commit
R-Lock B
R-Lock B
Cannot Promote lock on B, Wait
Promote lock on B …

14. Cannot Promote lock on B, Wait Cannot Promote lock on B, Wait
2PL: a Problem
What happens in the example below?
Transaction T Transaction T2
begin()
balance = b.getBalance() begin()
balance = b.getBalance()
b.setBalance =balance*1.1
b.setBalance=balance*1.1
R-Lock B
R-Lock B
Cannot Promote lock on B, Wait
Cannot Promote lock on B, Wait … …

15. Deadlock Conditions Necessary conditions W ... T V U T ... U
Non-sharable resources (locked objects)
No lock preemption
Hold & wait or circular wait
Held by
Held by
Wait for
Held by
Wait for W
...
Wait for A A T V U T B B
... U
Wait for
Held by
Wait for
Held by
Wait for
Held by
Hold & Wait
Circular Wait

16. Preventing Deadlocks Acquiring all locks at once
Acquiring locks in a predefined order
Not always practical:
Transactions might not know which locks they will need in the future
One strategy: timeout
If we design each transaction to be short and fast, then we can abort() after some period of time.

17. Even More: Two-Version Locking
Three types of locks: read lock, write lock, commit lock
Acquiring a commit lock only happens at commit().
Transaction cannot get a read or write lock if there is a commit lock
Read and write (from different transactions) can go concurrently.
What can go wrong with this?
Read-write conflicts (but no write-write conflict)
lock compatibility Lock already Lock requested set read write commit none OK OK OK read OK OK WAIT write OK WAIT WAIT commit WAIT WAIT WAIT
Read-write conflicts are possible, so writes get delayed.
Write-write conflicts are not possible, so no need to worry.

18. Two-Version Locking Allow writing tentative versions of objects
Letting other transactions read from the previously committed version
Optimistic writes: this works well if there’s little chance of read-write conflicts.
At commit(),
Promote all the write locks of the transaction into commit locks
If any objects have outstanding read locks, transaction must wait until the transactions that set these locks have completed and locks are released

19. Two-Version Locking
This allows for more concurrency than read-write locks.
Writing transactions risk waiting when commit
Read operations wait only if another transaction is committing the same object
Read operations of one transaction can cause a delay in the committing of other transactions

20. Summary Strict Execution Strict execution with exclusive locks
Delaying both their read and write operations on an object until all transactions that previously wrote that object have either committed or aborted
Strict execution with exclusive locks
Strict 2PL
Increasing concurrency
Non-exclusive locks
Two-version locks
Etc.

21. Acknowledgements
These slides contain material developed and copyrighted by Indranil Gupta (UIUC).