A transaction is a collection of database operations that are reliably and efficiently processed as one unit of work. Transactions must have the ACID properties of atomicity, consistency, isolation, and durability. Serializability is an important concept for transactions - a schedule is serializable if it is equivalent to running the transactions in some serial order. Conflict serializability detects conflicting operations between transactions and enforces a serial-equivalent order.

1. Transaction

3. Transaction definition Supports daily operations of an organization Collection of database operations Reliably and efficiently processed as one unit of work No lost data Interference among multiple users Failures

4. Airline Transaction Example START TRANSACTION Display greeting Get reservation preferences from user SELECT departure and return flight records If reservation is acceptable then UPDATE seats remaining of departure flight record UPDATE seats remaining of return flight record INSERT reservation record Print ticket if requested End If On Error: ROLLBACK COMMIT

5. ATM transaction example START TRANSACTION Display greeting Get account number, pin, type, and amount SELECT account number, type, and balance If balance is sufficient then UPDATE account by posting debit INSERT history record Display message and dispense cash Print receipt if requested End If On Error: ROLLBACK COMMIT

7. Transaction Properties Atomic: all or nothing Consistent: database must be consistent before and after a transaction Isolated: no unwanted interference from other users Durable: database changes are permanent after the transaction completes

13. Serializable schedule A serializable schedule is a linear arrangement of the database calls from several transactions with the property: the final database state obtained by executing the calls in schedule order is the same as that obtained by running the transactions in some unspecified serial order .

14. Serializability thru lock A lock is an access privilege on a database object, which the DBMS grant to a particular transaction Exclusive locks prevent any current access. A shared lock lets you read an object, but you need an exclusive lock to update it.

17. Transaction Management with SQL Transaction support is provided by two SQL statements: COMMIT and ROLLBACK. A COMMIT statement is reached, in which case all changes are permanently recorded within the database. The COMMIT statement automatically ends the SQL transaction. A ROLLBACK statement is reached in which case all changes are aborted and the database is rolled back to its previous consistent state.

23. Serializability Testing and Precedence Graphs/Dependency Graph So we need a simple method to test a schedule S and discover whether it is serializable. Simple method involves constructing a directed graph called a Precedence Graph from S Construct a precedence graph as follows: a vertex labelled Ti for every transaction in S an edge from Ti to Tj if any of these three conditions holds: Ti executes write(Q) before Tj executes read(Q) Ti executes read(Q) before Tj executes write(Q) Ti executes write(Q) before Tj executes write(Q) if the graph has a cycle, S is not serializable

24. Compute a precedence graph for schedule B (right) three vertices (T1, T2, T3) edge from Ti to Tj if Ti writes Q before Tj reads Q Ti reads Q before Tj writes Q (T1-T2) Ti writes Q before Tj writes Q

26. Examples of Conflicts A conflict exists when two transactions access the same item, and at least one of the accesses is a write. 1. lost update problem T : transfer $100 from A to C: R(A) W(A) R(C) W(C) S: transfer $100 from B to C: R(B) W(B) R(C) W(C) 2. inconsistent retrievals problem ( dirty reads violate consistency) T : transfer $100 from A to C: R(A) W(A) R(C) W(C) S : compute total balance for A and C : R(A) R(C) 3. nonrepeatable reads T : transfer $100 from A to C: R(A) W(A) R(C) W(C) S : check balance and withdraw $100 from A : R(A) R(A) W(A)

27. Serializable schedule A schedule is a partial ordering of operations for a set of transactions {T,S,...}, such that: The operations of each action execute serially. The schedule specifies an order for conflicting operations. Any two schedules for {T,S,...} that order the conflicting operations in the same way are equivalent . A schedule for {T,S,...} is serializable if it is equivalent to some serial schedule on {T,S,...} . There may be other serializable schedules on {T,S,...} that do not meet this condition, but if we enforce this condition we are safe. Conflict serializability : detect conflicting operations and enforce a serial- equivalent order.

28. Legal Interleaved schedule 1. avoid lost update problem T : transfer $100 from A to C: R(A) W(A) R(C) W(C) S: transfer $100 from B to C: R(B) W(B) R(C) W(C) 2. avoid inconsistent retrievals problem T : transfer $100 from A to C: R(A) W(A) R(C) W(C) S : compute total balance for A and C : R(A) R(C) 3. avoid non-repeatable reads T : transfer $100 from A to C R(A) W(A) R(C) W(C) S : check balance and withdraw $100 from A : R(A) R(A) W(A)

29. Defining legal schedule . To be serializable, the conflicting operations of T and S must be ordered as if either T or S had executed first. We only care about the conflicting operations: everything else will take care of itself. 2. Suppose T and S conflict over some shared item(s) x . 3. In a serial schedule, T ’s operations on x would appear before S ’s, or vice versa....for every shared item x . As it turns out, this is true for all the operations, but again, we only care about the conflicting ones. 4. A legal (conflict-serializable) interleaved schedule of T and S must exhibit the same property. Either T or S “wins” in the race to x ; serializability dictates that the “winner take all”.