Presentation on theme: "Transactions: 1 Transaction Program unit that accesses the database Executes atomically (all or nothing) and transforms the DB from one consistent state."— Presentation transcript:
Transactions: 1 Transaction Program unit that accesses the database Executes atomically (all or nothing) and transforms the DB from one consistent state to another Solves problems: –integrity constraint violations –system crashes –concurrent updates
Transactions: 2 Transaction State Diagram Active Partially CommittedFailed CommittedAborted All statements executed Transaction abort or system crash Able to guarantee completion Unable to guarantee completion Necessary adjustments made (e.g., rollback)
Transactions: 3 Crash Recovery Logging with Immediate Updates Can update anytime after log records with old/new values have been written to disk.
Transactions: 4 Crash Recovery Example assume actual update done assume log record on disk but update not done assume log record not on disk Do “undo” for each value record on disk -- overwrites changed or unchanged values. 1. Assume the system crashes before the commit as follows: 2. Assume the system crashes after the commit, and all log records are on disk but not all updates are done. “Redo” each value record; overwrite changed and unchanged values.
Transactions: 5 Multiple Transactions Recovery –order serially –redo those committed in serial order –undo those not committed in reverse serial order Checkpoints –flush all records from buffer –do all updates for committed transactions –add to log –subsequently ignore committed transactions before the
Transactions: 6 Concurrent Updates T1T2 read # enrolled in CS1 add 1 write # enrolled add 1 write # enrolled If 10 are initially enrolled, the DB says 11 after these transactions execute, but should say 12.
Transactions: 7 Two-Phase Locking Protocol Strict serial execution (works, but allows no concurrency) 2PLP (equivalent to serial execution, but allows concurrency) –Phase 1: locking—must not unlock –Phase 2: unlocking—must not lock T1T2 LX(N) Read(N) Add 1 to N Write(N) UN(N) LX(N) Read(N) Add 1 to N Write(N) UN(N) Any attempt by T2 to lock or read N here fails. T3 LX(M) Read(M) Add 1 to M Write (M) UN(M) T3 can overlap either T1 or T2 or both
Transactions: 8 Simple Locking is Not Enough T1T2 LX(A) A := A+1 UN(A) LX(A) LX(B) A := A*B UN(A) UN(B) LX(A) LX(B) B := B A UN(A) UN(B) Let A = B = 2 initially. Execute as written: A = 6 B = 4 Execute T1 then T2: A = 3 B = 1 Execute T2 then T1: A = 5 B = 3 Execution as written is not the same as either serial execution. Not 2P
Transactions: 9 Deadlock T1T2 LX(A) LX(B) Try LX(B)Try LX(A) Abort either T1 or T2.
Transactions: 10 Shared Locks Allow Additional Concurrency T1T2T3 LS(A) LX(B) LS(A) UN(B) LS(B) UN(A) LS(B) UN(A) UN(B) UN(A) UN(B) LS: read, but not write Serializable: T2 T1 T3
Transactions: 11 Dirty Reads Allow Even More Concurrency Dirty Data: data written by a transaction that has not yet been committed. Dirty Read: a read of dirty data. Problem: can take action on bogus data. –The dirty data may be rolled back. –May or may not matter (e.g., report of bank balance) Isolation levels control the reading of dirty data (Oracle’s Isolation levels)Oracle’s Isolation levels