Pessimistic v.s. Optimistic. Outline. Timestamps. Timestamps. Timestamps. CSE 444: Database Internals. Main invariant:

Transcription

1 Pessimistic v.s. Optimistic SE 444: Database Internals Lectures 5 and 6 Transactions: Optimistic oncurrency ontrol Pessimistic (locking) Prevents unserializable schedules Never for serializability (but may for deadlocks) Best for workloads with high levels of contention Optimistic (timestamp, multi-version, validation) Assume schedule will be serializable Abort when conflicts detected Best for workloads with low levels of contention Outline oncurrency control by timestamps (8.8) oncurrency control by validation (8.9) Snapshot Isolation Timestamps Each transaction receives unique timestamp TS(T) ould be: The system s clock A unique counter, incremented by the scheduler 4 Timestamps Timestamps Main invariant: The timestamp order defines the serialization order of the transaction Will generate a schedule that is view-equivalent to a serial schedule, and recoverable 5 With each element X, associate RT(X) = the highest timestamp of any transaction U that read X WT(X) = the highest timestamp of any transaction U that wrote X (X) = the commit bit: true when transaction with highest timestamp that wrote X committed 6

2 Main Idea For any r T (X) or w T (X) request, check for conflicts: w U (X)... r T (X) r U (X)... w T (X) w U (X)... w T (X) How do we check if Read too late? Write too late? Main Idea For any r T (X) or w T (X) request, check for conflicts: w U (X)... r T (X) r U (X)... w T (X) w U (X)... w T (X) How do we check if Read too late? Write too late? When T requests r T (X), need to check TS(U) TS(T) 7 8 Read Too Late Read Too Late T wants to read X T wants to read X START(T) START(U) w U (X)... r T (X) START(T) START(U) w U (X)... r T (X) If WT(X) > TS(T) then need to rollback T! 9 0 Write Too Late Write Too Late T wants to write X T wants to write X START(T) START(U) r U (X)... w T (X) START(T) START(U) r U (X)... w T (X) If RT(X) > TS(T) then need to rollback T!

3 Thomas Rule But we can still handle it: T wants to write X Thomas Rule But we can still handle it: T wants to write X START(T) START(V) w V (X)... w T (X) If RT(X) TS(T) and WT(X) > TS(T) then don t write X at all! Why does SE 444 -this Winter 07 work? START(T) START(V) w V (X)... w T (X) If RT(X) TS(T) and WT(X) > TS(T) then don t write X at all! View-serializable Why does SE 444 -this Winter 07 work? 4 schedule View-Serializability By using Thomas rule we do obtain a viewserializable schedule Summary So Far Only for transactions that do not Otherwise, may result in non-recoverable schedule Transaction wants to read element X If WT(X) > TS(T) then ROLLBAK Else READ and update RT(X) to larger of TS(T) or RT(X) Transaction wants to write element X If RT(X) > TS(T) then ROLLBAK Else if WT(X) > TS(T) ignore write & continue (Thomas Write Rule) Otherwise, WRITE and update WT(X) =TS(T) 5 6 Ensuring Recoverable Schedules Recall: Schedule avoids cascading s if whenever a transaction reads an element, then the transaction that wrote it must have already committed Use the commit bit (X) to keep track if the transaction that last wrote X has committed Ensuring Recoverable Schedules Read dirty data: T wants to read X, and WT(X) < TS(T) Seems OK, but START(U) START(T) w U (X)... r T (X) ABORT(U) If (X)=false, T needs to wait for it to become true 7 8

4 Ensuring Recoverable Schedules Thomas rule needs to be revised: T wants to write X, and WT(X) > TS(T) Seems OK not to write at all, but START(T) START(U) w U (X)... w T (X) ABORT(U) Timestamp-based Scheduling When a transaction T requests r T (X) or w T (X), the scheduler examines RT(X), WT(X), (X), and decides one of: To grant the request, or To rollback T (and restart with later timestamp) To delay T until (X) = true If (X)=false, T needs to wait for it to become true 9 0 Timestamp-based Scheduling RULES including commit bit There are 4 long rules in Sec You should be able to derive them yourself, based on the previous slides Make sure you understand them! READING ASSIGNMENT: Timestamp-based Scheduling (Read instead!) Transaction wants to READ element X If WT(X) > TS(T) then ROLLBAK Else If (X) = false, then WAIT Else READ and update RT(X) to larger of TS(T) or RT(X) Transaction wants to WRITE element X If RT(X) > TS(T) then ROLLBAK Else if WT(X) > TS(T) Then If (X) = false then WAIT else IGNORE write (Thomas Write Rule) Otherwise, WRITE, and update WT(X)=TS(T), (X)=false Basic Timestamps with ommit Bit Basic Timestamps with ommit Bit T T 4 4 A WT=0 T T 4 4 A WT=0 WT= WT= Time R (A) Abort Delay Time R (A) Abort Delay W (A) delay W 4 (A) WT=4 W (A) delay W 4 (A) WT=4 WT= WT= W(A) WT= W(A) WT= 4 4

