Transaction Processing John Ortiz

Transaction Processing Introduction Transactions are motivated by two of the properties of DBMS's discussed way back in our first lecture: Multi-user database access Safe from system crashes Main issues: How to model concurrent execution of user programs? How to guarantee acceptable DB behavior? How to deal with system crashes? Lecture 19 Transaction Processing

Transaction Processing Why Concurrency? Allowing only serial execution of user programs may cause poor system performance Low throughput, long response time Poor resource utilization (CPU, disks) Concurrent execution of user programs is essential for good DBMS performance. Because disk accesses are frequent, and relatively slow, it is important to keep the CPU humming by working on several user programs concurrently Lecture 19 Transaction Processing

Example: Why Concurrency? Assume each users’ program uses CPU and I/O resources (disks) in an interleaved fashion: CPU, R(X), CPU, W(X) Suppose each CPU request takes 1 time unit and each I/O request takes 5 time units. For a 2 GHz Machine, one clock tick is ½ ns An 8 millisecond seek time is 8000 microseconds, which is 8,000,000 ns Clearly the CPU can get quite a bit done while the disk is searching for a block Lecture 19 Transaction Processing

Example: Why Concurrency? T1 T2 T3 T4 Time CPU I/O Serial schedule Time units = 48 T1 T2 T3 T4 Time CPU I/O Non-serial schedule Time units = 41 Lecture 19 Transaction Processing

Example: Why Concurrency? T1 T2 T3 T4 Time CPU I/O Serial schedule Time units = 48 T1 T2 T3 T4 Time CPU I/O 1 I/O 2 Non-serial schedule Time units = 22 Use 2 disks Lecture 19 Transaction Processing

Transaction Processing A user program may carry out many operations on data retrieved from database, but DBMS is only concerned about what data is read/written from/to the database (on disk) A transaction is a sequence of database actions that is considered as a unit of work DB actions: read (R(X)), write (W(X)), commit, abort Represent DBMS’s abstract view of Interact user sessions Execution of user programs Lecture 19 Transaction Processing

Transaction Processing Example: Transaction Account(Ano, Name, Type, Balance) A user want to update Account set Balance = Balance – 50 where Ano = 10001 update Account set Balance = Balance + 50 where Ano = 12300 Let A be account w/ Ano=10001, B be account w/ Ano=12300. The transaction is R(A), W(A), R(B), W(B) Lecture 19 Transaction Processing

States of a Transaction active commit partially committed failed aborted abort failure exception end transaction begin read/write Lecture 19 Transaction Processing

Begin, Active, and Commit begin transaction : the first SQL query at the beginning of a program or a user session, or after the commitment of an earlier transaction Active : running SQL queries & updates. Operate on data in buffer or on disk Partially-committed : just before “commit work” is executed. All operations of the transaction have been done (in the memory buffer or on disk) but not yet final. Committed : after “commit work” is executed. Data updates have been made permanent. Lecture 19 Transaction Processing

Transaction Processing Failed and Aborted Failed : after an exception is encountered. Normal execution is interrupted. Can be Programmed DBMS enforced (e.g., for concurrency control) System failure: power failure, disk crashes, Aborted : after “rollback work” is executed. All actions of the transaction have been undone and the database has been restored to its state prior to the start of the transaction. Lecture 19 Transaction Processing

Consistency of Transaction Each transaction must leave the database in a consistent state if the DB is consistent when the transaction begins. DBMS will enforce some ICs, depending on the ICs declared in CREATE TABLE statements. Beyond this, the DBMS does not really understand the semantics of the data. (e.g., it does not understand how the interest on a bank account is computed). Lecture 19 Transaction Processing

Atomicity of Transactions A transaction might commit after completing all its actions, or it could abort (or be aborted by the DBMS) after executing some actions. A very important property guaranteed by the DBMS for all transactions is that they are atomic. That is, a user can think of a transaction as always executing all its actions in one step, or not executing any actions at all. DBMS logs all actions so that it can undo the actions of aborted transactions. Lecture 19 Transaction Processing

