Timestamps and Multiversion CC, Plua Oracle Locking

CS764 Spring 2004 Lecture 4- Timestamps and Multiversion CC, Plua Oracle
Locking

Basic Timestamp Order


• Timestamp ordering is a technique in which a serialization order is selected aprior
and transaction execution is forced to obey this order.

• Each transaction gets assigned a unique timestamp at startup

• Conflicting operations are processed in timestamp order


Operation

For each data item X, DBMS records the largest time stamp of any read and/or write
operation that has been processed. These are denoted: R-ts(X) and W-ts(X).


RW Synchronization:

• Consider a read with timestamp TS.
• If TS < W_ts(X), the read is rejected and the transaction is aborted
• Otherwise, the read is processed and R-ts(X) is set to max (R-ts(X), TS)

• Consider a write with timestamp TS
• If TS < R-ts(X), the write is rejected and the transaction is aborted
• Otherwise, the write is processed and W-ts(X) is set to max (W-ts(X), TS)

WW Synchronization

• A write with timestamp TS is rejected if TS < W-ts(X)
• Otherwise, the write is processed and W-ts(X) is set to TS
• The Thomas Write Rule is an optimization in which instead of rejected the
write when TS < W-ts(X), simply ignores the write

Comments

• When a transaction is aborted it is assigned a new and larger timestamp by the
DBMS and is restarted



Multiversion Time Stamp Ordering

For each data item X there is a set of R-ts and a set of (W-ts, value) pairs called versions

The read time stamps are the times of the reads that have been performed

RW Synchronization:

• Consider a read R with timestamp TS (R)
• R is processed by reading the version of X with the largest time stamp less
than TS(R) and TS(R) is added to the set of R-ts associated with X
• R is never rejected

• Consider a write W with timestamp TS. Let interval(W) be the interval from
ts(W) to the smallest W-ts(X) > ts(W) (assuming one exist, infinity
otherwise)
• If any R-ts(X) lies in interval(W), the write is rejected.

• Otherwise, write is processed and a new version of X is created with
timestamp (TS).


WW Synchronization

• A write always creates a new version of X with timestamp ts.
• Writes are never rejected


Oracle Locking

Uses a combination of multiversion time stamp ordering and locking

Example of a CC approach that uses different mechanisms to handle R-W, W-R, and
WW conflicts.

Oracle uses versioning to deal with R-W and W-R conflicts and locks to deal with WW
conflicts

Oracle never sets read locks!

Oracle’s Isolation Levels: Read Committed, Serializable, Read Only

• Can be set for an individual SQL query or an entire transaction which consists of
multiple SQL queries

Read Committed

• Enforces serialization at statement level

• Each statement (query) sees only committed data
• May suffer from non-repeatable reads and phantom reads
o T1 is said to have had a phantom read if T2 inserts new records that would
have been read by T1:

T1 select * from foo where condition
T2 inserts new records into foo that satisfy the condition and committs


Serializable

• Enforces serialization at transaction level
• Each statement sees data that was committed at the start of the transaction

Read Only

• Prohibits update operations by the transaction


Implementation

Locks on stored on the data page. This originates from the DEC Vax Cluster which had
a shared disk architecture. You can think of the locks as being part of the slot array

An transaction that updates a record does the following sequence of operations.

a) reads the data page into the buffer pool (if the page is not resident already)
b) obtains a exclusive lock on the record
c) copies the old version of the record to a “rollback segment” (think of the rollback
segment as a place where all the updated versions of records go)

d) updates the version of the record on the page and timestamps it with the timestamp of
the transaction
e) logs the changes to a redo log including the rollback info
f) eventually commits/aborts.
• If the transaction aborts the rollback segment is used to restore the version of the
record to the version that existed before the update

WW conflicts

Assume T1 has a lock on a record (as above)

T2 attempts to update the same record and will be blocked. If T1 eventually commits it
will release its lock and one of the following two cases will happen:

• If T2 is running at Serializable isolation level, T2 will fail and be aborted. The
problem is that T2 would see data that changed after it started – this violates the
Serializable isolation level of T2.

• If T2 is running at Read Committed isolation level, T2 is unblocked and proceeds

RW and WR conflicts

T1 attempts to read some record R

a) reads the data page into the buffer pool

b) looks at the timestamp and Xactid of R Assume Ti is the XACTID of the last updater

Three possible cases

i) Ti has committed

i.1) TS (Ti) < TS (T1) - use the version of R that is on the data page

i.2) TS (Ti) > TS (T1) – use the rollback segment to obtain the correct version of R

a) For Read Committed – want version that was committed at the time the select
started

b) for Serializable Isolation level – want version that was committed at the time
the transaction T1 started

ii) Ti has not committed

use the rollback segment to obtain the correct version of the object (according to the
whether the transaction is operating at Read Committed or Serializable Isolation levels

Cleaning up Rollback segments - a rollback segment can be deleted when

a) all transactions that generated updates that are reflected in the segment have
committed

and

b) there are no longer any transactions that could possible read a version of a record in
the rollback segment