8 Transactions
Total Page:16
File Type:pdf, Size:1020Kb
8 Transactions What happens if multiple users are reading and updating a database at the same time? 8.1 Let's imagine... Let's image a simple case with only two users, Alice and Bob, two students of the ISE class that developed a movies's database during the last month, as a result of great interest for the class and social distancing. They still need to recall the concepts of foreign keys, so they implemented only one table, and populated it with some movies of Buster Keaton to begin with. In the future they want to watch the movies written in the table (Alice or Bob or both) and they want to give it a grade between 1 and 6, thus they could later easily choose their movie-evening. NAME OF THE MOVIE GRADE The Frozen North None Seven Chances None Our Hospitality None Battling Butler None Steamboat Bill Jr. None 8.2 Conflicts / Dependencies We are Monday 20th April. Alice and Bob watch separately (#socialdistancing) a movie in the weekend. Now they have a bit a time between two zoom classes and want to update their table, at the same time, (not knowing about the other) and give a grade to the movie they watched. Let's see five scenarii. 8.2.1 updating-only two different tuples Alice watched The Frozen North and wants to give it a 4. Bob watched Seven Chances and wants to give it a 5. NAME OF THE MOVIE GRADE The Frozen North 4 Seven Chances 5 Our Hospitality None Battling Butler None Steamboat Bill Jr. None 8.2.2 Alice reads before Bob updates Alice wants to read the grade of Seven Chances . Bob watched Seven Chances and wants to give it a 5. READ-WRITE conflict She will see the following: NAME OF THE MOVIE GRADE The Frozen North None Seven Chances None Our Hospitality None Battling Butler None Steamboat Bill Jr. None 33 8.2.3 Alice reads after Bob updates Bob watched Seven Chances and wants to give it a 5. Alice wants to read the grade of Seven Chances . WRITE-READ conflict She will see the following NAME OF THE MOVIE GRADE The Frozen North None Seven Chances 5 Our Hospitality None Battling Butler None Steamboat Bill Jr. None 8.2.4 Alice updates before Bob updates Alice watched Our Hospitality and wants to give it a 5. Bob watched Our Hospitality and wants to give it a 6. WRITE-WRITE conflict At the end the table is the following: NAME OF THE MOVIE GRADE The Frozen North None Seven Chances None Our Hospitality 6 Battling Butler None Steamboat Bill Jr. None 8.2.5 Alice updates after Bob updates Bob watched Our Hospitality and wants to give it a 6. Alice watched Our Hospitality and wants to give it a 5. WRITE-WRITE conflict At the end the table is the following: NAME OF THE MOVIE GRADE The Frozen North None Seven Chances None Our Hospitality 5 Battling Butler None Steamboat Bill Jr. None We saw READ-WRITE, WRITE-READ, and WRITE-WRITE dependencies. Would it make sense to have a READ-READ dependency? No, because a READ transaction does not modify the table, thus having different users reading from the same table in different orders always display the same output. 8.3 Timeline/ Schedule / History of Transactions Now let's represent the prior cases in a timeline manner. The following illustrates the history of transactions. Imagine a time axis, the first action being the first row, and the last action being the last row. This is also called a schedule. You will need to understand theses schedules, how to draw a graph with the queries (as shown in the next subsection 8.4), how to draw a graph with the users (as shown in the subsection 8.5), and with the help of those graphs, to conclude if the schedule is serializable or not, and if yes, you might be asked to make it serial. 34 8.3.1 updating-only two different tuples Alice Bob WA(T he F rozen North) WB(Seven Chances) 8.3.2 Alice reads before Bob updates Alice Bob RA(Seven Chances) WB(Seven Chances) 8.3.3 Alice reads after Bob updates Alice Bob WB(Seven Chances) RA(Seven Chances) 8.3.4 Alice updates before Bob updates Alice Bob WA(Our Hospitality) WB(Our Hospitality) 8.3.5 Alice updates after Bob updates Alice Bob WB(Our Hospitality) WA(Our Hospitality) 8.4 Graph with the queries We implement the dependencies presented in the section 8.2 in a directed graph manner. Here the nodes are the queries, and the edges are the dependencies between them. 8.4.1 updating-only two different tuples Alice Bob WA(T he F rozen North) WB(Seven Chances) 8.4.2 Alice reads before Bob updates Alice Bob RA(Seven Chances) WB(Seven Chances) 8.4.3 Alice reads after Bob updates Alice Bob WB(Seven Chances) RA(Seven Chances) 8.4.4 Alice updates before Bob updates Alice Bob WA(Our Hospitality) WB(Our Hospitality) 35 8.4.5 Alice updates after Bob updates Alice Bob WB(Our Hospitality) WA(Our Hospitality) 8.5 Graph with the users Here the nodes are the users, eg. Alice and Bob, and the edges are the dependencies between them. 8.5.1 updating-only two different tuples 8.5.2 Alice reads before Bob updates 8.5.3 Alice reads after Bob updates 8.5.4 Alice updates before Bob updates 8.5.5 Alice updates after Bob updates This graph with the users as nodes is helping us to decide wether or not the schedule is serializable. If we have some cycle, there is no way to detangle the arrows, and the schedule is not serializable. In the case, we have no cycle, than we could detangle the arrows, which means : the schedule is serializable. If a schedule is serializable, we are able to modify the schedule to obtain a conflict-equivalent serial schedule. 36 8.6 Detecting cycles Here we have a graph with two nodes and a cycle. Here we have a graph with 5 nodes, 4 edges and no cycle. Here we have a graph with 5 nodes, 5 edges, and a cycle highlighted in orange. 37 8.7 Detailed example: written support for the video You can find here the transcript of the example written on the blackboard of the video recording of last year. 8.7.1 Timeline Alice Bob Charles RA(α) WB(α) RB(β) WC (α) RA(β) WC (β) RA(α) WC (α) WB(β) 8.7.2 Graph with the queries Alice Bob Charles RA(α) . WB(α) RB(β) . WC (α) RA(β) . WC (β) . RA(α) . WC (α) . WB(β) 38 8.7.3 Graph with the users We obtain a complete graph. There are cycles everywhere, thus the schedule is not seri- alizable. 8.8 Review questions Serializable schedules: Bob reads A Bob reads A Bob reads A Bob reads A Bob writes A Bob writes A Bob writes A Alice reads B Alice writes A Alice writes A Alice reads A Bob writes A Bob reads A Alice reads A Bob reads A Alice writes B Alice reads A Alice writes A Bob reads A Alice reads B (i.) (ii.) (iii.) (iv.) (ii.)! already serial, all actions together of one person and then all actions together of the other person. (iv.)! serializable, there is no interaction between Alice and Bob. We can swap Alice and Bob. (iii.)! serializable, we swap Alice and Bob reading transaction, there is no dependencies between them. (i.)! not serializable, we have to have Bob-Alice-Bob, we cannot swap Alice and Bob. There is a write-write conflict (Bob writes A. Alice writes A) and a write-read conflict (Alice writes A. Bob reads A). 8.9 Some additional definitions 29 transaction: group of one or more database operations, which is a unit of work that must be executed atomically and in apparent isolation from other transactions. transactions: SQL allows the programmer to group SQL statements into transactions, which may be committed or rolled back (aborted). Transactions may be rolled back by the application in order to undo changes, or by the system in order to guarantee atomicity and isolation. consistent database states: Database states that obey whatever implied or declared constraints the designers intended are called consistent. It is essential that operations on the database preserve consistency, that is, they turn one consistent database state into another. consistency of concurrent transactions: It is normal for several transactions to have access to a database at the same time. Transactions, run in isolation, are assumed to pre- serve consistency of the database. It is the job of the scheduler to assure that concurrently operating transactions also preserve the consistency of the database. 29from Database Systems, Garcia-Molina 39 schedules: Transactions are broken into actions, mainly reading and writing from the database. A sequence of these actions from one or more transactions is called a schedule. serial schedules: If transactions execute one at a time, the schedule is said to be serial. If its actions consist of all the actions of one transaction, then all the actions of another transaction, and so on. No mixing of the actions is allowed. notations: - An action is an expression of the form ri(X) or Wi(X), meaning that transaction Ti, reads or writes, respectively, the database element X . - A transaction Ti is a sequence of actions with subscript i.