Concurrency Control via Timestamps TimestampBased Scheduling Timestampbased scheduling

Concurrency Control via Timestamps

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)

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).

Where should w 1(x) occur? T 1 start T 2 start Before w 2(x) Before r 3(X) Last Nowhere T 3 start time w 2(x) r 3(x) w 1(x) ?

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.

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

Rules for Timestamp Based Scheduling If a transaction wants to do a write (w 1(X)): ◦ If ts(T 1) >= RT(X) and ts(T 1) >= WT(X): # physically realizable ◦ Write the new value to X; Set WT(X) to ts(T 1); Set C(X) to False ◦ If ts(T 1) >= RT(X) and ts(T 1) < 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(T 1) < RT(X): # physically unrealizable ◦ Rollback T 1 with a new timestamp

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).

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