Transactions. Juliana Freire. Some slides adapted from L. Delcambre, R. Ramakrishnan, G. Lindstrom, J. Ullman and Silberschatz, Korth and Sudarshan

Size: px

Start display at page:

Download "Transactions. Juliana Freire. Some slides adapted from L. Delcambre, R. Ramakrishnan, G. Lindstrom, J. Ullman and Silberschatz, Korth and Sudarshan"

Milton White
5 years ago
Views:

1 Transactions Juliana Freire Some slides adapted from L. Delcambre, R. Ramakrishnan, G. Lindstrom, J. Ullman and Silberschatz, Korth and Sudarshan

2 Motivation Database systems are normally being accessed by many users or processes at the same time Both queries and modifications Banks, online stores, airline reservation systems, search engines, etc. needs to serve multiple customers and applications simultaneously DMBS needs to keep processes from troublesome interactions

3 Example: Bad Interaction You and your spouse each take $100 from different ATM s at about the same time. The DBMS better make sure one account deduction doesn t get lost Compare: An OS allows two people to edit a document at the same time. If both write, one s changes get lost.

4 Transactions Transaction = process involving database queries and/or modification. Normally with some strong properties regarding concurrency. Formed in SQL from single statements or explicit programmer control.

5 ACID Transactions A DBMS is expected to support ACID transactions, which are: Atomic : Either the whole process is done or none is. Consistent : Database constraints are preserved. Isolated : It appears to the user as if only one process executes at a time. Durable : Effects of a process do not get lost if the system crashes. Optional: weaker forms of transactions are often supported as well. Trade-off: amount of concurrency vs. consistency

6 ACID Properties To preserve integrity of data, the database system must ensure:" Atomicity. Either all operations of the transaction are properly reflected in the database or none are. Recovery Consistency. Execution of a transaction in isolation preserves the consistency of the database. Developer Isolation. Although multiple transactions may execute concurrently, each transaction must be unaware of other concurrently executing transactions. Intermediate transaction results must be hidden from other concurrently executed transactions. Concurrency Control Durability. After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures. Recovery

7 Transactions in SQL SQL supports transactions, often behind the scenes Each statement issued at the generic query interface is a transaction by itself AUTO COMMIT mode In programming interfaces like Embedded SQL or PSM, a transaction begins the first time an SQL statement is executed and ends with the program or an explicit end You can also start a transaction explicitly using the statement: BEGIN TRANSACTION The SQL statement COMMIT causes a transaction to complete. Its database modifications are now permanent in the database.

8 ROLLBACK The SQL statement ROLLBACK also causes the transaction to end, but by aborting No effects on the database Failures like division by 0 can also cause rollback, even if the programmer does not request it Rollbacks may also be issued by the system to ensure transactions are executed correctly (more on this later)

9 An Example: Interacting Processes Assume the relation Sells (bookstore,book,price), and suppose that Joe s Bookstore sells only Silberschatz for $2.50 and Ullman for $3.00. Sally is querying Sells for the highest and lowest price Joe charges. Joe decides to stop selling Silberschatz and Ullman, but to sell only Ramakrishnan at $3.50.

10 Sally s Program Sally executes the following two SQL statements, which we call (min) and (max), to help remember what they do. (max) SELECT MAX(price) FROM Sells WHERE bookstore = Joe s bookstore ; (min) SELECT MIN(price) FROM Sells WHERE bookstore = Joe s bookstore ;

11 Joe s Program At about the same time, Joe executes the following steps, which have the mnemonic names (del) and (ins). (del) (ins) DELETE FROM Sells WHERE bookstore = Joe s bookstore ; INSERT INTO Sells VALUES( Joe s bookstore, Ramakrishnan, 3.50);

12 Interleaving of Statements Although (max) must come before (min) and (del) must come before (ins), there are no other constraints on the order of these statements, unless we group Sally s and/or Joe s statements into transactions. Sally s program (max) (min) Joe s program (del) (ins) Some possible interleavings: (max) (min) (del) (ins) (max) (del) (ins) (min) (max) (del) (min) (ins)

13 Example: Strange Interleaving Suppose the steps execute in the order (max)(del)(ins)(min) Joe s Prices: Statement: Result: {2.50, 3.00} (max) 3.00 {2.50, 3.00} (del) (ins) {3.50} (min) 3.50 Silberschatz for $2.50 and Ullman for $3.00 Ramakrishnan for $3.50 Sally sees MAX < MIN!

