Where We Are

• ACID properties of transactions CSE 444: Database Internals • Concept of serializability • How to provide serializability with locking • Lowers level of isolation with locking • How to provide serializability with optimistic cc Lectures 16 – Timestamps/Multiversion or Validation Transactions: Snapshot Isolation • Today: lower level of isolation with multiversion cc – Snapshot isolation

Magda Balazinska - CSE 444, Spring 2012 1 Magda Balazinska - CSE 444, Spring 2012 2

Snapshot Isolation Snapshot Isolation

• Not described in the book, but good overview in Wikipedia • A type of multiversion concurrency control algorithm • Provides yet another level of isolation

• Very efficient, and very popular – Oracle, PostgreSQL, SQL Server 2005

• Prevents many classical anomalies BUT… • Not serializable (!), yet ORACLE and PostgreSQL use it even for SERIALIZABLE transactions! – But “serializable snapshot isolation” now in PostgreSQL

Magda Balazinska - CSE 444, Fall 2010 3 Magda Balazinska - CSE 444, Fall 2010 4

Snapshot Isolation Rules Snapshot Isolation (Details)

• Multiversion concurrency control: • Each transactions receives a timestamp TS(T) – Versions of X: Xt1, Xt2, Xt3, . . .

• Transaction T sees snapshot at time TS(T) of the database • When T reads X, return XTS(T).

• When T commits, updated pages are written to disk • When T writes X: if other transaction updated X, abort – Not faithful to “first committer” rule, because the other transaction U might have committed after T. But once we abort • Write/write conflicts resolved by “first committer wins” rule T, U becomes the first committer J • Read/write conflicts are ignored

Magda Balazinska - CSE 444, Fall 2010 5 Magda Balazinska - CSE 444, Fall 2010 6

1 What Works and What Not Write Skew

• No dirty reads (Why ? ) • No inconsistent reads (Why ?) T1: T2: – A: Each transaction reads a consistent snapshot READ(X); READ(Y); if X >= 50 if Y >= 50 • No lost updates (“first committer wins”) then Y = -50; WRITE(Y) then X = -50; WRITE(X) COMMIT COMMIT • Moreover: no reads are ever delayed In our notation: R (X), R (Y), W (Y), W (X), C ,C • However: read-write conflicts not caught ! 1 2 1 2 1 2 Starting with X=50,Y=50, we end with X=-50, Y=-50. Non-serializable !!!

Magda Balazinska - CSE 444, Fall 2010 7 Magda Balazinska - CSE 444, Fall 2010 8

Write Skews Can Be Serious Questions/Discussions

• How does snapshot isolation (SI) compare to • Acidicland had two viceroys, Delta and Rho repeatable reads and serializable? • Budget had two registers: taXes, and spendYng – A: SI avoids most but not all phantoms (e.g., write skew) • They had high taxes and low spending… • Note: Oracle & PostgreSQL implement it even for isolation level SERIALIZABLE Delta: Rho: READ(taXes); READ(spendYng); – But most recently: “serializable snapshot isolation” if taXes = ‘High’ if spendYng = ‘Low’ • How can we enforce serializability at the app level ? then { spendYng = ‘Raise’; then {taXes = ‘Cut’; – A: Use dummy writes for all reads to create write-write WRITE(spendYng) } WRITE(taXes) } conflicts… but that is confusing for developers!!! COMMIT COMMIT

… and they ran a deficit ever since. 9 Magda Balazinska - CSE 444, Fall 2010 10

Commercial Systems Important Lesson

Always check documentation as DBMSs keep • ACID transactions/serializability make it easy to evolving and thus changing! Just to get an idea: develop applications • DB2: Strict 2PL • BUT they add overhead and slow things down • SQL Server: – Strict 2PL for standard 4 levels of isolation • Lower levels of isolation reduce overhead – Multiversion concurrency control for snapshot isolation • BUT they are hard to reason about for • PostgreSQL: Multiversion concurrency control developers! • Oracle: Multiversion concurrency control

Magda Balazinska - CSE 444, Fall 2010 11 Magda Balazinska - CSE 444, Spring 2012 12

2