Forcing Acyclicity

Locking

Snapshot Isolation

Timestamp Concurrency Control*

3x T2 "happens before" T1

The schedule is conflict-serializable

... but 2-Phase locking won't work if we can't predict T1's accesses.

Locking is...

... expensive

Costs are still incurred even if there are no problematic conflicts.

... restrictive

We don't know what the transaction will do, so we can't allow all schedules.

We don't know what a transaction will do... until it does.

Idea: Let the transaction do it.

(Then fix it if it broke anything later)

Forcing Acyclicity

Locking

Pessimistically block transactions before they can operate out of order.

Snapshot Isolation

Optimistically allow transactions to run and clean up after them if they break things.

Timestamp Concurrency Control*

Generic Transaction

... with snapshots

Read Phase

Collect...

$\textbf{ReadSet}(\mathcal T)$

The set of objects read by $\mathcal T$

$\textbf{WriteSet}(\mathcal T)$

The set of objects written by $\mathcal T$

T1 and T2 read the same object

OK!

T1 reads an object written by T2 (read-write)

Ok. (T1's validation phase started before T2's)

T2 reads an object written by T1 (write-read)

Ok if T1-Write finishes before T2-Read starts.

T1 and T2 write the same object (write-write)

Ok if T1-Write finishes before T2-Write starts.

Which conflicts we need to check for are different depending on how the phases overlap.

Note: The validation and write phases are NOT instantaneous.

Validation (and selecting a serial order) are a critical section: only one transaction at a time.

Allow write phases to proceed concurrently.

Test 1

If T1's write phase ends before T2's read phase starts, the transactions are already serial.

Test 2

If T1's write phase ends before T2's write phase starts, there's a possibility of write-read conflicts. Abort unless: $$WriteSet(T_1) \cap ReadSet(T_2) = \emptyset$$

Test 3

Otherwise write-read and write-write conflicts are possible. Abort unless: $$WriteSet(T_1) \cap ReadSet(T_2) = \emptyset$$ $$WriteSet(T_1) \cap WriteSet(T_2) = \emptyset$$

Idea: Check while the transaction is running

(abort immediately if a violation happens)

Timestamp Concurrency Control

(Snapshot Isolation as seen "in practice")

Each object $A$ gets a read timestamp ($RTS(A)$) and a write timestamp ($WTS(A)$)

Each transaction $\mathcal T$ gets a timestamp ($TS(\mathcal T)$).

(note that these can be logical timestamps like sequence numbers)

Basic Idea: Require transactions to follow $TS(\mathcal T)$ as a serial order.

Abort (and restart) transactions that would break this order.

Assign restarted transactions a brand new timestamp for fairness

When $\mathcal T$ reads object $A$...

If $WTS(A) > TS(\mathcal T)$

The value stored is a "later" version (write-read)

ABORT

If $WTS(A) < TS(\mathcal T)$

The value stored is safe to read.

$RTS(A) \leftarrow MAX(RTS(A), TS(\mathcal T))$

When $\mathcal T$ writes object $A$...

If $RTS(A) > TS(\mathcal T)$

Read from an "later" transaction (write-read)

ABORT

If $WTS(A) > TS(\mathcal T)$

Write from a "later" transaction (write-write)

Ignore the write

Otherwise

The value stored is safe to write.

$WTS(A) \leftarrow MAX(WTS(A), TS(\mathcal T))$

So is it correct?

T3's write to $A$ "hides" T2's

View Serializability

Conflict Equivalence

Two schedules are conflict-equivalent when you can transform one into the other by reordering any pair of operations that...

• operate on different objects
• OR, are both reads

View Equivalence

Two schedules are view-equivalent when you can transform one into the other by reordering any pair of operations that...

• operate on different objects
• OR, are both reads
• OR, are both writes to the same object, but ONLY IF the object is later overwritten by another write.

View Serializability

A schedule is view serializable if it is view-equivalent to some serial schedule

Timestamp concurrency control is guaranteed to produce view-serializable schedules.

View Serializability

On the happens-before graph, throw away edges created by "hidden" write-write conflicts.

If the resulting graph is acyclic, the schedule is view serializable

Timestamp Concurrency Control

(Snapshot Isolation as seen "in practice")

Read timestamps are expensive.

(every read becomes a write)

Snapshot Isolation in Oracle, Postgresql, SQLServer, etc... is Timestamp Concurrency Control without read timestamps.

Write-write conflicts will be detected.

Write before read conflicts will be detected.

Read before write conflicts will not be detected.

oops...

• Buffer all writes until a writer commits (but update WTS immediately)
• Block readers of object $A$ from committing until the all prior writers to $A$ commit.
• Abort readers of object $A$ of any prior writer of $A$ aborts.

Each version of an object has...

• ... the writing transaction's TS as its WTS.
• ... the highest TS of any transaction to read it as its RTS.

When $\mathcal T$ reads object $A$...

Always...

$RTS(A_i) \leftarrow MAX(RTS(A_i), TS(\mathcal T))$

When $\mathcal T$ writes object $A$...

If $RTS(A_i) > TS(\mathcal T)$

Unrecoverable read from an "later" transaction (write-read)

ABORT

If $WTS(A) > TS(\mathcal T)$

Write from a "later" transaction (write-write)

Add the write to the versions of $A$

Otherwise

The value stored is safe to write.

Add the write to the versions of $A$