14 Fixing the Problem With Transactions If we group Sally s statements (max)(min) into one transaction, then she cannot see this inconsistency She see s Joe s prices at some fixed time Either before or after he changes prices, or in the middle, but the MAX and MIN are computed from the same prices

15 Another Problem: Rollback Suppose Joe executes (del)(ins), but after executing these statements, thinks better of it and issues a ROLLBACK statement If Sally executes her transaction after (ins) but before the rollback, she sees a value, 3.50, that never existed in the database Silberschatz for $2.50 and Ullman for $3.00 Ramakrishnan for $3.50

16 Solution If Joe executes (del)(ins) as a transaction, its effect cannot be seen by others until the transaction executes COMMIT If the transaction executes ROLLBACK instead, then its effects can never be seen

17 Isolation Levels SQL defines four isolation levels = choices about what interactions are allowed by transactions that execute at about the same time How a DBMS implements these isolation levels is complex, and a typical DBMS provides its own options Only one level ( serializable ) = ACID transactions

18 Choosing the Isolation Level Within a transaction, we can say: SET TRANSACTION ISOLATION LEVEL X where X = SERIALIZABLE REPEATABLE READ READ COMMITTED READ UNCOMMITTED

19 Sally s Program Sally executes the following two SQL statements, which we call (min) and (max), to help remember what they do. (max) SELECT MAX(price) FROM Sells WHERE bookstore = Joe s bookstore ; (min) SELECT MIN(price) FROM Sells WHERE bookstore = Joe s bookstore ;

20 Joe s Program At about the same time, Joe executes the following steps, which have the mnemonic names (del) and (ins) (del) DELETE FROM Sells WHERE bookstore = Joe s bookstore ; (ins) INSERT INTO Sells VALUES( Joe s bookstore, Ramakrishnan, 3.50);

21 Serializable Transactions If Sally = (max)(min) and Joe = (del)(ins) are each transactions, and Sally runs with isolation level SERIALIZABLE, then she will see the database either before or after Joe runs, but not in the middle. It s up to the DBMS vendor to figure out how to do that, e.g.: True isolation in time Keep Joe s old prices around to answer Sally s queries SERIALIZABLE is the default

22 A Slight Detour Schedule: Time-ordered sequence of actions taken by one or more transactions Actions: read and write in main-memory buffers A schedule for a set of transactions must consist of all instructions of those transactions A schedule must preserve the order in which the instructions appear in each individual transaction Not all schedules (concurrent executions) result in a correct state

23 Concurrency Control Ensures that any schedule that gets executed will leave the database in a consistent state Notion of correctness based on equivalence to serial schedules Correctness principle: Each transaction preserves database consistency, thus serial execution of a set of transactions preserves database consistency

24 Assuring Serializable Behavior Impossible to require that operations run serially Very low throughput! DBMS assures serializable behavior even if the execution of transactions is not serial But the results looks to users as if they were A schedule is serializable if it is equivalent to a serial schedule Common approach: lock database elements If t1 locks element A, t2 can run in parallel if it does not need A

25 Conflicting Instructions Instructions li and lj of transactions Ti and Tj respectively, conflict if and only if there exists some item Q accessed by both li and lj, and at least one of these instructions wrote Q. 1. li = read(q), lj = read(q). li and lj don t conflict. 2. li = read(q), lj = write(q). They conflict. 3. li = write(q), lj = read(q). They conflict 4. li = write(q), lj = write(q). They conflict A conflict between li and lj forces a (logical) temporal order between them

26 Conflict Serializability If a schedule S can be transformed into a schedule S by a series of swaps of non-conflicting instructions, we say that S and S are conflict equivalent We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule

27 Conflict Serializability: Example Schedule 3 is conflict serializable. Why? Schedule 3

28 Conflict Serializability (Cont.) T1 R(A) W(A) R(B) W(B) T2 R(A) W(A) R(B) W(B) T1 R(A) W(A) R(B) W(B) T2 R(A) W(A) R(B) W(B) T1 R(A) W(A) R(B) W(B) T2 R(A) W(A) R(B) W(B) T1 R(A) W(A) R(B) W(B) T2 R(A) W(A) R(B) W(B) Schedule 3 Schedule 3 is conflict serializable!

29 Isolation Level Is Personal Choice Your choice, e.g., run serializable, affects only how you see the database, not how others see it! Example: If Joe Runs serializable, but Sally doesn t, then Sally might see no prices for Joe s bookstore i.e., it looks to Sally as if she ran in the middle of Joe s transaction You decide what is acceptable for your application

