Announcements. Review of Schedules. Scheduler. Notation. Pessimistic Scheduler. CSE 444: Database Internals. Serializability.

Size: px

Start display at page:

Download "Announcements. Review of Schedules. Scheduler. Notation. Pessimistic Scheduler. CSE 444: Database Internals. Serializability."

Erica Singleton
5 years ago
Views:

1 nnouncements SE 444: Database Internals Lab 2 is due tonight Lab 2 quiz is on Wednesday in class Same format as lab 1 quiz Lectures 14 Transactions: Locking Lab 3 is available Fastest way to do lab 3 is to do it very slowly Hw5 is due on Friday 1 2 Serializability Review of Schedules Serial Serializable onflict serializable View serializable Recoverability Recoverable voids cascading aborts Scheduler The scheduler: Module that schedules the transaction s actions, ensuring serializability Two main approaches Pessimistic: locks Optimistic: timestamps, multi-version, validation 3 4 Pessimistic Scheduler Notation Simple idea: Each element has a unique lock Each transaction must first acquire the lock before reading/writing that element If the lock is taken by another transaction, then wait The transaction must release the lock(s) l i () = transaction T i acquires lock for element u i () = transaction T i releases lock for element 5 6 1

2 Non-Serializable Schedule RED(, t) WRITE(, t) RED(, t) WRITE(,t) RED(,s) WRITE(,s) RED(,s) WRITE(,s) 7 L 1 (); RED(, t) WRITE(, t); U 1 (); L 1 () RED(, t) WRITE(,t); U 1 (); Example L 2 (); RED(,s) WRITE(,s); U 2 (); L 2 (); DENIED GRNTED; RED(,s) WRITE(,s); U 2 (); Scheduler has ensured a conflict-serializable schedule 8 L 1 (); RED(, t) WRITE(, t); U 1 (); L 1 (); RED(, t) WRITE(,t); U 1 (); ut L 2 (); RED(,s) WRITE(,s); U 2 (); L 2 (); RED(,s) WRITE(,s); U 2 (); Locks did not enforce conflict-serializability!!! What s wrong 9? The 2PL rule: In every transaction, all lock requests must precede all unlock requests This ensures conflict serializability! (will prove this shortly) 10 Example: 2PL transactions L 1 (); L 1 (); RED(, t) WRITE(, t); U 1 () RED(, t) WRITE(,t); U 1 (); Now it is conflict-serializable L 2 (); RED(,s) WRITE(,s); L 2 (); DENIED GRNTED; RED(,s) WRITE(,s); U 2 (); U 2 (); 11 Growing phase Shrinking phase Example with Multiple Transactions T4 Unlocks second so perhaps was waiting for Unlocks first Was not waiting for anyone Equivalent to each transaction executing entirely the moment it enters shrinking phase 12 2

3 13 14 Then there is the following temporal cycle in the schedule: Then there is the following temporal cycle in the schedule: U 1 ()àl 2 () why? Then there is the following temporal cycle in the schedule: U 1 ()àl 2 () L 2 ()àu 2 () why? 17 Then there is the following temporal cycle in the schedule: U 1 ()àl 2 () L 2 ()àu 2 () U 2 ()àl 3 () L 3 ()àu 3 () U 3 ()àl 1 () 18 L 1 ()àu 1 () ontradiction 3

4 New Problem: Non-recoverable Schedule L 1 (); L 1 (); RED(, t) WRITE(, t); U 1 () RED(, t) WRITE(,t); U 1 (); bort L 2 (); RED(,s) WRITE(,s); L 2 (); DENIED GRNTED; RED(,s) WRITE(,s); U 2 (); U 2 (); ommit 19 Strict 2PL Strict 2PL: ll locks held by a transaction are released when the transaction is completed; release happens at the time of OMMIT or ROLLK Schedule is recoverable Schedule avoids cascading aborts Schedule is strict: read book 20 L1(); RED() :=+100 WRITE(); L1(); RED() :=+100 WRITE(); U1(),U1(); Rollback Strict 2PL L2(); DENIED GRNTED; RED() := *2 WRITE(); L2(); RED() := *2 WRITE(); U2(); U2(); ommit 21 Summary of Strict 2PL Ensures serializability, recoverability, and avoids cascading aborts Issues: implementation, lock modes, granularity, deadlocks, performance 22 The Locking Scheduler Task 1: -- act on behalf of the transaction dd lock/unlock requests to transactions Examine all RED() or WRITE() actions dd appropriate lock requests On OMMIT/ROLLK release all locks Ensures Strict 2PL! The Locking Scheduler Task 2: -- act on behalf of the system Execute the locks accordingly Lock table: a big, critical data structure in a DMS! When a lock is requested, check the lock table Grant, or add the transaction to the element s wait list When a lock is released, re-activate a transaction from its wait list When a transaction aborts, release all its locks heck for deadlocks occasionally

