Transactions Controlling Concurrent Behavior Lecture 13 Sub-sets of SQL Data retrieval: SELECT Data Manipulation Language (DML): INSERT, UPDATE, DELETE Data Definition Language (DDL): CREATE, ALTER, DROP, RENAME • Transaction control: COMMIT, ROLLBACK Data Control Language (DCL): GRANT, REVOKE Busy, busy, busy... • In production environments, it is unlikely that we can limit our system to just one user at a time. – Consequently, it is possible for multiple queries to be submitted at approximately the same time. • If all of the queries were very small (i.e., in terms of time), we could probably just execute them on a first-come-first- served basis. • However, many queries are both complex and time consuming. – Executing these queries would make other queries wait a long time for a chance to execute. • So, in practice, the DBMS may be running many different queries at about the same time. Concurrency: two people—one bank account problem • Before withdrawing money, each needs to check if the balance is sufficient • Initially there is 100$ on the account Ryan Monica Balance1 = r(Ryan) 100 Balance2 = r(Monica) 100 Balance2 -= 50 w(Monica) Balance2 50 Balance1 -= 100 w(Ryan) Balance1 0 In fact, the withdrawn amount is 150$ The problem is that the reading and writing operations should be performed as one transaction, their combination should be atomic Transactions • DBMS groups your SQL statements into transactions. • A transaction (ORACLE) consists of series of DML statements, one DDL statement or one DCL statement • By default, your transaction starts with the first executable SQL statement that you issue. The transaction ends when one of the following occurs: – A COMMIT or ROLLBACK are issued – A DDL (CREATE, ALTER, DROP …) or DCL (GRANT, REVOKE) statement is issued – A user properly exits (COMMIT) – System crashes (ROLLBACK) • Once the transaction ends, a new transaction starts with your next executable statement AUTOCOMMIT • Environment variable AUTOCOMMIT is by default set to OFF • A user can set it to SET AUTOCOMMIT ON SET AUTOCOMMIT IMMEDIATE and every SQL statement is written to disk as soon as it is issued. Every statement becomes a transaction • In the middle of transaction, the user can see the changed data by issuing SELECT queries. The user is getting the data from the temporary storage area. Other users cannot see the changes until transaction has been committed Concurrent Modifications • Unlike operating systems, which support interaction of processes, a DMBS needs to keep processes from troublesome interactions. • Even when there is no “failure,” several transactions can interact to turn a consistent state into an inconsistent state. COMMIT and ROLLBACK • The SQL statement COMMIT causes a transaction to complete. – It’s database modifications are now permanent in the database. • The SQL statement ROLLBACK also causes the transaction to end, but by aborting. – No effects on the database. • Failures like division by 0 or a constraint violation can also cause rollback, even if the programmer does not request it. ACID Transactions • ACID transactions are: – Atomic : Whole transaction or none is done. – Consistent : Database constraints preserved. – Isolated : It appears to the user as if only one process executes at a time. • That is, even though actions of several transactions might be interleaved, the net effect is identical to executing all transactions one after another in some serial order. – Durable : Effects of a process survive a crash. • Optional: weaker forms of transactions are often supported as well. Interleaving • For performance reasons, a DBMS has to interleave the actions of several transactions. However, the interleaving must be done carefully… • Consider two transactions T1 and T2, each of which, when running alone preserves database consistency: – T1 transfers $100 from A to B, and – T2 increments both A and B by 1% (e.g. daily interest) – Consider the following interleaving. (1) T1 deducts $100 from A, (2) T2 increments both A and B by 1%, (3) T1 adds $100 to B. – What’s the problem? – B just lost $1. Transactions and Schedules • A transaction is a list of actions. The actions could be: – read, write, commit, abort • A schedule is a list of actions from a set of transactions. E.g. T1 T2 r(A) w(A) r(B) w(B) commit r(C) w(C) commit Anomalies: Reading Uncommitted Data T1 T2 r(A) w(A) r(A) w(A) r(B) w(B) commit r(B) w(B) commit • T1 transfers $100 from A to B, and • T2 increments both A and B by 1% (e.g. daily interest) • The problem is that the bank didn’t pay interest on the $100 that was being transferred. • Of course there would be no problem if we executed T1 and after that T2, or vice versa. Anomalies: Unrepeatable Reads • Suppose that A is the number of copies available for a book. • Transactions T1 and T2 both place an order for this book. First they check the availability of the book. • Consider now the following: 1. T1 checks whether A is greater than 1. Suppose T1 sees (reads) value 1. 2. T2 also reads A and sees 1. 3. T2 decrements A to 0. 4. T2 commits. 5. T1 tries to decrement A, which is now 0, and gets an error because some integrity check doesn’t allow it. • This situation can never arise in a serial execution of T1 and T2. Anomalies: Overwriting uncommitted data • Suppose that Larry and Harry are two employees, and their salaries must be kept equal. • T1 sets their salaries to $1000 and • T2 sets their salaries to $2000. • Now consider the following schedule: T1 T2 r(Larry) w(Larry) r(Harry) w(Harry) r(Harry) $1000 to Harry w(Harry) r(Larry) $2000 to Larry w(Larry) commit commit Unfortunately, Harry will be paid less than Larry. Summarizing the Terminology • A transaction (model) is a sequence of r and w actions on database elements. • A schedule is a sequence of reads/writes actions performed by a collection of transactions. • Serial Schedule = All actions for each transaction are consecutive. r1(A); w1(A); r1(B); w1(B); r2(A); w2(A); r2(B); w2(B); … • Serializable Schedule: A schedule whose “effect” is equivalent to that of some serial schedule. We will introduce a sufficient condition for serializability. Conflicts • There is a conflict if two transactions (i.e. ri, rj, wi, or wj ) access the same data (X or Y) and at least one of them is a write. • ri(X); rj(Y) ≡ rj(Y); ri(X) – i.e. we can always flip ri(X); rj(Y) (even when X=Y). • We can flip ri(X); wj(Y) as long as X≠Y • However, ri(X); wj (X) wj(X); ri (X) – In the RHS, Ti reads the value of X written by Tj, whereas it is not so in the LHS. • We can flip wi(X); wj(Y); provided X≠Y • However, wi(X); wj(X) wj(X); wi(X); – The final value of X may be different depending on which write occurs last. Conflicts (Cont’d) Summarizing, there is a conflict if one of these two conditions hold. 1. A read and a write of the same X, or 2. Two writes of the same X • Such actions conflict in general and may not be swapped in order. • All other events (reads/writes) may be swapped without changing the effect of the schedule (on the DB). Definition • A schedule is conflict-serializable if it can be converted into a serial schedule by a series of non-conflicting swaps of adjacent elements Example r1(A); w1(A); r2(A); w2(A); r1(B); w1(B); r2(B); w2(B) r1(A); w1(A); r2(A); w2(A); r1(B); w1(B); r2(B); w2(B) r1(A); w1(A); r2(A); r1(B); w2(A); w1(B); r2(B); w2(B) r1(A); w1(A); r1(B); r2(A); w2(A); w1(B); r2(B); w2(B) r1(A); w1(A); r1(B); r2(A); w1(B); w2(A); r2(B); w2(B) r1(A); w1(A); r1(B); w1(B); r2(A)w2(A); r2(B); w2(B) Conflict-serializability • Sufficient condition for serializability but not necessary. Example S1: w1(Y); w1(X); w2(Y); w2(X); w3(X); -- This is serial S2: w1(Y); w2(Y); w2(X); w1(X); w3(X); • S2 isn’t conflict serializable, but it is serializable. It has the same effect as S1. – Intuitively, the values of X written by T1 and T2 have no effect, since T3 overwrites them. Serializability/precedence Graphs • Non-swappable pairs of actions represent potential conflicts between transactions. • The existence of non-swappable actions enforces an ordering on the transactions that include these actions. • Nodes: transactions {T1,…,Tk} • Arcs: There is an arc from Ti to Tj if they have conflict access to the same database element X and Ti is first; in written Ti <S Tj. Precedence graphs example 1 r2(A); r1(B); w2(A); r3(A); w1(B); w3(A); r2(B); w2(B) Note the following: .w1(B) <S r2(B) .r2(A) <S w3(A) 1 2 3 These are conflicts since they contain a read/write Conflict serializable on the same element They cannot be swapped. Therefore T1 < T2 < T3 21 Precedence graphs example 2 r2(A); r1(B); w2(A); r2(B); r3(A); w1(B); w3(A); w2(B) Note the following: .r1(B) <S w2(B) 1 2 3 .w2(A) <S w3(A) .r2(B) <S w1(B) Not conflict serializable Here, we have T1 < T2 < T3, but we also have T2 < T1 22 • If there is a cycle in the graph – Then, there is no serial schedule which is conflict- equivalent to S.