1. 02/23/2005Yan Huang - CSCI5330 Database Implementation – Transaction Transaction

2. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Outline Transaction and OLTP Desired properties of transactions Schedule Concurrent transactions and their properties

3. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Transaction A multi-billion dollar business OLTP http://www.tpc.org/default.asp

4. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Transaction Definition A unit of program execution that accesses and possibly updates various data items Transactions?  Book an airline ticket from DFW to Paris  Buy “The Dilbert Principle” from amazon.com  Sell 1000 shares of LU from your ameritrade account  Withdraw $100 from a ATM machine  Issue a SQL statement to sqlplus of Oracle 9i  Look at your grade of homework 3  Check out your groceries at Walmart

5. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Transaction Concept A transaction is a unit of program execution that accesses and possibly updates various data items. Two main issues to deal with:  Failures of various kinds, such as hardware failures and system crashes  Concurrent execution of multiple transactions a 1, a 2, a 3, a 4, …, a n, commit Database may be inconsistentconsistent c 1, c 2, c 3, c 4, …, c l, commit b 1, b 2, b 3, b 4, …, b m, commit a 1, a 2, a 3, a 4, …, a n, commit

6. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Challenges to Maintain Transactions Hardware failures  Cashed stuck in ATM machine  Power failure… Software failures  Programming errors  System crash… User interference  Termination of transactions Concurrent users  Multiple users accessing the same item

7. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Designed Properties of Database Systems Atomicity Consistency Isolation Durability

8. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Atomicity Transaction needs to be executed as a unit Example  You should not cause the quantity of “The Dilbert Principle” of amazon.com decrease if you place your order and the order does not get through due to server errors Who are responsible for atomicity?  Transaction management system and  Recovery system

9. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Example of Fund Transfer Transaction to transfer $50 from account A to account B: 1. read(A) 2. A := A – 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B) 7. commit

10. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Atomicity Either all operations of the transaction are properly reflected Or none are (1) read(A), (2)A := A -50,(3)write(A), (4) read(B), (5)B := B + 50, (6)write(B), (7) commit (1) read(A), (2)A := A -50,(3)write(A), (4) read(B), (5)B := B + 50

11. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Consistency Database implicit/explicit constraints need to be maintained Example:  Transferring money from one account to another in the same bank should not change your total amount of money Who are responsible for consistency?  Transaction management system and  Programmer

12. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Consistency A+B = TOT where TOT is a constant value Consistency: DB satisfies all integrity and constraints  Examples: - x is key of relation R - x  y holds in R - Domain(x) = {Red, Blue, Green}  is valid index for attribute x of R no employee should make more than twice the average salary A+B = TOT A+B may not equal to TOTA+B= TOT (1) read(A), (2)A := A -50,(3)write(A), (4) read(B), (5)B := B + 50, (6)write(B), (7) commit

13. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Isolation Transaction A should not see partial results of transaction B Analogy:  When I update my website here and there, you should not see and think a tentative version as my final version Who are responsible for isolation?  Transaction management system

14. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Isolation Intermediate transaction results must be hidden from other concurrently executed transactions. A+B may not equal to TOTA+B= TOT T2 A+B ≠ TOT?! (1) read(A), (2)A := A -50,(3)write(A), (4) read(B), (5)B := B + 50, (6)write(B), (7) commit

15. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Durability Any transaction committed needs to be in database for ever Example:  After you get the receipt of the water melon you buy from Alberson, the transaction is final and permanently reflected in the database system If you want to cancel it, that is another transaction Who are responsible for durability?  Transaction management system and  Recovery system

16. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Durability After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures. After this point, A and B are permanently updated (1) read(A), (2)A := A -50,(3)write(A), (4) read(B), (5)B := B + 50, (6)write(B), (7) commit

17. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Transaction State (Cont.) a 1, a 2, a 3, a 4, …, a n, commit

18. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction An Ideal World No hardware failures No software failures No programming errors Do we still need transaction management?

19. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Why Concurrent Transactions? Parallelism Improved response time

20. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Storage Hierarchy Read(x) read x from memory, if it is not in memory yet, read from disk first Write(x) writes x to memory and possibly to disk Memory Disk x x 1. read(A) 2. A := A – 50 3. write(A) 4. read(B) 5. B := B + 50 6. write(B) 7. commit

21. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Schedules T1 Read(A) A:=A-50 Write(A) Read(B) B:=B+50 Write(B) T2 Read(A) Temp:=A*0.1 A:=A-temp Write(A) Read(B) B:=B+temp Write(B) Schedule 1 Read(A) A:=A-50 Read(A) Temp:=A*0.1 A:=A-temp Write(A) Read(B) Write(A) Read(B) B:=B+50 Write(B) B:=B+temp Write(B) T1 transfer $50 from A to B T2 transfer 10% of the balance from A to B

22. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Schedules Schedules – sequences that indicate the chronological order in which instructions of concurrent transactions are executed  a schedule for a set of transactions must consist of all instructions of those transactions  must preserve the order in which the instructions appear in each individual transaction.

23. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Serial Schedule T 1 is followed by T 2. A = 100, B = 100 originally A = ? and B = ? Schedule 2 Read(A) A:=A-50 Write(A) Read(B) B:=B+50 Write(B) Read(A) Temp:=A*0.1 A:=A-temp Write(A) Read(B) B:=B+temp Write(B)

24. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Example Schedule (Cont.) Schedule 3 is equivalent to Schedule 1. In both Schedule 2 and 3, the sum A + B is preserved. A = 100, B = 100 originally A = ? and B = ? Schedule 3 Read(A) A:=A-50 Write(A) Read(A) Temp:=A*0.1 A:=A-temp Write(A) Read(B) B:=B+50 Write(B) Read(B) B:=B+temp Write(B)

25. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Example Schedules (Cont.) A = 100, B = 100 originally A = ? and B = ? Schedule 4 does not preserve the sum A + B Schedule 4 Read(A) A:=A-50 Read(A) Temp:=A*0.1 A:=A-temp Write(A) Read(B) Write(A) Read(B) B:=B+50 Write(B) B:=B+temp Write(B)

26. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Where is the mystery? How to preserve database consistency? Serializability!

27. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Serializability A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule.

28. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Conflict Serializability Transactions T 1 and T 2 Two operations on the same item Q, Intuitively, a conflict between T 1 and T 2 forces a (logical) temporal order between T 1 and T 2. Two consecutive non-conflict operations in a schedule can been interchanged Read(Q)Write(Q) Read(Q) Write(Q) T1 T2 Conflict?

29. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Conflict Serializability (Cont.) 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.

30. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Note Only read and write operations will cause conflict Other operations (A:=A+10) are on local copy variables and do not interface with database

31. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Simplified Schedules Schedule 3 Read(A) A:=A-50 Write(A) Read(A) Temp:=A*0.1 A:=A-temp Write(A) Read(B) B:=B+50 Write(B) Read(B) B:=B+temp Write(B) Schedule 3 Read(A) Write(A) Read(A) Write(A) Read(B) Write(B) Read(B) Write(B) Schedule 2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B) Schedule 2 Read(A) A:=A-50 Write(A) Read(B) B:=B+50 Write(B) Read(A) Temp:=A*0.1 A:=A-temp Write(A) Read(B) B:=B+temp Write(B)

32. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Schedule 3 and Schedule 2 are conflict equivalent Schedule 3 Read(A) Write(A) Read(A) Write(A) Read(B) Write(B) Read(B) Write(B) Schedule 2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B)

33. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Schedule 3 and Schedule 2 are conflict equivalent Schedule 3 Read(A) Write(A) Read(A) Read(B) Write(A) Write(B) Read(B) Write(B) Schedule 2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B)

34. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Schedule 3 and Schedule 2 are conflict equivalent Schedule 3 Read(A) Write(A) Read(A) Read(B) Write(B) Write(A) Read(B) Write(B) Schedule 2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B)

35. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Schedule 3 and Schedule 2 are conflict equivalent Schedule 3 Read(A) Write(A) Read(B) Read(A) Write(B) Write(A) Read(B) Write(B) Schedule 2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B)

36. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Schedule 3 and Schedule 2 are conflict equivalent Schedule 3 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B) Schedule 2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B)

37. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Conflict Serializability (Cont.) We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule Schedule 3 is conflict serializable

38. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Conflict Serializability (Cont.) Example of a schedule that is not conflict serializable: T 3 T 4 read(Q) write(Q) write(Q) We are unable to swap instructions in the above schedule to obtain either the serial schedule, or the serial schedule.

39. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Testing for Serializability Precedence graph — a direct graph where the vertices are the transactions (names).

40. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Example Schedule (Schedule A) T 1 T 2 T 3 T 4 T 5 read(X) read(Y) read(Z) read(V) read(W) read(W) read(Y) write(Y) write(Z) read(U) read(Y) write(Y) read(Z) write(Z) read(U) write(U)

41. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Precedence Graph for Schedule A T3T3 T4T4 T1T1 T2T2 T5T5

42. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Recoverability Only commit after the transaction your read from commits

43. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Cascadeless Schedule Only read committed write

44. 1/14/2005Yan Huang - CSCI5330 Database Implementation – Transaction Check Schedules Schedule 1 Read(A) Write(A) Read(B) Write(A) Read(B) Write(B) Schedule 2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(B) Schedule 3 Read(A) Write(A) Read(A) Write(A) Read(B) Write(B) Read(B) Write(B) Schedule 4 Read(A) Write(A) Read(B) Write(A) Read(B) Write(B) Conflict serializable? Recoverable? Cascadeless?