Chapter 15: Transactions Transaction Concept Transaction Concept Concurrent Executions Concurrent Executions Serializability Serializability Testing for Serializability Testing for Serializability

Transaction Concept A transaction is a unit of program execution that accesses and possibly updates various data items. A transaction is a unit of program execution that accesses and possibly updates various data items. Two main issues to deal with: Two main issues to deal with: Failures of various kinds, such as hardware failures and system crashes Failures of various kinds, such as hardware failures and system crashes Concurrent execution of multiple transactions 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

ACID Properties Atomicity Atomicity Consistency Consistency Isolation Isolation Durability Durability To preserve integrity of data, the database system must ensure:

Example of Fund Transfer Transaction to transfer $50 from account A to account B: Transaction to transfer $50 from account A to account B: 1. read(A) 2. A := A – write(A) 4. read(B) 5. B := B write(B) 7. commit

Atomicity Either all operations of the transaction are properly reflected Either all operations of the transaction are properly reflected Or none are 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

Consistency A+B = TOT where TOT is a constant value A+B = TOT where TOT is a constant value Consistency: DB satisfies all integrity and constraints Consistency: DB satisfies all integrity and constraints Examples: Examples: - x is key of relation R - x is key of relation R - x  y holds in R - x  y holds in R - Domain(x) = {Red, Blue, Green} - Domain(x) = {Red, Blue, Green}  is valid index for attribute x of R  is valid index for attribute x of R no employee should make more than twice the average salary no employee should make more than twice the average salary A+B = TOT 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

Isolation Intermediate transaction results must be hidden from other concurrently executed transactions. 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

Durability After a transaction completes successfully, the changes it has made to the database persist, even if there are system failures. 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

Transaction State Active Active Partially committed Partially committed Committed Committed Failed Failed Aborted Aborted

Transaction State (Cont.) a 1, a 2, a 3, a 4, …, a n, commit

Implementation of Atomicity and Durability Assumes one transaction at a time Assumes one transaction at a time Useful for text editors, but extremely inefficient for large databases: executing a single transaction requires copying the entire database. Useful for text editors, but extremely inefficient for large databases: executing a single transaction requires copying the entire database. The shadow-database scheme:

Storage Hierarchy Read(x) read x from memory, if it is not in memory yet, read from disk first 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 Write(x) writes x to memory and possibly to disk Memory Disk x x 1. read(A) 2. A := A – write(A) 4. read(B) 5. B := B write(B) 7. commit

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

Schedules Schedules – sequences that indicate the chronological order in which instructions of concurrent transactions are executed 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 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. must preserve the order in which the instructions appear in each individual transaction.

Concurrent Executions Multiple transactions are allowed to run concurrently in the system Multiple transactions are allowed to run concurrently in the system Concurrency control schemes – mechanisms to achieve isolation, i.e., to control the interaction among the concurrent transactions in order to prevent them from destroying the consistency of the database Concurrency control schemes – mechanisms to achieve isolation, i.e., to control the interaction among the concurrent transactions in order to prevent them from destroying the consistency of the database

Serial Schedule T 1 is followed by T 2. 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)

Example Schedule (Cont.) Schedule 3 is equivalent to Schedule 1. 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)

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)

Where is the mystery? How to preserve database consistency? How to preserve database consistency? Serializability!

Serializability A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule. A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule.

Conflict Serializability Transactions T 1 and T 2 Transactions T 1 and T 2 Two operations on the same item Q, 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. 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 Two consecutive non-conflict operations in a schedule can been interchanged Read(Q)Write(Q) Read(Q) Write(Q) T1 T2 Conflict?

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. 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.

Note Only read and write operations will cause conflict Only read and write operations will cause conflict Other operations (A:=A+10) are on local copy variables and do not interface with database Other operations (A:=A+10) are on local copy variables and do not interface with database

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)

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)

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)

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)

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)

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)

Conflict Serializability (Cont.) We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule Schedule 3 is conflict serializable Schedule 3 is conflict serializable

Conflict Serializability (Cont.) Example of a schedule that is not conflict serializable: 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.

Testing for Serializability Consider some schedule of a set of transactions T 1, T 2,..., T n Consider some schedule of a set of transactions T 1, T 2,..., T n Precedence graph — a direct graph where the vertices are the transactions (names). Precedence graph — a direct graph where the vertices are the transactions (names). We draw an arc from T i to T j if the two transaction conflict, and T i accessed the data item on which the conflict arose earlier. We draw an arc from T i to T j if the two transaction conflict, and T i accessed the data item on which the conflict arose earlier. We may label the arc by the item that was accessed. We may label the arc by the item that was accessed. Example 1 Example 1 x y

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)

Precedence Graph for Schedule A T3T3 T4T4 T1T1 T2T2 T5T5

Test for Conflict Serializability A schedule is conflict serializable if and only if its precedence graph is acyclic. A schedule is conflict serializable if and only if its precedence graph is acyclic. Cycle-detection algorithms exist which take order n 2 time, where n is the number of vertices in the graph. (Better algorithms take order n + e where e is the number of edges.) Cycle-detection algorithms exist which take order n 2 time, where n is the number of vertices in the graph. (Better algorithms take order n + e where e is the number of edges.) If precedence graph is acyclic, the serializability order can be obtained by a topological sorting of the graph. This is a linear order consistent with the partial order of the graph. For example, a serializability order for Schedule A would be T 5  T 1  T 3  T 2  T 4. If precedence graph is acyclic, the serializability order can be obtained by a topological sorting of the graph. This is a linear order consistent with the partial order of the graph. For example, a serializability order for Schedule A would be T 5  T 1  T 3  T 2  T 4.

Concurrency Control vs. Serializability Tests Testing a schedule for serializability after it has executed is a little too late! Testing a schedule for serializability after it has executed is a little too late! Goal – to develop concurrency control protocols that will assure serializability. They will generally not examine the precedence graph as it is being created; instead a protocol will impose a discipline that avoids nonseralizable schedules. Goal – to develop concurrency control protocols that will assure serializability. They will generally not examine the precedence graph as it is being created; instead a protocol will impose a discipline that avoids nonseralizable schedules. Tests for serializability help understand why a concurrency control protocol is correct. Tests for serializability help understand why a concurrency control protocol is correct.