Example: Why Atomicity? Account(Ano, Name, Type, Balance) A user want to update Account set Balance = Balance – 50 where Ano = 10001 update Account set Balance = Balance + 50 where Ano = 12300 System crashed in the middle Possible outcome w/o recovery: $50 transferred or lost The operations must be done as a unit Lecture 19 Transaction Processing

Transaction Processing Durability DBMS often save data in main memory buffer to improve system efficiency. Data in buffer is volatile (may get lost if system crashes) When a transaction commits, DBMS must guarantee that all updates make by the transaction will not be lost even if the system crashes later DBMS uses the log to redo actions of committed transactions if necessary Lecture 19 Transaction Processing

Transaction Processing Isolation Users submit transactions, and can think of each transaction as executing by itself (in isolation) Concurrency is achieved by the DBMS, which interleaves actions (reads/writes of DB objects) of various transactions DBMS guarantees that interleaving transactions do not interfere with each other Lecture 19 Transaction Processing

Example: Why Isolation? Two users (programs) do this at the same time User 1: update Student set GPA = 3.7 where SID = 123 User 2: update Student set Major = ‘CS’ where SID = 123 Sequence of events: for each user, read tuple, modify attribute, write tuple. Possible outcomes w/o concurrency control: one change or both Lecture 19 Transaction Processing

Example: Why Isolation? Emp(EID, Name, Dept, Sal, Start, Loc) User 1: update Emp set Dept = ‘Sales’ where Loc = ‘Downtown' User 2: update Emp set Start = 3/1/00 where Start = 2/29/00 Possible outcomes w/o concurrency control: each tuple has one change or both, may be inconsistent across tuples Lecture 19 Transaction Processing

Example: Interleaved Transactions Consider two transactions: T1: BEGIN A=A+100, B=B-100 END T2: BEGIN A=1.06*A, B=1.06*B END One possible interleaved execution: T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B It is OK. But what about another interleaving? T1: A=A+100, B=B-100 T2: A=1.06*A, B=1.06*B Lecture 19 Transaction Processing

Schedule: Modeling Concurrency Schedule: a sequence of operations from a set of transactions, where operations from any one transaction are in their original order Notation: Ri(X): read X by Ti Wi(X): write X by Ti R1(A), W1(A), R2(B), W2(B), R1(C), W1(C) Lecture 19 Transaction Processing

Transaction Processing Schedule (cont.) Represents some actual sequence of database actions. In a complete schedule, each transaction ends in commit or abort. A schedule transforms database from an initial state to a final state Initial state Final state A schedule Lecture 19 Transaction Processing

Transaction Processing Schedule (cont.) Assume a consistent initial state A representation of an execution of operations from a set of transactions Ignore aborted transactions Incomplete (not yet committed) transactions Operations in a schedule conflict if They belong to different transactions They access the same data item At least one item is a write operation Lecture 19 Transaction Processing

Anomalies with Concurrency Interleaving transactions may cause many kinds of consistency problems Reading Uncommitted Data ( “dirty reads”): R1(A), W1(A), R2(A), W2(A), C2, R1(B), A1 Unrepeatable Reads: R1(A), R2(A), W2(A), C2, R1(A), W1(A), C1 Overwriting Uncommitted Data (lost update): R1(A), R2(A), W2(A), W1(A) Lecture 19 Transaction Processing

Anomalies with Concurrency Incorrect Summary Problem Data items may be changed by one transaction while another transaction is in the process of calculating an aggregate value A correct “sum” may be obtained prior to any change, or immediately after any change Lecture 19 Transaction Processing

Transaction Processing Serial Schedule An acceptable schedule must transform database from a consistent state to another consistent state Serial schedule : one transaction runs entirely before the next transaction starts. T1: R(X), W(X) T2: R(X), W(X) R1(X) W1(X) C1 R2(X) W2(X) C2 Serial R2(X) W2(X) C2 R1(X) W1(X) C1 R1(X) R2(X) W2(X) W1(X) C1 C2 Non-serial Lecture 19 Transaction Processing