30 Read-Committed Transactions SET TRANSACTION ISOLATION LEVEL READ COMMITTED If Sally runs with isolation level READ COMMITTED, then she can see only committed data, but not necessarily the same data each time Example: Under READ COMMITTED, the interleaving (max)(del)(ins)(min) is allowed, as long as Joe commits (max) {(del),(ins),commit)} (min) Sally sees MAX < MIN.

31 Repeatable-Read Transactions SET TRANSACTION ISOLATION LEVEL REPEATABLE READ Requirement is like read-committed, plus: if data is read again, then everything seen the first time will be seen the second time But the second and subsequent reads may see more tuples as well

32 Example: Repeatable Read Suppose Sally runs under REPEATABLE READ, and the order of execution is (max)(del)(ins)(min) (max) sees prices 2.50 and 3.00 (min) can see 3.50, but must also see 2.50 and 3.00, because they were seen on the earlier read by (max) New inserted tuples are called phantoms

33 Read Uncommitted SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED A transaction running under READ UNCOMMITTED can see data in the database, even if it was written by a transaction that has not committed (and may never) Allows dirty reads Example: If Sally runs under READ UNCOMMITTED, she could see a price 3.50 even if Joe later aborts

34 Choosing a Seat EXEC SQL BEGIN DECLARE SECTION; int flight; /* flight number */ char date[10]; /* flight date */ char seat[3]; /* seat number */ int occ; /* boolean to tell if seat is occupied */ EXEC SQL END DECLARE SECTION; void chooseseat() { /* some code to prompt user to enter a flight, date, a seat and store these in the variables defined above */ EXEC SQL SELECT occupied INTO :occ FROM Flights WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; If (!occ) { EXEC SQL UPDATE Flights SET occupied = TRUE WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; /* code to record seat assignment and inform user */ } else /* msg indicating unavailability of requested seat */ } What happens if two agents try to select seat 22A on flight 90 on 10/1/2008?

35 EXEC SQL BEGIN DECLARE SECTION; int flight; /* flight number */ char date[10]; /* flight date */ char seat[3]; /* seat number */ int occ; /* boolean to tell if seat is occupied */ EXEC SQL END DECLARE SECTION; Choosing a Seat void chooseseat() { /* some code to prompt user to enter a flight, date, a seat and store these in the variables defined above */ EXEC SQL SELECT occupied INTO :occ FROM Flights WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; If (!occ) { EXEC SQL UPDATE Flights SET occupied = TRUE WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; /* code to record seat assignment and inform user */ } else /* msg indicating unavailability of requested seat */ } User1 finds seat empty User1 sets seat 22A occupied Each operation is performed correctly, but the global result is not correct: both customers think they have seat 22A How can we prevent this? Use transactions! User2 finds seat empty User2 sets seat 22A occupied

36 Choosing a Seat: Now in a transaction EXEC SQL BEGIN DECLARE SECTION; int flight; /* flight number */ char date[10]; /* flight date */ char seat[3]; /* seat number */ int occ; /* boolean to tell if seat is occupied */ EXEC SQL END DECLARE SECTION; void chooseseat() { /* some code to prompt user to enter a flight, date, a seat and store these in the variables defined above */ EXEC SQL START TRANSACTION EXEC SQL SELECT occupied INTO :occ FROM Flights WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; If (!occ) { EXEC SQL UPDATE Flights SET occupied = TRUE WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; /* code asking customer to confirm the seat */ If (answer) Else /* change occupied back to FALSE */ EXEC SQL COMMIT /* code to record seat assignment and inform user */ } else /* msg indicating unavailability of requested seat */ } User1 finds seat empty User1 sets seat 22A occupied User2 finds seat empty User2 sets seat 22A occupied The global result is correct. But is this efficient?

37 Choosing a Seat: Now in a transaction EXEC SQL BEGIN DECLARE SECTION; int flight; /* flight number */ char date[10]; /* flight date */ char seat[3]; /* seat number */ int occ; /* boolean to tell if seat is occupied */ EXEC SQL END DECLARE SECTION; void chooseseat() { /* some SET code TRANSACTION to prompt user READ to enter WRITE a flight, date, a seat and ISOLATION store these LEVEL in the READ variables UNCOMMITTED defined above */ EXEC SQL START TRANSACTION EXEC SQL SELECT occupied INTO :occ FROM Flights WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; If (!occ) { EXEC SQL UPDATE Flights SET occupied = TRUE WHERE fltnum = :flight AND fltdate=:date AND fltseat=:seat; /* code asking customer to confirm the seat */ If (answer) Else /* change occupied back to FALSE */ EXEC SQL COMMIT /* code to record seat assignment and inform user */ } else /* msg indicating unavailability of requested seat */ } What happens if we allow dirty reads? Dirty read Speeds up average processing time Can always run the transaction again

