This document discusses concurrency control techniques for databases, including pessimistic and optimistic concurrency control. It describes locking techniques used for synchronization, including binary locks, certify locks, and two-phase locking to ensure serializability. It also discusses problems that can occur with locking such as deadlocks and starvation.

1. 3. Concurrency Control
▪ Pessimistic concurrency control
Check before a database operation is executed by locking data
items before they are read and written or checking timestamps.
▪ Optimistic concurrency control
Transactions are allowed to proceed freely in the private work
space before committing it is validated.
Once validated, the objects may be updated in updating phase.

2. 3. Concurrency Control
▪ Locking techniques for concurrency control
☞ Locking data items is one of the main techniques used for controlling
the concurrent execution of transactions.
☞ A lock describes the status of the data item with respect to possible
operations that can be applied to that item.
- Used for synchronizing the access by concurrent transactions to the
database items.
☞ When an object is locked by another transaction
- The requesting transaction must wait.

3. 3. Concurrency Control
▪ Types of Locks
1) Binary locks
☞ Only two states:
locked (lock_item(x) operation)
unlocked (unlock_item(x) operation) (or 1 and 0, for simplicity)
☞ A distinct lock is associated with each database item x.
If the value of the lock on x is 1, item x cannot be accessed by a
database operation that requests the item.
If the value of the lock on x is 0, the item can be accessed when
requested. We refer to the current value (or state) of the lock
associated with item x as lock(x).

4. 3. Concurrency Control
▪ Types of Locks
1) Binary locks
☞ Two operations, lock_ and unlock_item are used with binary locking.
Lock_item(x):
- requests access to an item x by first issuing a lock_item(x) operation.
If lock(x) = 1, the transaction is forced to wait.
If lock(x) = 0, it is set to 1 and the transaction is allowed to access item x.
Unlock_item (x):
- when using the item, it issues an unlock_item(x) operation.
- which sets lock(x) to 0 (unlocks the item) so that x may be accessed by
other transactions.
☞ Hence, a binary lock enforces mutual exclusion on the data item ;
= i.e., at a time only one transaction can hold a lock.

5. 3. Concurrency Control
▪ Types of Lock
2) Certify lock
☞ Used to improving performance of locking protocols.
3) Conversion of locks
☞ A transaction that already holds a lock on item x is allowed under
certain conditions to convert the lock from one locked state to another.
Ex) it is possible for a transaction t to issue a read_lock(x) and then
later on to upgrade the lock by issuing a write_lock(x) operation.
• Upgrading:
• Downgrading:

6. 3. Concurrency Control
▪ Locks don’t guarantee serialisability: lost update
♪. Schedule 1: t1 followed by t2
♪. Schedule 2: t2 followed by t1
x=50, y=80
x=70, y=50

7. 3. Concurrency Control
▪ Non-serialisable schedule s that uses locks
Let x=20, y=30.
Result of s
x=50, y=50.

8. 3. Concurrency Control
▪ Ensuring serialisability: two-phase locking
• All locking operations (read_lock, write_lock) precede the first unlock
operation in the transactions.
• Two phases:
Expanding phase:
- new locks on items can be acquired but none can be released.
Shrinking phase:
- existing locks can be released but no new ones can be acquired.

9. 3. Concurrency Control
▪ Ensuring serialisability: two-phase locking
• All locking operations (read_lock, write_lock) precede the first unlock
operation in the transactions.
• Two phases:
Expanding phase:
- new locks on items can be acquired but none can be released.
Shrinking phase:
- existing locks can be released but no new ones can be acquired.

10. 3. Concurrency Control
▪ Two-phase locking(TPL)
• Basic 2pl
When a transaction releases a lock, it may not request another lock.

11. 3. Concurrency Control
▪ Locking problems: deadlock
Each of two or more transactions is waiting for the other to release an item.
Also called a deadly embrace.
To handle a deadlock one of t3 or t4 must be rolled back and its locks
released.
The potential for deadlock exists in most locking protocols.
Deadlocks are a necessary evil.

12. 3. Concurrency Control
▪ Starvation
If concurrency control manager is badly designed.
Ex)
A transaction may be waiting for an x-lock on an item, while a sequence of
other transactions request and are granted an s-lock on the same item.
The same transaction is repeatedly rolled back due to deadlocks.
Concurrency control manager can be designed to prevent starvation.