1. Concurrency Control via Timestamps

2. Timestamp-Based Scheduling
Timestamp-based scheduling is similar to validation-based scheduling in that it is optimistic and checks for non-serializable actions (roll backing if needed).
But instead of having a validation phase in the middle of a transaction, each read and write is validated at the time it occurs.
To do this, every database element needs some additional meta-data:
RT(X) - the read time of X, which is the time of the highest (most recent) time X was read
WT(X) - the write time of X, which is the time of the highest time X was written to
C(X) - the commit bit of X, which is True if and only if the highest write of X has committed
This bit is used to check if its state is uncommitted and is used to prevent dirty reads (reading uncommitted data)

3. Physically Unrealizable Behaviors
Transactions should appear to happen serially in the order in which they started. If they do things which violate this, they have performed a behavior which is physically unrealizable.
Read-too-late:
Ti tries to read element X, but a different transaction (Tj) wrote over element X. And, Tj started after Ti. Ti should have read the old value of X, but can't because it is overwritten.
Write-too-late:
Ti tries to write to element X, but Tj has already read X. And, Tj started after Ti. Tj should have read the value written by Ti, but didn't (because Ti wrote too late).

4. Where should w1(x) occur?
Before w2(x) Before r3(X) Last Nowhere
T1 start
T2 start
T3 start
time
w2(x)
r3(x)
w1(x) ?

5. Thomas Write Rule
Writes can be skipped if a later write is already in place.
One problem: if the later write is aborted, then the earlier write should have happened.
Solution: When a transaction writes to X, the write is "tentative" and may be undone if the transaction is aborted. The commit bit is set to False, and the scheduler makes a copy of the previous X and WT(X) for restore in the case of an abort.

6. Rules for Timestamp Based Scheduling
If a transaction wants to do a read (r1(X)):
If ts(T1) >= WT(X): # The read is physically realizable
If C(X) is true, grant the request
And, if ts(T1) > RT(X), set RT(X) to ts(T1), otherwise leave it alone
Else (C(X) is false):
Delay until transaction that wrote to (X) commits/aborts
Else (ts(T1) < WT(X)): # so the read is physically unrealizable
Rollback T1 and restart with a new timestamp

7. Rules for Timestamp Based Scheduling
If a transaction wants to do a write (w1(X)):
If ts(T1) >= RT(X) and ts(T1) >= WT(X): # physically realizable
Write the new value to X; Set WT(X) to ts(T1); Set C(X) to False
If ts(T1) >= RT(X) and ts(T1) < WT(X):
# physically realizable, but already written to
If C(X) is True, Thomas Write Rule applies (do nothing)
If C(X) is False, delay until 'later' write commits or aborts
If ts(T1) < RT(X): # physically unrealizable
Rollback T1 with a new timestamp

8. Rules for Timestamp Based Scheduling
If a transaction wants to commit:
Find all of the elements written to by that transaction and set all of the commit bits to true
If a transaction wants to rollback:
Any transaction that was waiting to write is allowed to do so now.
The previous version of each value that was written should be replaced (and the old WT replaced as well).

9. Why (in validation) do we start roll backed transactions with a new timestamp?
If a transaction is restarted with the same timestamp as before, it would always be immediately aborted Because Validation likes to be different from Locking