5 Lock Modes S = shared lock (for RED) X = exclusive lock (for WRITE) Lock Granularity Fine granularity locking (e.g., tuples) High concurrency High overhead in managing locks Lock compatibility matrix: None S X None OK OK OK S OK OK onflict X OK onflict onflict 25 oarse grain locking (e.g., tables, predicate locks) Many false conflicts Less overhead in managing locks lternative techniques Hierarchical locking (and intentional locks) [commercial DMSs] Lock escalation 26 Hierarchical Locking Hierarchical Locking To enable both coarse- and fine-grained locking onsider database as a hierarchy Relations are largest lockable elements Relations consist of blocks locks contain tuples To place a lock on an element, start at the top If at element to lock, get an S or X lock on it If want to lock an element deeper in the hierarchy Leave an intentional lock: IS or IX 27 From Franklin97. See readings SE Spring posted 2016 on course website28 Deadlocks Lock Performance ycle in the wait-for graph: waits for waits for waits for Deadlock detection Timeouts Wait-for graph Deadlock avoidance cquire locks in pre-defined order cquire all locks at once before starting Throughput # ctive Transactions thrashing Why?

6 The Tree Protocol n alternative to 2PL, for tree structures E.g. -trees (the indexes of choice in databases) ecause Indexes are hot spots! 2PL would lead to great lock contention Rules: The Tree Protocol The first lock may be any node of the tree Subsequently, a lock on a node may only be acquired if the transaction holds a lock on its parent Nodes can be unlocked in any order (no 2PL necessary) rabbing First lock parent then lock child Keep parent locked only if may need to update it Release lock on parent if child is not full The tree protocol is NOT 2PL, yet ensures conflict-serializ ability! So far we have assumed the database to be a static collection of elements (=tuples) If tuples are inserted/deleted then the phantom problem appears INSERT INTO Product(name, color) VLUES ( gizmo, blue ) Is this schedule serializable? INSERT INTO Product(name, color) VLUES ( gizmo, blue ) Suppose there are two blue products, X1, X2: R1(X1),R1(X2),W2(X3),R1(X1),R1(X2),R1(X3) INSERT INTO Product(name, color) VLUES ( gizmo, blue ) Suppose there are two blue products, X1, X2: R1(X1),R1(X2),W2(X3),R1(X1),R1(X2),R1(X3) 35 This is conflict serializable SE Spring! What s 2016 wrong?? 36 6

7 INSERT INTO Product(name, color) VLUES ( gizmo, blue ) Suppose there are two blue products, X1, X2: R1(X1),R1(X2),W2(X3),R1(X1),R1(X2),R1(X3) phantom is a tuple that is invisible during part of a transaction execution but not invisible during the entire execution In our example: : reads list of products : inserts a new product : re-reads: a new product appears! Not serializable SE 444 due - Spring to 2016 phantoms In a static database: onflict serializability implies serializability In a dynamic database, this may fail due to phantoms Dealing With Phantoms Lock the entire table, or Lock the index entry for blue If index is available Or use predicate locks lock on an arbitrary predicate Strict 2PL guarantees conflict serializability, but not serializability Dealing with phantoms is expensive! Isolation Levels in SQL 1. Isolation Level: Dirty Reads 1. Dirty reads SET TRNSTION ISOLTION LEVEL RED UNOMMITTED 2. ommitted reads SET TRNSTION ISOLTION LEVEL RED OMMITTED 3. Repeatable reads SET TRNSTION ISOLTION LEVEL REPETLE RED 4. Serializable transactions ID SET TRNSTION ISOLTION LEVEL SERILIZLE 41 Long duration WRITE locks No RED locks Read-only transactions are never delayed Possible pbs: dirty and inconsistent reads 42 7

2. Isolation Level: Read ommitted Long duration WRITE locks Short duration RED locks Only

Isolation Level: Repeatable Read Long duration WRITE locks Long duration RED locks

RED locks Deals with phantoms too lient 1: STRT TRNSTION INSERT INTO SmallProduct(name,

8 2. Isolation Level: Read ommitted Long duration WRITE locks Short duration RED locks Only acquire lock while reading (not 2PL) 3. Isolation Level: Repeatable Read Long duration WRITE locks Long duration RED locks Unrepeatable reads When reading same element twice, may get two different values This is not serializable yet!!! Why? Isolation Level Serializable RED-ONLY Transactions Long duration WRITE locks Long duration RED locks Deals with phantoms too lient 1: STRT TRNSTION INSERT INTO SmallProduct(name, price) SELET pname, price WHERE price <= 0.99 DELETE WHERE price <=0.99 OMMIT lient 2: SET TRNSTION RED ONLY STRT TRNSTION SELET count(*) May improve performance 45 SELET count(*) FROM SmallProduct OMMIT 46 8

CSE 444: Database Internals. Lectures Transactions

CSE 444: Database Internals. Lectures Transactions CSE 444: Database Internals Lectures 13-14 Transactions CSE 444 - Spring 2014 1 Announcements Lab 2 is due TODAY Lab 3 will be released today, part 1 due next Monday HW4 is due on Wednesday HW3 will be