1. ENFORCING SERIALIZABILITY BY LOCKS
SECTION 18.3
ENFORCING SERIALIZABILITY BY LOCKS

2. INTRODUCTION Enforcing serializability by locks Locks
Locking scheduler
Two phase locking 2

3. Locks It works like as follows : A request is sent from transaction
Scheduler checks in the lock table to make sure that they are serializable
Generates a serializable schedule of actions. 3

4. Consistency of transactions
Actions and locks must relate each other
Transactions can only read or write an element if has been granted a lock and has not yet released the lock.
The locked element must be later unlocked by the transaction.
Legality of schedules
No two transactions can acquire the lock on same element without the prior one releasing it. 4

5. Locking Scheduler
Grants lock requests only if it is in a legal schedule.
Lock table stores the information about current locks on the elements.
A legal schedule of consistent transactions but unfortunately it is not a serializable. (because it has different end results). 5

6. Locking schedule (contd.)
The locking scheduler delays requests that would result in an illegal schedule. 6

7. Two-phase locking
Guarantees a legal schedule of consistent transactions is conflict-serializable.
All lock requests proceed all unlock requests.
The growing phase:
Obtain all the locks and no unlocks allowed.
The shrinking phase:
Release all the locks and no locks allowed. 7

8. Working of Two-Phase locking
Assures serializability.
Two protocols for 2PL:
Strict two phase locking : Transaction holds all its exclusive locks till commit / abort.
Rigorous two phase locking : Transaction holds all locks till commit / abort. 8

9. Failure of 2PL.
2PL fails to provide security against deadlocks. 9