Water pepper

Personal Insults

Insulting those who attempt to answer your questions by claiming that they are not knowledgeable is not acceptable on Wikipedia. I hope that some day you will realize that you are mistaken, not 30 years of computer science textbooks, college courses, and countless professors/students who all repeat the same thing. If you honestly disagree with what I've explained about ACID, please call your local university - as long as it isn't Missouri Science & Technology, because you'll likely get me and I'll just tell you the same thing I'd tell any student, atomic means all or nothing. Isolation means the outcome is the same as some possible sequential ordering. -- kainaw™ 19:28, 6 March 2009 (UTC)

This message by Kainaw posted in response to this thread <http://en.wiki.x.io/wiki/Talk:ACID#ACID_-.3E_AID.3F_ACD.3F>.Water pepper (talk) 19:42, 8 March 2009 (UTC)

ACID

made by --206.168.41.194 (talk) 15:35, 11 April 2019 (UTC)Luciano You made some mistakes in your comments:

"They can't (have the effect of) interfering with each other because then they'd be (having the effect of) running in parallel and thus interfering, which offends the principle of Isolation."

Running in parallel does not imply interference. I will give an example, but I'm afraid that the terminology of these common transaction management examples need to be explained... When discussing transaction management, there are two primary operations: READ() and WRITE(). A letter is placed in the parenthesis to refer to some data item that is read or written, such as READ(A). Transactions are normally identified as T1, T2, T3... and so on. To apply an operation to a specific transaction, the transaction precedes it as in T1:READ(A) means Transaction 1 performs the read operation on A. So, consider T1 = READ(A), WRITE(B). T2 = READ(C), WRITE(D). If they run in parallel as T1:READ(A), T2:READ(C), T1:WRITE(B), T2:WRITE(D). The transactions ran in parallel without any interference.

"Consistency says the transaction completes entirely or is rolled back entirely."

That is not accurate. Consistency means that the final state of the database, after the transaction commits, must be consistent or the transaction must be rolled back. Consistency doesn't come into consideration until the transaction completes. This is another example. Assume that we have a database where A+B must always be 100. If it is not consistent, then the transaction making the change to A or B must be rolled back. T1 = READ(A), WRITE(B). So, T1:READ(A) runs. Something happens (it doesn't matter what - perhaps someone spilled a drink on one of the drives). The attempt to WRITE(B) completely fails. Consistency is not checked. This falls under atomicity. If the transaction is started, it MUST complete. Since it didn't complete, it must be rolled back. Consistency would only be checked if WRITE(B) completed. Assume that it did. So, you did the whole transaction. Since you messed with B, the database will check to see if A+B=100 - which is a consistency rule on the database. If A+B does not equal 100, the transaction took the database to an inconsistent state. It must be rolled back.

You wanted a case where you are isolated and consistent but failed atomicity. Consider the previous two examples (which is why I specifically used them). We have a database that requires A+B=100. T1 = READ(A), WRITE(B). T2 = READ(C), WRITE(D). The operations run in the order we previously mentioned: T1:READ(A), T2:READ(C), T1:WRITE(B), T2:WRITE(D). However, the T1:WRITE(B) fails and B is not changed in any way. So, for Transaction 1, you have isolation. T2 did not affect anything that T1 was working with. You also have consistency (even though it wouldn't be checked). B did not change. Before T1 began, A+B had to equal 100 because we know the database started out consistent. Since B didn't change (and nothing changed A either), we know that A+B still equals 100. However, atomicity requires that if you perform READ(A), you must perform WRITE(B). The WRITE(B) failed, so atomicity failed, so we must roll back the transaction. Therefore, you can have isolation and consistency without atomicity. We can toss durability into another example if you like, but it just adds one more complication.

You are not making bad assumptions. Your assumptions are very common.

The hardest one to get students to drop is the assumption that atomicity implies mutual exclusion. That is not the case in transaction management. Imagine that it was the case: when a transaction starts, all other transactions are excluded from processing. That would mean that every transaction would run in a serial fashion. The entire point of transaction management is to run transactions in parallel. So, obviously, we can't use a rule that requires serial processing.

Another common assumption is that consistency implies that the transaction ran each operation properly. That is not true. Consider the example above. We start out with A+B=100. I read A. Then I write to B. If I write anything to B other than the current value of B, I've guaranteed that A+B is not 100. My transaction ran properly - it read and wrote just as I asked it to do. However, it broke the consistency rules and it would need to be rolled back (and I'd get a nasty message telling me that I was breaking the rules).

The third most common mistake that comes to mind is the belief that if a transaction uses a database item, nothing else can use it or you break isolation. There are three ways to break isolation. They are normally called Read-Write, Write-Write, and Write-Read.

Read-Write means that one transaction reads a value. Then, another transaction overwrites the value while the first transaction is still running. From that point on, the first transaction is working with a value that is invalid. Using our example above, assume your transaction reads A to ensure that when it writes to B the result of A+B will be 100. But, before you finish up, I write a new value to A. You did all you could to ensure consistency, but without isolation, I was able to mess it up.

Write-Write is based on the same idea except it is caused when one transaction writes a value and another overwrites it. So, instead me writing over A before you finish up, I overwrite B before you commit your changes. You made sure A+B=100. Then, before you said "I'm done" to the database, I stepped in and messed up your results.

Write-Read is commonly called a "dirty read". This is more complicated. Assume that I have a rather dumb transaction. I subtract 10 from A and then add 10 back to A. I subtract 10 (which is a write to A). You read A. You then ensure that A+B=100 so you can commit. Before you do that, I add 10 back to A. Again, lack of isolation caused a problem.

Finally, consider the read-read, which is not an isolation error. You read A. I read A. You do your thing. I do my thing - which doesn't include writing to A or B (because that would cause one of the above errors). We shared a resource without violating isolation.

Please let me know if any of that doesn't make sense. I normally teach this with animated slides. I find that watching the transaction move on the screen makes it easier for students to visualize. -- kainaw™ 00:43, 10 March 2009 (UTC)

Just found this, will have to mull it over, though that won't happen tonight. Thanks for following up. Will get back. 78.151.156.76 (talk) 00:03, 12 March 2009 (UTC)

(...responded on my talk page...) -- kainaw™ 14:00, 13 March 2009 (UTC)