In timestamping as a concurrency-control method, the scheduler needs to assign to each transaction T a unique number, its timestamp TS (T). Timestamps must be issued in ascending order, at the time that a transaction first notifies the scheduler that it is beginning. Two approaches to generating timestamps are:

a. One possible way to create timestamps is to use the system clock, provided the scheduler does not operate so fast that it could assign timestamps to two transactions on one tick of the clock.

b. Another approach is for the scheduler to maintain a counter. Each time a transaction starts, the counter is incremented by I, and the new value becomes the timestamp of the transaction. In this approach, timestamps have nothing to do with "time," but they have the important property that we need for any timestamp-generating system: a transaction that starts later has a higher timestamp than a transaction that starts earlier.

Whatever method of generating timestamps is used, the scheduler must maintain a table of currently active transactions and their timestamps.

To use timestamps as a concurrency-control method, we need to associate with each database element X two timestamps and an additional bit:

1. aT(X), the read time of X, which is the highest timestamp of a transaction that has read X.

2. wr(X). the write tone oft which is the highest timestamp of a transaction that has written X.

3. c(X), the commit bit for X, which is true if and only if the most recent transaction to write A' has already committed. The purpose of this bit is to avoid a situation where one transaction T reads data written by another transaction U, and U then aborts. This problem, where T makes a "dirty read" of uncommitted data, certainly can cause the database state to become inconsistent, and any scheduler needs a mechanism to prevent dirty reads.