1 00:00:00,440 --> 00:00:01,580 In this video we'll delve into 2 00:00:01,730 --> 00:00:03,540 more detail about the properties of transactions. 3 00:00:05,120 --> 00:00:06,670 As a reminder, transactions are a 4 00:00:06,930 --> 00:00:08,490 concept that's been introduced as 5 00:00:08,610 --> 00:00:09,560 a solution to both the concurrency 6 00:00:10,120 --> 00:00:11,440 control problem and the system 7 00:00:11,840 --> 00:00:13,050 failure problem in databases. 8 00:00:14,220 --> 00:00:15,900 Specifically a transaction is 9 00:00:16,020 --> 00:00:17,910 a sequence of operations that are treated as a unit. 10 00:00:18,810 --> 00:00:20,040 Transactions appear to run 11 00:00:20,220 --> 00:00:21,370 in isolation, even if many 12 00:00:21,550 --> 00:00:23,760 clients are operating on a database at the same time. 13 00:00:24,610 --> 00:00:25,630 And further more if there is 14 00:00:25,760 --> 00:00:27,520 a system failure in unexpected software, 15 00:00:27,960 --> 00:00:29,700 hardware, or power failure every 16 00:00:29,960 --> 00:00:31,420 transactions changes that were 17 00:00:31,560 --> 00:00:33,120 issued to the database are either 18 00:00:33,330 --> 00:00:35,000 reflected entirely or not at all. 19 00:00:35,940 --> 00:00:37,590 Every database connoisseur knows that 20 00:00:37,760 --> 00:00:39,220 transaction support, what are 21 00:00:39,300 --> 00:00:40,740 known as the ACID properties. 22 00:00:41,380 --> 00:00:44,470 Although not everybody always remembers what 23 00:00:45,410 --> 00:00:46,890 A stands for atomicity; 24 00:00:48,660 --> 00:00:52,280 C stands for consistency; I 25 00:00:52,590 --> 00:00:56,410 stands for isolation; and D stands for for durability. 26 00:00:58,070 --> 00:01:00,900 And we're going to talk about each of these four properties in turn. 27 00:01:01,730 --> 00:01:03,710 We're going to talk about isolation first. 28 00:01:04,690 --> 00:01:05,780 We're going to talk about durability 29 00:01:06,520 --> 00:01:07,990 second,then we'll next talk 30 00:01:08,180 --> 00:01:10,370 about atomicity and we'll conclude talking about consistency. 31 00:01:11,690 --> 00:01:12,500 So here's the deal with isolation. 32 00:01:13,630 --> 00:01:14,980 We'll have a whole bunch of 33 00:01:14,980 --> 00:01:15,920 clients operating on our database, 34 00:01:16,550 --> 00:01:17,510 and we'd kind of like each 35 00:01:17,730 --> 00:01:19,910 client to imagine that they're operating on their own. 36 00:01:20,450 --> 00:01:21,340 So as we discussed in the 37 00:01:21,440 --> 00:01:22,830 previous video, each client 38 00:01:23,150 --> 00:01:25,320 issues to the database system a sequence of transactions. 39 00:01:26,210 --> 00:01:27,540 So this first client might 40 00:01:27,810 --> 00:01:29,450 be issuing first transaction T1, 41 00:01:30,820 --> 00:01:31,870 then T2, T3, and so on. 42 00:01:32,570 --> 00:01:34,000 Over here we have T9, 43 00:01:34,570 --> 00:01:36,210 T10, T11 and as a 44 00:01:37,480 --> 00:01:40,650 reminder, each transaction itself can be a sequence of statements. 45 00:01:41,200 --> 00:01:42,530 So, this might be statement one, 46 00:01:42,800 --> 00:01:44,360 statement two, statement three and 47 00:01:44,510 --> 00:01:45,610 so on, and then those 48 00:01:45,790 --> 00:01:47,160 statements will be treated as a unit. 49 00:01:48,170 --> 00:01:50,450 So the isolation property is implemented 50 00:01:51,120 --> 00:01:52,740 by a very specific formal 51 00:01:53,190 --> 00:01:54,500 notion called serializability. 52 00:01:56,220 --> 00:01:58,100 What serializability says is 53 00:01:58,200 --> 00:01:59,920 that the operations within transactions 54 00:02:00,750 --> 00:02:02,520 may be interleaved across clients, 55 00:02:03,430 --> 00:02:04,930 but the execution of those 56 00:02:05,140 --> 00:02:06,390 operations must be equivalent 57 00:02:06,920 --> 00:02:09,670 to some sequential serial orderOf all the transactions. 58 00:02:11,170 --> 00:02:12,500 So for our example over 59 00:02:12,750 --> 00:02:14,510 here, the system itself may 60 00:02:14,950 --> 00:02:15,870 execute all of the 61 00:02:15,930 --> 00:02:17,190 statements within each transaction 62 00:02:17,870 --> 00:02:19,980 and over here concurrently but 63 00:02:20,130 --> 00:02:21,710 it has to guarantee that the 64 00:02:21,810 --> 00:02:23,090 behavior against the database 65 00:02:23,860 --> 00:02:26,210 is equivalent to some sequence in order again. 66 00:02:26,510 --> 00:02:28,270 So perhaps the equivalent sequential 67 00:02:28,770 --> 00:02:29,880 order will be as if the 68 00:02:29,950 --> 00:02:31,240 system first did transaction 69 00:02:32,350 --> 00:02:33,560 T1, then may T2, T9 70 00:02:34,070 --> 00:02:37,160 and T10, maybe back to T3 and So on. 71 00:02:37,850 --> 00:02:38,880 And again the system has to 72 00:02:38,980 --> 00:02:40,640 guarantee that the state 73 00:02:40,960 --> 00:02:42,550 of the database, at this point 74 00:02:42,850 --> 00:02:43,860 in time, even if its 75 00:02:44,190 --> 00:02:45,590 internally the statements within 76 00:02:45,950 --> 00:02:47,490 any of these transactions looks as if 77 00:02:47,640 --> 00:02:49,170 these transactions executed in order. 78 00:02:50,440 --> 00:02:51,550 Now, you might wonder how the 79 00:02:51,630 --> 00:02:53,210 database system could possibly guarantee 80 00:02:53,800 --> 00:02:56,160 this level of consistency while still inter-leading operation. 81 00:02:57,370 --> 00:02:58,690 It uses protocols that are 82 00:02:58,760 --> 00:03:00,450 based on locking portions of the database. 83 00:03:01,490 --> 00:03:02,690 Now we're not going to describe the 84 00:03:03,070 --> 00:03:06,480 implementation, because implementation aspects are not the focus of this course. 85 00:03:07,200 --> 00:03:08,190 What you need to know from 86 00:03:08,400 --> 00:03:10,420 a user's application perspective is 87 00:03:10,530 --> 00:03:11,920 really the properties that are being guaranteed. 88 00:03:13,650 --> 00:03:14,880 Now with the formal 89 00:03:15,370 --> 00:03:16,410 notion of a let's go 90 00:03:16,510 --> 00:03:17,420 back and look at the examples 91 00:03:17,780 --> 00:03:18,920 from the previous video that motivated 92 00:03:19,410 --> 00:03:21,420 the problems we could get into with concurrent access. 93 00:03:22,400 --> 00:03:23,450 The first one was the 94 00:03:23,760 --> 00:03:24,890 example where two separate clients 95 00:03:25,290 --> 00:03:27,340 were updating Standford's enrollment. 96 00:03:27,430 --> 00:03:28,980 Let's just call one of them T1. 97 00:03:29,000 --> 00:03:29,750 It's not a transaction. 98 00:03:30,260 --> 00:03:30,690 And the other T2. 99 00:03:30,980 --> 00:03:32,360 So when we run 100 00:03:32,500 --> 00:03:33,620 thing is against the system and 101 00:03:33,880 --> 00:03:36,030 serializability is guaranteed, then 102 00:03:36,280 --> 00:03:37,810 we will have a behavior that 103 00:03:38,120 --> 00:03:39,750 is at least equivalent to 104 00:03:40,120 --> 00:03:41,470 either T1 followed by T2, 105 00:03:42,450 --> 00:03:43,680 or T2 followed by T1. 106 00:03:44,510 --> 00:03:45,560 So, in this case, when we 107 00:03:45,660 --> 00:03:47,840 start with our enrollment of 15,000, 108 00:03:48,040 --> 00:03:49,540 either execution will correctly 109 00:03:50,550 --> 00:03:54,580 have a final enrollment of 17,500 solving our concurrency problems. 110 00:03:55,910 --> 00:03:56,730 Here's our second example. 111 00:03:57,510 --> 00:03:58,700 In this case the first client was 112 00:03:58,910 --> 00:04:00,620 modifying the major of 113 00:04:00,820 --> 00:04:01,750 student 123 in the 114 00:04:02,000 --> 00:04:04,120 apply table and the second was modifying the decision. 115 00:04:04,680 --> 00:04:05,630 And we saw that if 116 00:04:05,750 --> 00:04:07,090 we allowed these to run in 117 00:04:07,180 --> 00:04:08,260 an interleaved fashion, it would 118 00:04:08,330 --> 00:04:10,510 be possible that only one of the two changes would be made. 119 00:04:11,440 --> 00:04:13,380 Again, with serializability we're going 120 00:04:13,640 --> 00:04:14,740 to get behavior that guarantees 121 00:04:15,430 --> 00:04:16,530 it is equivalent to either 122 00:04:16,690 --> 00:04:18,940 T1 and then T2, or T2 and then T1. 123 00:04:19,230 --> 00:04:20,720 And in both cases, both 124 00:04:21,140 --> 00:04:22,550 changes will be reflected in 125 00:04:22,760 --> 00:04:24,480 the database which is what we would like. 126 00:04:25,750 --> 00:04:26,920 The next example was the one 127 00:04:27,140 --> 00:04:28,030 where we were looking at the 128 00:04:28,110 --> 00:04:29,710 Apply and the Student table, 129 00:04:30,170 --> 00:04:31,700 and we were modifying the Apply 130 00:04:31,910 --> 00:04:33,720 table based on the 131 00:04:33,900 --> 00:04:35,440 GPA in the Student table, and 132 00:04:35,530 --> 00:04:37,200 simultaneously modifying that GPA. 133 00:04:38,100 --> 00:04:39,110 So again if these are issued 134 00:04:39,410 --> 00:04:40,990 as two transactions, we'll have 135 00:04:41,330 --> 00:04:42,550 either T1 followed by 136 00:04:42,730 --> 00:04:44,610 T2 or T2 followed by T1. 137 00:04:45,100 --> 00:04:46,920 Or at least we will have behavior that is equivalent to that. 138 00:04:47,810 --> 00:04:48,690 Now this case is a 139 00:04:48,750 --> 00:04:50,680 bit interesting because either of 140 00:04:50,890 --> 00:04:53,190 these does result in a consistent state of the database. 141 00:04:54,550 --> 00:04:55,980 In the first case, we'll update 142 00:04:56,340 --> 00:04:57,700 all the decision records before the 143 00:04:57,790 --> 00:04:59,080 GPAs are modified for anyone, 144 00:04:59,690 --> 00:05:00,830 and in the second case, will 145 00:05:01,030 --> 00:05:03,440 update the apply records after the GPAs have been modified. 146 00:05:04,060 --> 00:05:05,510 The interesting thing here 147 00:05:05,940 --> 00:05:07,300 is that the order does 148 00:05:07,660 --> 00:05:08,800 matter in this case. 149 00:05:09,820 --> 00:05:13,130 Now, the database systems only guarantees serializability. 150 00:05:13,820 --> 00:05:14,740 They guarantee that the behavior 151 00:05:15,240 --> 00:05:16,820 will be equivalent to some 152 00:05:17,250 --> 00:05:18,680 sequential order but they 153 00:05:18,830 --> 00:05:20,240 don't guarantee the exact sequential 154 00:05:20,780 --> 00:05:23,360 order if the transactions are being issued at the same time. 155 00:05:23,990 --> 00:05:25,580 So if it's important to get, 156 00:05:25,910 --> 00:05:27,310 say, T1 before T2, that 157 00:05:27,900 --> 00:05:29,590 would actually have to be coded as part of the application. 158 00:05:31,050 --> 00:05:32,280 And our last example was 159 00:05:32,480 --> 00:05:33,570 the case where we had the 160 00:05:33,800 --> 00:05:35,620 Apply table, the Archive table, 161 00:05:36,110 --> 00:05:37,900 and we were moving records from 162 00:05:38,070 --> 00:05:39,370 one table to another in 163 00:05:39,590 --> 00:05:41,180 one of our clients, and the 164 00:05:41,260 --> 00:05:43,840 other client was counting the tuples. 165 00:05:44,140 --> 00:05:46,660 And again, so T1 and T2, they're issued as transactions. 166 00:05:47,450 --> 00:05:49,330 The system guarantees that we'll 167 00:05:49,740 --> 00:05:51,100 either move all the 168 00:05:51,290 --> 00:05:52,190 tuples first and then count 169 00:05:52,490 --> 00:05:54,660 them, or will count the tuples and then move them. 170 00:05:55,220 --> 00:05:56,580 Now, again, here's a case 171 00:05:57,070 --> 00:05:58,340 where the order makes a difference, 172 00:05:58,950 --> 00:06:00,030 but if we care specifically 173 00:06:00,610 --> 00:06:02,710 about the order, that would have to be coded as part as the application. 174 00:06:04,360 --> 00:06:06,620 OK, so we've finished our first of the four ACID properties. 175 00:06:07,180 --> 00:06:09,430 The other three will actually be quite a bit quicker to talk about. 176 00:06:10,070 --> 00:06:11,030 Let's talk now about durability. 177 00:06:11,750 --> 00:06:14,720 And we only need to look at one client to understand what's going on. 178 00:06:15,370 --> 00:06:16,330 So let's say that we 179 00:06:16,440 --> 00:06:17,540 have our client, and the client 180 00:06:17,990 --> 00:06:20,140 has issuing a sequence of transactions to the database. 181 00:06:21,340 --> 00:06:23,740 And each transaction again is a sequence of statements. 182 00:06:24,480 --> 00:06:26,730 And finally at the end of the transaction there is a commit. 183 00:06:28,620 --> 00:06:30,230 So what durability guarantees for us 184 00:06:30,590 --> 00:06:31,590 is that if there is a 185 00:06:31,780 --> 00:06:33,340 system crash after a transaction 186 00:06:34,080 --> 00:06:35,330 commits, then all effects 187 00:06:35,680 --> 00:06:37,740 of that transaction will remain in the database. 188 00:06:38,620 --> 00:06:40,170 So, specifically, if at a 189 00:06:40,460 --> 00:06:41,540 later point in time after 190 00:06:41,920 --> 00:06:43,280 this occurs, there's a failure 191 00:06:43,700 --> 00:06:45,230 for whatever reason, the client 192 00:06:45,730 --> 00:06:47,120 can rest assured that the 193 00:06:47,660 --> 00:06:49,170 effects of this transaction are in 194 00:06:49,320 --> 00:06:50,240 the database, and when the system 195 00:06:50,610 --> 00:06:52,470 comes back up, they will still be in there. 196 00:06:53,200 --> 00:06:54,120 So you may be wondering 197 00:06:54,530 --> 00:06:55,580 how it's possible to make this 198 00:06:55,750 --> 00:06:57,370 guarantee since database systems 199 00:06:57,760 --> 00:06:59,080 move data between disc and 200 00:06:59,180 --> 00:07:00,610 memory and a crash could occur at anytime. 201 00:07:01,760 --> 00:07:03,260 They're actually fairly complicated protocols 202 00:07:03,770 --> 00:07:05,740 that are used and they're based on the concept of logging. 203 00:07:06,360 --> 00:07:09,000 But once again we're not gonna talk about the implementation details. 204 00:07:09,490 --> 00:07:10,760 What's important from the user 205 00:07:11,010 --> 00:07:13,200 or application perspective is the properties that are guaranteed. 206 00:07:13,770 --> 00:07:15,340 2 properties down. 207 00:07:16,040 --> 00:07:16,910 Now let's talk about atomicity. 208 00:07:17,510 --> 00:07:18,200 again we'll only look at 209 00:07:18,240 --> 00:07:21,040 one client who's issuing a sequence of transactions to the database. 210 00:07:21,990 --> 00:07:23,310 And let's look at transaction T2 211 00:07:23,630 --> 00:07:24,410 which itself is a sequence 212 00:07:24,870 --> 00:07:26,400 of statements followed by commit. 213 00:07:27,630 --> 00:07:28,990 The case that atomicity deals 214 00:07:29,450 --> 00:07:30,400 with is the case where there's 215 00:07:30,580 --> 00:07:31,640 actually a crash or a 216 00:07:31,900 --> 00:07:33,240 failure during the execution 217 00:07:33,550 --> 00:07:35,270 of the transaction, before it's been committed. 218 00:07:36,060 --> 00:07:37,420 What the property tells 219 00:07:37,760 --> 00:07:38,990 us is that even in 220 00:07:39,180 --> 00:07:40,780 the presence of system crashes, every 221 00:07:41,040 --> 00:07:43,720 transaction is always executed either all or nothing. 222 00:07:44,480 --> 00:07:44,690 on the database. 223 00:07:45,450 --> 00:07:46,320 So in other words, if we have 224 00:07:46,580 --> 00:07:48,320 each of our transactions running, it's 225 00:07:48,500 --> 00:07:49,780 not possible in a system 226 00:07:49,990 --> 00:07:50,970 crash to, say, have executed 227 00:07:51,930 --> 00:07:52,980 on the database a couple of 228 00:07:53,080 --> 00:07:54,640 statements but not the rest of the transaction. 229 00:07:56,450 --> 00:07:58,290 Now once again, you might be wondering how this is implemented. 230 00:07:59,290 --> 00:08:00,460 It also uses a log-in 231 00:08:00,700 --> 00:08:02,380 mechanism and specifically when 232 00:08:02,620 --> 00:08:04,080 the system recovers from a 233 00:08:04,240 --> 00:08:05,560 crash, there is a 234 00:08:05,640 --> 00:08:07,000 process by which partial effects of 235 00:08:07,090 --> 00:08:08,080 transactions that were underway 236 00:08:08,760 --> 00:08:09,910 at the time of the crash, are undone. 237 00:08:11,050 --> 00:08:13,890 Now applications do need to be somewhat aware of this process. 238 00:08:14,520 --> 00:08:16,340 So when an application submits a 239 00:08:16,640 --> 00:08:18,000 transaction to the database, it's possible 240 00:08:18,600 --> 00:08:19,660 that it will get back an error 241 00:08:19,960 --> 00:08:21,120 because there was in fact a 242 00:08:21,350 --> 00:08:22,500 crash during the execution of 243 00:08:22,560 --> 00:08:24,390 the transaction, and then the system is restarted. 244 00:08:25,360 --> 00:08:26,590 In that case the application 245 00:08:26,830 --> 00:08:28,670 does have the guarantee that none 246 00:08:29,250 --> 00:08:30,480 of the effects of the 247 00:08:30,550 --> 00:08:31,870 transaction were reflected in 248 00:08:31,910 --> 00:08:33,970 the database, but it will need to restart the transaction. 249 00:08:35,480 --> 00:08:36,470 Now let's come back to the 250 00:08:36,660 --> 00:08:37,930 fact that the system will undo 251 00:08:38,400 --> 00:08:39,360 partial effects of a transaction 252 00:08:40,120 --> 00:08:41,690 to guarantee the atomicity property, 253 00:08:42,500 --> 00:08:43,610 that each transaction is executed 254 00:08:44,100 --> 00:08:45,320 in an all or nothing fashion. 255 00:08:46,210 --> 00:08:47,550 So, this concept of undoing 256 00:08:47,900 --> 00:08:48,700 partial Full effects of the 257 00:08:48,770 --> 00:08:50,200 transaction is known as 258 00:08:50,710 --> 00:08:52,610 transaction roll back or transaction abort. 259 00:08:53,110 --> 00:08:54,500 And the reason I'm mentioning it 260 00:08:54,730 --> 00:08:56,040 here is that although it 261 00:08:56,210 --> 00:08:57,860 is the implementation mechanisms for 262 00:08:58,010 --> 00:08:59,860 Atima City, it's also an 263 00:09:00,290 --> 00:09:01,910 operation that's exposed by the 264 00:09:02,000 --> 00:09:04,130 database in an application would like to use it. 265 00:09:05,080 --> 00:09:07,010 Specifically, a transaction rollback 266 00:09:07,910 --> 00:09:09,050 can be initiated by the system, 267 00:09:09,680 --> 00:09:12,030 in the case of an error, or a crash recovery. 268 00:09:12,700 --> 00:09:13,820 But it also can be client initiated. 269 00:09:14,790 --> 00:09:15,970 And let me give a 270 00:09:16,120 --> 00:09:17,540 little example where a client might 271 00:09:17,740 --> 00:09:19,380 write code that takes advantage of the operation. 272 00:09:20,760 --> 00:09:22,440 So here is some toy application code. 273 00:09:22,860 --> 00:09:24,330 In this code, the client begins 274 00:09:24,640 --> 00:09:26,570 a transaction, it asks the 275 00:09:26,830 --> 00:09:28,190 Database user for some input. 276 00:09:29,190 --> 00:09:30,420 It performs some sequel commands. 277 00:09:30,830 --> 00:09:32,290 Maybe some modifications to the 278 00:09:32,370 --> 00:09:33,950 database based on the input from the user. 279 00:09:34,470 --> 00:09:36,320 It confirms that the user likes the results of those modifications. 280 00:09:37,050 --> 00:09:39,080 And if the user says 281 00:09:39,320 --> 00:09:40,860 okay, then the transaction is committed, 282 00:09:41,100 --> 00:09:43,110 and we get an atomic execution of this behavior. 283 00:09:43,980 --> 00:09:45,220 But if the user doesn't say okay, 284 00:09:45,700 --> 00:09:47,080 then the transaction is rolled back 285 00:09:47,740 --> 00:09:49,450 and, automatically, these sequel commands 286 00:09:49,970 --> 00:09:52,010 that were executed are undone, and 287 00:09:52,340 --> 00:09:54,400 that frees the application from writing 288 00:09:54,720 --> 00:09:55,990 the code that undoes those commands 289 00:09:56,930 --> 00:09:58,200 explicitly So it can actually be quite 290 00:09:59,450 --> 00:10:01,180 a useful feature for clients to use. 291 00:10:02,010 --> 00:10:03,030 But clients do need to 292 00:10:03,150 --> 00:10:05,000 be very careful, because this 293 00:10:05,410 --> 00:10:07,230 rollback command only undoes 294 00:10:07,790 --> 00:10:09,890 effects on the data itself in the database. 295 00:10:10,680 --> 00:10:11,880 So if perhaps in this 296 00:10:12,070 --> 00:10:13,350 code, the system was 297 00:10:13,610 --> 00:10:15,250 also modifying some variables 298 00:10:16,120 --> 00:10:17,220 or even worse, say delivering 299 00:10:17,800 --> 00:10:18,720 cash out of an ATM 300 00:10:18,960 --> 00:10:21,920 machine, the rollback command is not going to undo those. 301 00:10:22,210 --> 00:10:23,870 It's not gonna modify variables and 302 00:10:23,970 --> 00:10:24,870 it's certainly not going to 303 00:10:24,950 --> 00:10:26,470 pull that cash back into the ATM. 304 00:10:27,450 --> 00:10:28,510 So, there actually is another issue 305 00:10:28,750 --> 00:10:30,120 with this particular client interaction 306 00:10:30,650 --> 00:10:31,950 that I am going to put a "frownie" face here. 307 00:10:32,330 --> 00:10:34,610 It was a nice, simple example of how rollback can be helpful. 308 00:10:35,480 --> 00:10:36,850 But one thing that happens in 309 00:10:36,970 --> 00:10:38,450 this example is that we 310 00:10:38,560 --> 00:10:41,130 begin a transaction and then we wait for the user to do something. 311 00:10:41,580 --> 00:10:42,900 And we actually wait for the user back here. 312 00:10:43,550 --> 00:10:45,130 So experienced database application 313 00:10:46,510 --> 00:10:47,720 developers will tell you to 314 00:10:48,000 --> 00:10:49,220 never hold open a 315 00:10:49,250 --> 00:10:52,070 transaction and then wait for arbitrary amounts of time. 316 00:10:52,830 --> 00:10:54,460 The reason is that transactions do 317 00:10:54,810 --> 00:10:56,210 use this locking mechanism I 318 00:10:56,570 --> 00:10:57,690 alluded to earlier, so when 319 00:10:57,900 --> 00:10:59,380 a transaction is running, it 320 00:10:59,580 --> 00:11:00,860 may be blocking other portions, 321 00:11:01,880 --> 00:11:04,340 blocking other clients from portions of the database. 322 00:11:05,260 --> 00:11:06,460 If the user happened to 323 00:11:06,550 --> 00:11:07,210 go out for a cup of coffee 324 00:11:07,700 --> 00:11:08,480 or is going to come back in 325 00:11:08,560 --> 00:11:09,590 a week, we certainly don't want 326 00:11:10,000 --> 00:11:11,770 to leave the database locked up for an entire week. 327 00:11:12,100 --> 00:11:13,470 So, again and a general rule 328 00:11:13,500 --> 00:11:15,430 of thumb is that transactions should 329 00:11:15,690 --> 00:11:16,820 be constructed in a fashion 330 00:11:17,090 --> 00:11:19,220 that we know they are going to run to completion fairly quickly. 331 00:11:20,630 --> 00:11:21,560 Finally, let's talk about consistency. 332 00:11:22,800 --> 00:11:24,360 The consistency property talks about 333 00:11:24,630 --> 00:11:26,510 how transactions interact with the 334 00:11:26,810 --> 00:11:28,710 integrity constraints that may hold on a database. 335 00:11:29,430 --> 00:11:30,920 As a reminder and integrity constraint 336 00:11:31,360 --> 00:11:34,010 is a specification of which database states are legal. 337 00:11:35,160 --> 00:11:37,960 Transactions are actually very helpful in the management of constraints. 338 00:11:38,860 --> 00:11:40,030 Specifically, when we have 339 00:11:40,130 --> 00:11:41,720 multiple clients interacting with the 340 00:11:41,780 --> 00:11:43,000 database in an interleaved fashion, 341 00:11:43,860 --> 00:11:44,860 we can have a setup where 342 00:11:45,350 --> 00:11:46,710 each client can assume that 343 00:11:46,830 --> 00:11:48,080 when it begins it operates 344 00:11:48,620 --> 00:11:51,130 on a database that satisfies all integrity constraints. 345 00:11:52,760 --> 00:11:54,420 Then each transaction, then sorry, 346 00:11:54,710 --> 00:11:56,820 each client, must guarantee that 347 00:11:57,080 --> 00:11:58,280 all constraints hold when the 348 00:11:58,350 --> 00:11:59,730 transaction ends and that's 349 00:11:59,910 --> 00:12:01,010 typically guaranteed by the 350 00:12:01,130 --> 00:12:02,560 constraint enforcement sub system. 351 00:12:03,740 --> 00:12:05,850 Now with that guarantee, since we 352 00:12:05,960 --> 00:12:07,410 have serialized ability of transactions. 353 00:12:08,580 --> 00:12:10,820 that guaranteesthat constraints always hold. 354 00:12:11,250 --> 00:12:12,990 Specifically the behavior of 355 00:12:13,440 --> 00:12:15,970 the database is some sequential order of the transactions. 356 00:12:17,190 --> 00:12:18,200 We know and we can 357 00:12:18,520 --> 00:12:20,810 assume at the start of the transaction the constraints hold. 358 00:12:21,430 --> 00:12:22,920 And then we guarantee they hold at the end. 359 00:12:23,500 --> 00:12:25,360 And since the behaviors equivalent to 360 00:12:25,440 --> 00:12:26,710 a sequential order then the 361 00:12:26,770 --> 00:12:28,190 next transaction can assume 362 00:12:28,490 --> 00:12:29,990 the constraints hold and so on. 363 00:12:31,110 --> 00:12:33,400 In conclusion transaction are a very powerful concept. 364 00:12:33,950 --> 00:12:35,120 They give a solution for both 365 00:12:35,360 --> 00:12:36,860 concurrency control and system 366 00:12:37,310 --> 00:12:38,360 failure management and databases. 367 00:12:39,420 --> 00:12:41,090 They provide formally understood properties 368 00:12:41,600 --> 00:12:44,030 of atomicity, consistency, isolation and durability. 369 00:12:45,620 --> 00:12:48,410 In the next video we are going to focus more on the isolation property. 370 00:12:49,270 --> 00:12:50,130 We're going to see that in some 371 00:12:50,390 --> 00:12:51,420 cases we may want to 372 00:12:51,750 --> 00:12:52,970 relax the notion of isolation 373 00:12:53,920 --> 00:12:55,290 while still providing properties that 374 00:12:55,420 --> 00:12:57,310 are sufficient for applications in certain circumstances.