Serial Schedule IS Acceptable Serial schedules guarantee transaction isolation & consistency Different serial schedules can have different final states N transactions may form N! different serial schedules Any state from a serial schedule is acceptable – DBMS makes no guarantee about the order in which transactions are executed Lecture 19 Transaction Processing

Example: Serial Schedules T1: R(X), X=X+10, W(X) T2: R(X), X=X*2, W(X) Final X = 60 R1(X) W1(X) C1 R2(X) W2(X) C2 S1: Initial X = 20 Final X = 50 S2: R2(X) W2(X) C2 R1(X) W1(X) C1 Lecture 19 Transaction Processing

Is Non-Serial Schedule Acceptable? T1: R(X), X=X*2, W(X), R(Y), Y=Y-5, W(Y) T2: R(X), X=X+10, W(X) R1(X) W1(X) R2(X) W2(X) R1(Y) W1(Y) C1 C2 S1: final X=50 Y=30 Initial X=20 Y=35 R1(X) W1(X) R1(Y) W1(Y) C1 R2(X) W2(X) C2 S2: Lecture 19 Transaction Processing

Serializable Schedules Serializable schedule: Equivalent to a serial schedule of committed transactions. Non-serial (allow concurrent execution) Acceptable (final state is what some serial schedule would have produced) Types of Serializable schedules: depend on how the equivalency is defined Conflict: based on conflict operations View: based on viewing of data Ex: p.645, text does not show commits Lecture 19 Transaction Processing

Lock-Based Concurrency Control Strict Two-phase Locking (Strict 2PL) Protocol: Each transaction must obtain a S (shared) lock on object before reading, and an X (exclusive) lock on object before writing. All locks held by a transaction are released when the transaction completes If a transaction holds an X lock on an object, no other transaction can get a lock (S or X) on that object. Strict 2PL allows only serializable schedules. Lecture 19 Transaction Processing

Transaction Processing Cascading Aborts When a transaction aborts, all its actions are undone. DBMS uses a log to keep track of actions of each transaction If T1 reads uncommitted data written by T2 (dirty read) and T2 must aborted, then T1 must also be aborted (cascading aborts) T1: R(A) W(A) … Abort T2: R(A) W(A) … Cascadeless schedule: transactions only read data from committed transactions Lecture 19 Transaction Processing

Transaction Processing Recoverability If a transaction fails, the DBMS must return the DB to its previous state Computer failure – hw, sw, network, memory error Transaction error – erroneous input, divison by zero Local errors – insufficient funds, data not found Concurrency control enforcement – transaction aborted Disk failure – hard disk crash (listed in text but not much different from 1.) Physical catastrophe – power, theft, fire, etc. Lecture 19 Transaction Processing

Transaction Processing Recoverability If T1 reads data from T2, commits and then T2 needs to abort, what should DBMS do? This situation is undesirable! A schedule is recoverable if very transaction commits only after all transactions from which it reads data commit. Cascadeless schedules are recoverable (but not vice-versa!). Real systems typically ensure that only recoverable schedules arise (through locking). Lecture 19 Transaction Processing

Transaction Processing Summary Transactions model DBMS’ view of user programs Concurrency control and recovery are important issues in DBMSs Transactions must have ACID properties Atomicity Consistency Isolation Durability C & I are guaranteed by concurrency control A & D are guaranteed by crash recovery Lecture 19 Transaction Processing

Transaction Processing Summary (cont.) Schedule models concurrent execution of transactions Conflicts arise when two transactions access the same object, and one of the transactions is modifying it Serial execution is our model of correctness Serializability allows us to “simulate” serial execution with better performance Concurrent execution should avoid cascade abort and be recoverable Lecture 19 Transaction Processing