Two philosophies for the same job: ask first, or sort it out by age
Lock-based protocols make a transaction request permission before touching data, blocking rivals until it is safe. Timestamp-based protocols instead let every transaction proceed and use its age to resolve conflicts after the fact.
After this lesson
You should be able to
- Distinguish a shared lock from an exclusive lock and explain why the distinction matters.
- Explain how timestamp ordering resolves conflicts without using locks at all.
Locking: ask permission, and wait if you cannot have it yet
A shared lock (S-lock) on a data item allows a transaction to read it, and multiple transactions can hold a shared lock on the same item simultaneously — many readers cause no conflict. An exclusive lock (X-lock) allows a transaction to write the item, and it must be held alone; no other transaction may hold any lock, shared or exclusive, on that item at the same time. This mirrors a real reading-room rule: many people can read the same reference book at once, but only one person may write in it, and while they do, nobody else may even read it.
Two-phase locking (2PL) requires every transaction to split its life into a growing phase, where it may only acquire locks, and a shrinking phase, where it may only release them — never acquiring a new lock after releasing even one. This simple discipline, provably, guarantees conflict-serializability, connecting locking directly back to the previous lesson's precedence-graph test.
Timestamps: never wait, just check who is older
Timestamp-based protocols take an entirely different approach: every transaction gets a unique timestamp the instant it starts, fixing a strict relative order among all transactions before any conflict is even possible. No locks, no waiting to acquire permission — every operation is allowed to run immediately.
Instead, each data item remembers the timestamp of the youngest transaction that last read it and the youngest that last wrote it. Before any read or write, the protocol checks whether the requesting transaction's timestamp is older than what already happened — if an operation would violate the timestamp order (an older transaction trying to act after a younger one already did), that transaction is rolled back and restarted with a fresh, later timestamp instead of being blocked.
Try it yourself
Transaction T1 holds a shared lock on item X. Transaction T2 requests an exclusive lock on the same X. Explain what must happen under two-phase locking, and why.
Need a hint?
An exclusive lock cannot coexist with any other lock on the same item, shared or otherwise.
Check the worked solution
T2 must wait until T1 releases its shared lock on X, because an exclusive lock cannot be granted while any other transaction holds any lock (shared or exclusive) on the same item. This is precisely why write operations under locking can force other transactions to pause — the cost that timestamp ordering avoids by using restarts instead.
Quick check
Under timestamp ordering, why is a transaction rolled back and restarted rather than simply blocked to wait, when it would violate timestamp order?
Why this lesson exists
Syllabus mapping
Lock Based Protocols, Timestamp Based Protocols, Validation- Based Protocols, Multiple Granularity
Maps to course outcome CO3.