1. Locks

2. 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.

3. 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

4. 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).

5. 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 ???

6. 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

7. 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

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