Locks

Locks It is the job of the scheduler to ensure that the requested actions in transactions can not lead to an inconsistent database state. A scheduler can use locks to enforce this behavior. A locking scheduler enforces conflict-serializability, which is a more stringent condition then correctness or even serializability. Transactions must request and release locks, in addition to reading and writing database elements.

Rules for Locks Consistency of Transactions: Legality of Schedules: A transaction can only read or write an element if it previously was granted a lock on that element (and hasn't yet released the lock) If a transaction locks an element, it must later unlock that element Legality of Schedules: No two transactions may lock the same element without one having first released the lock

Additional notation for locks: li(X): Transaction Ti requests a lock on database element X ui(X): Transaction Ti releases (unlocks) a lock on database element X Rules using new notation: Consistency of Transactions: Whenever a transaction Ti has an action ri(X) or wi(X), then there is a previous action li(X) with no intervening ui(X), and there is a subsequent ui(X). Legality of Schedules: If there are actions li(X) followed by lj(X) in a schedule, then somewhere between these actions there must be an action ui(X).

Is this schedule legal? Yes No Depends ??? l1(A); r1(A); u1(A); l2(A); l2(B); r2(A); w2(B); w2(B); u2(B); l3(B); w3(B); u3(B); u2(A); Yes No Depends ???

Transaction 1 Transaction 2 A B 25 r2(A) A *= 2 w2(A) 50 r1(A) A += 100 w1(A) 150 r1(B) B += 100 w1(B) 125 r2(B) B *= 2 w2(B) 250

Transaction 1 Transaction 2 A B 25 l2(A); r2(A) A *= 2 w2(A); u2(A) 50 l1(A); r1(A) A += 100 w1(A); u1(A) 150 l1(B); r1(B) B += 100 w1(B); u1(B) 125 l2(B); r2(B) B *= 2 w2(B); u2(B) 250

The Rules Are Incomplete! Consistency of Transactions + Legality of Schedules != conflict-serializability