5 Summary of Timestamp-based Scheduling View-serializable Avoids cascading s (hence: recoverable) Does NOT handle phantoms These need to be handled separately, e.g. predicate locks Multiversion Timestamp When transaction T requests r(x) but WT(X) > TS(T), then T must rollback Idea: keep multiple versions of X: X t, X t-, X t-,... TS(X t ) > TS(X t- ) > TS(X t- ) > Details When w T (X) occurs, if the write is legal then create a new version, denoted X t where t = TS(T) When r T (X) occurs, find most recent version X t such that t < TS(T) Notes: WT(X t ) = t and it never changes RT(X t ) must still be maintained to check legality of writes an delete X t if we have a later version X t and all active transactions T have TS(T) > t 7 Four versions of X: R 6 (X) -- Read X Example (in class) X X 9 X X 8 W (X) heck read timestamp of X 8 R 5 (X) Read X W 5 (X) heck read timestamp of X When can we delete X? 8 Example w/ Basic Timestamps T Timestamps: 50 R (A) W (A) T 4 5 R (A) Abort R 4 (A) A WT=0 RT=50 WT=50 RT=00 WT=00 RT=5 T 50 R (A) W (A) Example w/ Multiversion T 4 5 R (A) W (A) R 4 (A) A 0 RT=50 A 50 RT=00 RT=00 A 00 RT=

6 Second Example w/ Multiversion Second Example w/ Multiversion T W(A) R (A) R (A) T 4 T W 4 (A) R 4 (A) R 5 (A) W 5 (A) A 0 X A RT= X A A A 4 A 5 RT=5 RT=5 T W(A) R (A) R (A) T 4 T W 4 (A) R 4 (A) R 5 (A) W 5 (A) A 0 X A RT= X A A A 4 A 5 RT=5 RT=5 Outline oncurrency control by timestamps (8.8) oncurrency control by validation (8.9) Snapshot Isolation oncurrency ontrol by Validation Each transaction T defines: Read set RS(T) = the elements it reads Write set WS(T) = the elements it writes Each transaction T has three phases: Read phase; time = START(T) Validate phase (may need to rollback); time = VAL(T) Write phase; time = FIN(T) Main invariant: the serialization order is VAL(T) 4 Avoid r T (X) - w U (X) onflicts START(U) VAL(U) FIN(U) U: Read phase Validate Write phase T: Read phase Validate? START(T) conflicts VAL(T) IF RS(T) WS(U) and FIN(U) > START(T) (U has validated and U has not finished before T begun) Then ROLLBAK(T) 5 Avoid w T (X) - w U (X) onflicts START(U) VAL(U) FIN(U) U: Read phase Validate Write phase T: Read phase Validate Write phase? START(T) VAL(T) conflicts IF WS(T) WS(U) and FIN(U) > VAL(T) (U has validated and U has not finished before T validates) Then ROLLBAK(T) 6 6

7 Outline oncurrency control by timestamps (8.8) oncurrency control by validation (8.9) Snapshot Isolation Not in the book, but good overview in Wikipedia Better: pay attention in class! Snapshot Isolation A type of multiversion concurrency control algorithm Provides yet another level of isolation Very efficient, and very popular Oracle, PostgreSQL, SQL Server 005 Prevents many classical anomalies BUT Not serializable (!), yet ORALE and PostgreSQL use it even for SERIALIZABLE transactions! But serializable snapshot isolation now in PostgreSQL 7 8 Snapshot Isolation Overview Snapshot Isolation Details Each transactions receives a timestamp TS(T) Transaction T sees snapshot at time TS(T) of the database Write/write conflicts resolved by first committer wins rule Loser gets ed Read/write conflicts are ignored Multiversion concurrency control: Versions of X: X t, X t, X t,... When T reads X, return X TS(T). When T writes X (to avoid lost update): If latest version of X is TS(T) then proceed If (X) = true then If (X) = false then wait When T commits, write its updates to disk 9 40 What Works and What Not Write Skew No dirty reads (Why?) No inconsistent reads (Why?) No lost updates ( first committer wins ) Moreover: no reads are ever delayed T: READ(X); if X >= 50 then Y = -50; WRITE(Y) OMMIT In our notation: T: READ(Y); if Y >= 50 then X = -50; WRITE(X) OMMIT However: read-write conflicts not caught! R (X), R (Y), W (Y), W (X),, Starting with X=50,Y=50, we end with X=-50, Y=-50. Non-serializable!!! 4 4 7

8 Write Skews an Be Serious Acidicland had two viceroys, Delta and Rho Budget had two registers: taxes, and spendyng They had high taxes and low spending Delta: READ(taXes); if taxes = High then { spendyng = Raise ; WRITE(spendYng) } OMMIT Rho: READ(spendYng); if spendyng = Low then {taxes = ut ; WRITE(taXes) } OMMIT Discussion: Tradeoffs Pessimistic : Locks Great when there are many conflicts Poor when there are few conflicts Optimistic : Timestamps, Validation, SI Poor when there are many conflicts (rollbacks) Great when there are few conflicts ompromise READ ONLY transactions timestamps READ/WRITE transactions locks and they ran a deficit ever since ommercial Systems Always check documentation! DB: Strict PL SQL Server: Strict PL for standard 4 levels of isolation Multiversion concurrency control for snapshot isolation PostgreSQL: SI; recently: seralizable SI (!) Oracle: SI 45 8