The Issue • Maintaining database correctness when Implementing Isolation many transactions are accessing the database concurrently – Assuming each transaction maintains database Chapter 20 correctness when executed in isolation 1 2 Transaction Schedule T1: begin_transaction(); Isolation …. Transaction schedule (commit applies to this) • Serial execution: p1,1; …. p p p – Since each transaction is consistent and isolated from all 1,1 1,2 1,3 others, schedule is guaranteed to be correct for all p1,2; To db applications …. server – Inadequate performance p1,3; local • Since system has multiple asynchronous resources and commit(); variables transaction uses only one at a time • Concurrent execution: • Consistent - performs correctly when executed in – Improved performance (multiprogramming) isolation starting in a consistent database state – Some interleavings produce correct result, others do not – Preserves database consistency – We are interested in concurrent schedules that are equivalent to serial schedules. These are referred to as – Moves database to a new state that corresponds to new real-world state serializable schedules. 3 4 Schedule Schedule Schedule in which • Representation 1: Arriving schedule requests are serviced (merge of transaction (to preserve isolation) T : p p p p T1 schedules) 1 1 2 3 4 T : p p Concurrency 2 1 2 time → T2 Control database • Representation 2: T3 transaction p1,1 p1,2 p2,1 p1,3 p2,2 p1,4 schedules Database server time → 5 6 1 Concurrency Control Correct Schedules • Interleaved schedules equivalent to serial • Transforms arriving interleaved schedule into a schedules are the only ones guaranteed to be correct interleaved schedule to be submitted to the correct for all applications DBMS • Equivalence based on commutativity of operations – Delays servicing a request (reordering) - causes a transaction to wait • Definition: Database operations p1 and p2 – Refuses to service a request - causes transaction to commute if, for all initial database states, they abort (1) return the same results and • Actions taken by concurrency control have (2) leave the database in the same final state performance costs when executed in either order. – Goal is to avoid delaying or refusing to service a p1 p2 p2 p1 request 7 8 Commutativity of Read and Conventional Operations Write Operations • Read • p1 commutes with p2 if – r(x, X) - copy the value of database variable x to – They operate on different data items local variable X • w1(x) commutes with w2(y) and r2(y) • Write – Both are reads – w(x, X) - copy the value of local variable X to • r1(x) commutes with r2(x) database variable x • Operations that do not commute conflict • w (x) conflicts with w (x) • We use r1(x) and w1(x) to mean a read or 1 2 • w1(x) conflicts with r2(x) write of x by transaction T1 9 10 Equivalence of Schedules Equivalence of Schedules • An interchange of adjacent operations of different • Equivalence is transitive: If S1 can be derived transactions in a schedule creates an equivalent from S by a series of such interchanges, S is schedule if the operations commute 2 1 ≠ equivalent to S S1: S1,1 pi,j pk,l S1,2 where i k 2 S2: S1,1 pk,l pi,j S1,2 – Each transaction computes the same results (since operations return the same values in both schedules) and hence writes the same values to the database. – The database is left in the same final state (since the state seen by S1,2 is the same in both schedules). 11 12 2 Example of Equivalence Example of Equivalence conflict S : r (x) r (x) w (x) r (y) w (y) 1 1 2 2 1 1 T1: begin transaction T2: begin transaction read (x, X); read (x,Y); S2: r1(x) r2(x) r1(y) w2(x) w1(y) X = X+4; write (y,Y); write (x, X); commit; S3: r1(x) r1(y) r2(x) w2(x) w1(y) commit; S4: r1(x) r1(y) r2(x) w1(y) w2(x) initial state final state x=1, y=3 r (x) r (x) w (y) w (x) x=5, y=1 S5: r1(x) r1(y) w1(y) r2(x) w2(x) 1 2 2 1 Interchange conflicting operations x=1, y=3 r (x) w (y) r (x) w (x) x=5, y=1 commuting operations 2 2 1 1 ordered in same way T T S1 is equivalent to S5 2 1 S is the serial schedule T , T Interchange 5 1 2 conflicting operations x=1, y=3 r1(x) w1(x) r2(x) w2(y) x=5, y=5 S is serializable 1 T1 T2 S1 is not equivalent to the serial schedule T2, T1 13 14 Serializable Schedules Isolation Levels • Serializability provides a conservative definition of • S is serializable if it is equivalent to a serial correctness schedule – For a particular application there might be many • Transactions are totally isolated in a serializable acceptable non-serializable schedules schedule – Requiring serializability might degrade performance • A schedule is correct for any application if it is a • DBMSs offer a variety of isolation levels: §©¨ ¥ § ¨ ¢ serializable schedule of consistent transactions ¡£¢£¤¦¥ is the most stringent • The schedule : – Lower levels of isolation give better performance r1(x) r2(y) w2(x) w1(y) is not serializable • Might allow incorrect schedules • Might be adequate for some applications 15 16 Serializable Conflict Equivalence • Theorem - Schedule S can be derived from S 1 2 • Definition- Two schedules, S and S , of the by a sequence of commutative interchanges if 1 2 same set of operations are conflict equivalent if and only if conflicting operations in S and S 1 2 conflicting operations are ordered in the same are ordered in the same way way in both Only If: Commutative interchanges do not reorder – Or (using theorem) if one can be obtained from the conflicting operations other by a series of commutative interchanges If: A sequence of commutative interchanges can be determined that takes S1 to S2 since conflicting operations do not have to be reordered (see text) 17 18 3 Conflict Equivalence View Equivalence • Result- A schedule is serializable if it is conflict equivalent to a serial schedule • Two schedules of the same set of operations ≡ r1(x) w2(x) w1(y) r2(y) r1(x) w1(y) w2(x) r2(y) are view equivalent if: conflict conflict – Corresponding read operations in each return the same values (hence computations are the same) • If in S transactions T1 and T2 have several pairs of – Both schedules yield the same final database state conflicting operations (p1,1 conflicts with p2,1 and • Conflict equivalence implies view equivalence. p conflicts with p ) then p must precede p 1,2 2,2 1,1 2,1 • View equivalence does not imply conflict and p1,2 must precede p2,2 (or vice versa) in order for S to be serializable. equivalence. 19 20 Conflict vs View Equivalence View Equivalence set of schedules set of schedules T1: w(y) w(x) that are view that are conflict T2: r(y) w(x) equivalent to equivalent to serial schedules T3: w(x) serial schedules • Schedule is not conflict equivalent to a serial schedule • A concurrency control based on view equivalence should provide better performance than one based • Schedule has same effect as serial schedule on conflict equivalence since less reordering is done T2 T1 T3. It is view equivalent to a serial but … schedule and hence serializable • It is difficult to implement a view equivalence concurrency control 21 22 Conflict Equivalence and Serialization Graph of a Serializability Schedule, S • Serializability is a conservative notion of • Nodes represent transactions correctness and conflict equivalence • There is a directed edge from node Ti to node provides a conservative technique for Tj if Ti has an operation pi,k that conflicts with determining serializability an operation pj,r of Tj and pi,k precedes pj,r in S • However, a concurrency control that • Theorem - A schedule is conflict serializable guarantees conflict equivalence to serial if and only if its serialization graph has no schedules ensures correctness and is easily cycles implemented 23 24 4 Example Conflict (*) Intuition: Serializability and S: … p , …, p , ... 1,i 2,j Nonserializability T2 T4 S is serializable in order • Consider the nonserializable schedule * T1 T2 T3 T4 T5 T6 T7 r1(x) w2(x) r2(y) w1(y) T1 T2 T1 T5 T6 T7 • Two ways to think about it: – Because of the conflicts, the operations of T1 and T2 T3 cannot be interchanged to make an equivalent serial S is not serializable due schedule T2 T4 – Because T read x before T wrote it, T must precede to cycle T2 T6 T7 T2 1 2 1 T2 in any ordering, and because T1 wrote y after T2 read it, T1 must follow T2 in any ordering --- clearly an T1 T5 T6 T7 impossibility T3 25 26 Recoverability: Schedules with Aborted Transactions Cascaded Abort T1 : r (x) w(y) commit • Recoverable schedules solve abort problem T : w(x) abort 2 but allow cascaded abort: abort of one • T2 has aborted but has had an indirect effect on the transaction forces abort of another database – schedule is unrecoverable T1: r (y) w(z) abort • Problem: T1 read uncommitted data - dirty read T2: r (x) w(y) abort • Solution: A concurrency control is recoverable if it T3: w(x) abort does not allow T1 to commit until all other • Better solution: prohibit dirty reads transactions that wrote values T1 read have committed request T1 : r (x) w(y) commit abort T2: w(x) abort 27 28 Dirty Write Strict Schedules • Dirty write: A transaction writes a data item • Strict schedule: Dirty writes and dirty reads written by an active transaction are prohibited • Dirty write complicates rollback: • Strict and serializable are two different no rollback necessary properties – Strict, non-serializable schedule: T1: w(x) abort r1(x) w2(x) r2(y) w1(y) c1 c2 T2 : w(x) abort – Serializable, non-strict schedule: what value of x w2(x) r1(x) w2(y) r1(y) c1 c2 should be restored? 29 30 5 Concurrency Control Models of