In a database where multiple transactions run concurrently, one way to avoid conflicts and ensure correctness is to order transactions by time using a timestamp‑based protocol.

Instead of using locks, this protocol assigns a numeric timestamp to each transaction and uses these timestamps to decide who goes first when conflicts arise. This creates a deterministic order that helps the system produce serializable schedules.

What Is a Timestamp?

A timestamp is a unique number that represents the logical time at which a transaction starts.

• Often timestamps are just increasing counters (1, 2, 3, ...).

• A smaller timestamp means the transaction is older (started earlier).

• A larger timestamp means the transaction is newer (started later).

The DBMS keeps a system timestamp and assigns it to each new transaction when it begins.

Basic Idea of Timestamp‑Based Protocol

Every data item has, conceptually, two timestamps associated with it:

• Read timestamp (RT): the timestamp of the latest transaction that successfully read the item.

• Write timestamp (WT): the timestamp of the latest transaction that successfully wrote the item.

Whenever a transaction wants to read or write an item, the protocol compares its own timestamp with these values:

• If the transaction is “too old” (its timestamp is older than the current state), it may be rejected or rolled back.

• If the transaction is “new enough”, the operation is allowed and the timestamps are updated.

In simple terms, the protocol enforces:

“Older transactions cannot overwrite or ignore the changes of newer ones, and newer transactions cannot read garbage from the future.”

How It Works: Read and Write Rules

For a transaction $T$ with timestamp $TS(T)$ trying to access a data item:

• Before a read

  • If $TS(T) < \text{WT(item)}$, that means $T$ is older than the last writer.

  • The read may be rejected or rolled back (depending on variant) to avoid inconsistency.

• Before a write

  • If $TS(T) < \text{RT(item)}$, that means some younger transaction has already read the old value.

  • Overwriting now would break that transaction’s view, so the write may be rejected or rolled back.

If the checks pass, the operation is allowed and the read or write timestamp of the item is updated to $TS(T)$.

This mechanism effectively imposes a total order on transactions, similar to a serial schedule, even though operations may be interleaved.

Why Timestamp‑Based Protocol Matters?

• It is a lock‑free approach to concurrency control: transactions are ordered by timestamps instead of by waiting for locks.

• It guarantees serializability by enforcing a consistent logical order.

• It is especially useful in distributed systems and theoretical models where fine‑grained locking is hard.

For beginners, the key idea is:

• Each transaction gets a timestamp when it starts.

• Reads and writes are allowed only if the timestamp order is respected, otherwise the transaction is rejected or restarted.

Summary

Timestamp‑based protocol in DBMS is a concurrency control method that assigns a timestamp to each transaction and uses these timestamps to decide the order of conflicting operations. By comparing a transaction’s timestamp with the read and write timestamps of data items, the protocol ensures that only serializable schedules are allowed. This approach avoids many locking complications while still guaranteeing correctness in concurrent execution.