DBMS Notes
The Timestamp Ordering Protocol is a concurrency control mechanism that uses transaction timestamps — rather than locks — to determine the serialization...
Overview
The Timestamp Ordering Protocol is a concurrency control mechanism that uses transaction timestamps — rather than locks — to determine the serialization order of conflicting operations. Each transaction receives a unique timestamp when it begins, and the protocol ensures that conflicting read/write operations execute in timestamp order.
The most significant advantage: No locks means no deadlocks. This eliminates the need for deadlock detection, prevention, or timeout mechanisms entirely.
Per-Data-Item Bookkeeping
For each data item X in the database, the system maintains two timestamp values:
| Field | Meaning |
|---|---|
| W-timestamp(X) | The largest timestamp of any transaction that has successfully executed write(X) |
| R-timestamp(X) | The largest timestamp of any transaction that has successfully executed read(X) |
These fields record "who was the most recent reader/writer" and are updated after each successful operation.
Protocol Rules
Read Rule — Transaction Ti wants to read(X)
| CASE 1 | TS(Ti) < W-timestamp(X) |
| Meaning | Ti is older than the transaction that last wrote X. |
| Problem | Ti would read a value that has been overwritten by a newer transaction. |
| Action | REJECT. Abort Ti and restart with a new (larger) timestamp. |
| CASE 2 | TS(Ti) >= W-timestamp(X) |
| Meaning | Ti is at least as new as the last writer -- read is safe. |
| Action | ALLOW the read. |
| Update | R-timestamp(X) = MAX(R-timestamp(X), TS(Ti)) |
Write Rule — Transaction Ti wants to write(X)
| CASE 1 | TS(Ti) < R-timestamp(X) |
| Meaning | A newer transaction has already READ the current value of X. |
| Problem | If Ti writes now, that newer read would have seen wrong data. |
| Action | REJECT. Abort Ti and restart with a new timestamp. |
| CASE 2 | TS(Ti) < W-timestamp(X) |
| Meaning | A newer transaction has already WRITTEN X. |
| Problem | Ti's write would overwrite a more recent value. |
| Action | REJECT. Abort Ti and restart with a new timestamp. |
| (Thomas Write Rule variant | simply SKIP this write instead of aborting) |
| CASE 3 | TS(Ti) >= R-timestamp(X) AND TS(Ti) >= W-timestamp(X) |
| Meaning | Ti is the newest transaction to access X. |
| Action | ALLOW the write. |
| Update | W-timestamp(X) = TS(Ti) |
Worked Example
| Initial | R-timestamp(A) = 0, W-timestamp(A) = 0 |
| Transactions | T1 (TS=1), T2 (TS=2), T3 (TS=3) |
| Step 1 | T2 reads A |
| Step 2 | T3 writes A |
| Step 3 | T1 reads A |
| -> REJECT | T1 is ABORTED, restarted with new timestamp (say TS=4) |
| Step 4 | T2 writes B |
| Step 5 | T3 reads B |
Thomas Write Rule (Optimization)
The basic protocol aborts Ti when TS(Ti) < W-timestamp(X) for a write. But the Thomas Write Rule observes that if a newer transaction has already written X, then Ti's write is obsolete — it would be immediately overwritten anyway. So instead of aborting, we simply skip the write:
Timestamp Protocol Guarantees
| Property | Guaranteed? |
|---|---|
| Conflict serializability | Yes (basic protocol) |
| View serializability | Yes (Thomas Write Rule) |
| Deadlock freedom | Yes (no locks used) |
| Starvation freedom | No (transaction may be repeatedly aborted) |
| Cascading rollbacks | Possible (if aborted transaction's writes were read) |
Preventing Cascading Rollbacks
The basic timestamp protocol allows dirty reads (reading uncommitted data). To prevent cascading rollbacks:
- Strict Timestamp Ordering: Delay reads until the writing transaction commits
- Buffered Writes: Hold writes in a buffer until commit, then apply all at once
- Commit Dependencies: Track which transactions read from uncommitted writers
Comparison: Timestamp vs. Lock-Based Protocols
| Feature | Timestamp Protocol | Two-Phase Locking (2PL) |
|---|---|---|
| Deadlocks | Impossible | Possible (need detection) |
| Restart frequency | Higher (conflicts cause abort) | Lower (conflicts cause wait) |
| Overhead | Maintain timestamps per item | Maintain lock table |
| Serialization order | Determined at start (by TS) | Determined at runtime (by lock grants) |
| Starvation | Possible (repeated aborts) | Possible (long waits) |
| Best suited for | Read-heavy, low-conflict workloads | Write-heavy, high-conflict workloads |
Advantages and Disadvantages
Advantages:
- No deadlocks (eliminates a major complexity in database systems)
- Serialization order is predictable (based on start time)
- No waiting for locks — transactions proceed immediately or abort
- Good for distributed systems (timestamps are easy to coordinate)
Disadvantages:
- High abort rate under heavy write contention (many restarts)
- Starvation: a long transaction may be repeatedly aborted by newer ones
- Cascading rollback possible without strict variant
- Maintaining timestamps for every data item adds storage overhead
Summary
The timestamp protocol provides deadlock-free concurrency control by ordering all operations according to transaction start times. It works well for read-dominated workloads with low conflict but suffers from excessive aborts under heavy write contention. The Thomas Write Rule optimization reduces unnecessary aborts by skipping obsolete writes rather than aborting their transactions.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Timestamp-Based Protocol.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Database Management Systems (DBMS) topic.
Search Terms
dbms, database management systems (dbms), unit, timestamp, protocol, timestamp-based protocol
Related Database Management Systems (DBMS) Topics