38 Atomicity: A Bank Transfer EXEC SQL BEGIN DECLARE SECTION; int acct1, acct2; /* the two accounts */ int balance1; /* amt of money in acct1 */ int amt; /* amt of money to transfer */ EXEC SQL END DECLARE SECTION; void transfer() { /* some code to prompt user to enter accts 1 and 2 and xfer amt */ EXEC SQL SELECT balance INTO :balance1 FROM Accounts WHERE acctno = :acct1; If (balance1>=amt) { EXEC SQL UPDATE Accounts SET balance += :amt WHERE acctno = :acct2; EXEC SQL UPDATE Accounts SET balance -= :amt WHERE acctno = :acct1; } else /* msg indicating insufficient funds */ } Failure What happens if the computer fails after the 1 st update? Database is now in an inconsistent state How can we prevent this? Two updates must be performed atomically!

39 Read-Only Transactions When transactions read and write, they are prone to serialization problems If transaction only reads, there is more freedom to let it execute in parallel with other transactions SET TRANSACTION READ ONLY; SET TRANSACTION READ WRITE; default

40 Transactions and Constraints A transaction can only succeed if it leaves the database in a consistent state No constraints are violated

41 Example create table Teaches ( Cname varchar(30), Year int, foreign key (Pname) references Professor(Pname), foreign key (Cname) references Course(Cname) ); create table Professor ( Pname varchar(30), Paddr varchar(100), primary key (Pname) ); create table Course ( Cname required int, primary key (Cname) ); varchar(30),

42 Example: Constraints and Transactions Constraint: Every faculty member must teach at least two courses every year New year has come, new schedule is being prepared: insert into Teaches values (silva,algorithms,2006); rejected!

43 Example: Constraints and Transactions Constraint: Every faculty member must teach at least two courses every year Solution: group updates together START TRANSACTION insert into Teaches values (silva,algorithms,2006); insert into Teaches values (silva,advalgorithms,2006); COMMIT; tell DBMS to check constraints only after transaction is committed

44 Deferring the Checking of Constraints Any constraint may be declared DEFERRABLE or NOT DEFERRABLE NOT DEFERRABLE: default Constraint checked immediately after modification DEFERRABLE Constraint checked after transaction is finished

45 Another Example create table Teaches ( Cname varchar(30), Year int, foreign key (Pname) references Professor(Pname), foreign key (Cname) references Course(Cname) ); create table Professor ( Pname varchar(30), Paddr varchar(100), primary key (Pid) ); create table Course ( Cname required int, primary key (Cname) ); varchar(30), insert into Teaches values (silva,algorithms,2005); insert into Professor values (1,'silva','salt lake city'); Judicious ordering can help

46 One Last Example create table Teaches ( Cname varchar(30), Year int, foreign key (Pname) references Professor(Pname), foreign key (Cname) references Course(Cname) ); create table Professor ( Pname varchar(30), Paddr varchar(100), primary key (Pid) ); create table Course ( Cname required int, primary key (Cname) varchar(30), foreign key (Cname) references Teaches(Cname) ); Judicious ordering does not work if there are cyclic dependencies! insert into Teaches values (silva,algorithms,2005); insert into Course values (algorithms,1);

47 One Last Example create table Teaches ( Cname varchar(30), Year int, foreign key (Pname) references Professor(Pname), foreign key (Cname) references Course(Cname) DEFERRABLE INITIALLY DEFERRED ); create table Professor ( Pname varchar(30), Paddr varchar(100), primary key (Pid) ); create table Course ( Cname varchar(30), required int, primary key (Cname) foreign key (Cname) references Teaches(Cname) DEFERRABLE INITIALLY DEFERRED ); Judicious ordering does not work if there are cyclic dependencies! START TRANSACTION insert into Teaches values (silva,algorithms,2005); insert into Course values (algorithms,1); COMMIT

Transactions. The Setting. Example: Bad Interaction. Serializability Isolation Levels Atomicity

Transactions. The Setting. Example: Bad Interaction. Serializability Isolation Levels Atomicity Transactions Serializability Isolation Levels Atomicity 1 The Setting Database systems are normally being accessed by many users or processes at the same time. Both queries and modifications. Unlike Operating