1. Concurrency Control via Validation

2. Concurrency Control
So far, we've been using locks to manage concurrency control.
We care about serializability because then we can reason about transactions as if they were completely isolated from each other.
Locks achieve that by only allowing actions that can't generate non-serializable outcomes.
Locks are a form of pessimistic concurrency control because they assume transactions will conflict unless we stop them from doing so.
Locks aren't the only way to ensure serializable schedules.

3. Basic Idea Optimize for the case where conflict is rare.
Transactions occur in three phases:
Read. (In-transaction writes are to private storage)
Validation. Make sure no conflicts will occur when write phase happens
Write. If validations are successful, make writes public. (Else, abort!)
When is this a good idea?
When most transactions are readers (no conflicts)
Lots of transactions, each only accessing/modifying a small fraction of the total database

4. Validation Goal: Guarantee non-serializable schedules can not pass.
Technique: Find an equivalent serializable schedule.
Assign an ascending timestamp to each transaction at start
Ensure that if you run transactions in order by "<" on timestamp, you get an equivalent serial schedule.
Suppose ts(Ti) < ts(Tj), That ordering is serializable if one of the three conditions hold:
Ti completes its write phase before Tj starts its read phase
(Ti doesn't write to any object that Tj reads from) and (Ti completes its write phase before Tj starts its write phase)
(Ti doesn't write to any object that Tj reads from) and (Ti doesn't write to the same element that Tj writes to) and (Ti completes its read phase before Tj completes its read phase)

5. Conditions (Ti occurs before Tj):
Ti completes its write phase before Tj starts its read phase
Serial Execution
(Ti doesn't write to any object that Tj reads from) and (Ti completes its write phase before Tj starts its write phase)
You can interweave writes from Ti with reads from Tj, as long as they don't cause a WR conflict

6. Conditions (Ti occurs before Tj):
(Ti doesn't write to any object that Tj reads from) and (Ti doesn't write to the same element that Tj writes to) and (Ti completes its read phase before Tj completes its read phase)
You can interweave writes from Ti and reads from Tj or writes from Ti and writes from Tj, but all conflicts must be resolved as RW (never WR)

7. Why validation works
Each condition guarantees that the three possible conflicts (WR, RW, WW) are always resolved in "one direction", later transactions happen after earlier transactions.