Isolation levels. Introduction to Database Design 2012, Lecture 14. Rasmus Ejlers Møgelberg. Questions class about one week before exam

Size: px

Start display at page:

Download "Isolation levels. Introduction to Database Design 2012, Lecture 14. Rasmus Ejlers Møgelberg. Questions class about one week before exam"

Doris Walker
6 years ago
Views:

1 Isolation levels Introduction to Database Design 2012, Lecture 14 End of course Exam - Wednesday June 6, from 9 to 13 - Written exam with all written materials allowed - Make sure that you can do the exercises from the exercise sheets Questions class about one week before exam - I will choose exercises from previous years exams - You should prepare to solve these on board 2

2 What was most interesting? What was most difficult? What was missing? Short informal evaluation 3 Advertisement Fall course Programming Language Principles and Implementations How are Java and C# implemented? - C# in particular delegates and generics - Syntactical analysis of programming languages - Stack machines including JVM or CLR Understanding memory allocation and various constructions in Java and C# Part of programming languages specialisation 4

3 Aborting transactions Isolation levels Implementing serializability Today s lecture 5 Detecting non-serializability T 1 T 2 T 3 T 4 read(c) write(c) read(b) 6

4 A serializable schedule T 1 T 2 T 3 read(b) Conflict equivalent to T 3T1T2 See exercise 2 this week Notice the two conflicting timelines! 7 Transaction model 8

5 When a transaction s Transactions may fail to complete - In case of hardware failure or loss of connection - The application program may choose to abandon transaction - The DBMS may refuse to complete the transaction A failed transaction must be rolled back This means all changes made must be undone Serializability is not enough for a schedule to be safe if we consider risk of failure 9 Unrecoverable schedules T 1 T 2 How do we roll back the changes made by T 1? T 2 s read is called a dirty read T 2 should not be allowed to before T1 10

6 Recoverable schedules T 1 T 2 T is dependent on S if it reads a value written by S while S is still active A recoverable schedule is one where no transaction T s before all transactions it depends on have ted Above we can still force T 2 to when T1 does 11 Cascading rollbacks T 1 T 2 T 3 read(b) write(c) Dirty reads can lead to chains of cascading rollbacks This is unfortunate for efficiency reasons 12

7 Avoiding cascading rollbacks A cascadeless schedule is one with no dirty reads Cascadeless schedules are also recoverable 13 Dirty writes T 1 T 2 A dirty write is a write to a value previously written by an active transaction Complicates rollback - Rollback of T1 should not restore old value of A - Rollback of T2 should restore A as before T1 s write 14

8 Strict schedules Dirty writes do not make roll back impossible But allowing them makes database inefficient A strict schedule is one that disallows dirty reads as well as dirty writes 15 Isolation levels

9 Motivation Suppose we want to compute the total of the balances across all accounts Such a scan may take a while Concurrent transactions could make our computation imprecise Should we disallow concurrent transactions? Or should we accept some inaccuracy? 17 Isolation levels DBMSs allow users to compromise safety in order to gain efficiency Each transaction can be given a lower isolation level than the high default one Correctness then becomes users responsibility Should be used with care 18

10 SQL standard specifies 4 isolation levels - Serializable - Repeatable read - Read ted - Read unted None of these allow dirty writes The higher the more safety The lower the more concurrency Isolation levels 19 Isolation level: Read unted T 1 T 2 No requirement of serializability Dirty reads allowed Schedule above can occur Dirty writes still disallowed 20

11 Isolation level: Read ted T 1 T 2 No requirement of serializability Dirty reads and writes disallowed Two consecutive reads in the same transaction need not give same result This is called non-repeatable read 21 Non-repeatable read problem T 1 T 2 Suppose T 1 is trying to reserve a flight seat What happens if T 2 makes reservation in the meantime? T 2 s update is a lost update First it checks availability then makes reservation 22

Non-repeatable read in practice 23 Non-repeatable reads in practice Selecting seats on airplane Airline allows multiple users to select among available seats at the same time Two users may choose the

12 Non-repeatable read in practice 23 Non-repeatable reads in practice Selecting seats on airplane Airline allows multiple users to select among available seats at the same time Two users may choose the same seat In that case one user is asked to choose another Usually a seat reservation is implemented using two transactions - One to find available seats to show user - One trying to book chosen seat 24

13 Isolation level: Repeatable reads T 1 T 2 read(b) This level guarantees repeatable reads No dirty reads or writes Serializability not guaranteed Above schedule is allowed 25 All schedules are serializable Repeatable reads No dirty reads or writes Isolation level: Serializable T 1 T 2 T 3 read(b) 26

14 Implementations Implementations Two strategies - Optimistic: Assume things will not go wrong Clean up afterwards if they do - Pessimistic Make sure from the beginning that nothing will go wrong Timestamps are optimistic Locks are pessimistic 28

15 Each transaction given a timestamp Timestamps Each data item is given two timestamps - One for the most recent transaction that read the item - One for the most recent transaction that wrote the item Timestamps determine transaction order If a transaction tries e.g. to write an item with a later read timestamp the transaction is rolled back 29 T 1 T 2 start start Timestamp example When T 1 tries to write A the read timestamp of A will be later than T1 s So this can no longer be equivalent to T 1 T2 T 1 will have to roll back 30

16 Locks give exclusive access to data item Locks Only one transaction can have the lock at a time If a transaction needs a lock owned by another transaction it will have to wait DBMS must keep track of locks Usually two types of locks - Read lock - Write lock 31 Two-phase locking T 1 lock(a) lock(b) read(b) release(a) release(b) T 2 lock(a) lock(b) release(a) release(b) Ensures serializability In first phase transactions acquire locks. In second phase it releases them 32

17 T 1 T 2 lock(a) lock(b) lock(b) lock(a) Deadlock Transactions can get stuck waiting for each other One solution is to roll back whenever a deadlock occurs 33 Summary Serializability not enough to ensure safety in case of failure - Recoverability, cascadeless schedules Many DBMSs allow insecure isolation levels for efficiency reasons Implementations of serializability include locks and timestamps More on concurrency in Mobile and Distributed Systems class 34

Chapter 22. Transaction Management

Chapter 22. Transaction Management Chapter 22 Transaction Management 1 Transaction Support Transaction Action, or series of actions, carried out by user or application, which reads or updates contents of database. Logical unit of work on