Concurrency Control via
Validation
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.
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
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)
http://optimist.deviantart.com/art/you-cannot-pass-7205616
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
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)
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.
http://www.onedirectionmusic.com/