This preview shows pages 1–2. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: CS-350: Fundamentals of Computing Systems Page 1 of 9Lecture Notes Azer Bestavros. All rights reserved. Reproduction or copying (electronic or otherwise) is expressly forbidden except for students enrolled in CS-350. The Concept of Transactions The notion of a "transaction" is a recurring one when building computing systems in general, and database systems in particular. Consider, for example, the task of transferring money between two accounts. The program to be executed to complete this transfer is likely to consist of a number of steps, including the two main steps of "subtracting the transfer amount from one account" and the "addition of the transfer amount to the other account." For such a task (and for many others), the following properties are important for the computing system to maintain/satisfy: 1.Atomicity:The execution of a transaction must be performed in an "all or nothing" fashion. In other words, the partialresults (or intermediate system state) must not be possible to observe by any entity other than the transaction itself. 2.Consistency:Assuming that the state of the system (e.g. the values in various records in various relations of a relational database) before executing a transaction is correct (e.g. all GPA's are between 0 and 4, etc.) then, after executing the transaction, the state of the system continues to be correct. 3.Isolation:The execution of a transaction is isolated from the possibly concurrent execution of other transactions in the system i.e., the completion of a transaction does not have to depend on the successful completion (or failure) of any other transaction. A necessary condition for that is that transactions are not able to observe the partial results of other transactions (a.k.a., atomicity). 4.Durability:Once the system "commits" a transaction, the results (or effects) of the transaction execution must persist even if the system crashes (say before changes to the system state are saved to disk). In other words, the changes due to a committed transaction are permanent(e.g. once an airplane seat is assigned to a customer, it cannot be taken away!) The above properties are commonly called the "ACID" properties of transaction (ACID= Atomicity + Consistency + Isolation + Durability). Example to Illustrate ACID properties: We discuss the ACID properties using an example. Consider our banking transaction example we alluded to earlier. Consider two transactions A and B to access the same account and as well as the possible concurrent execution of any number of these transactions. You can think of these transactions as being executed by members of the same family (sharing the bank account) using different ATM cards....
View Full Document
This document was uploaded on 04/14/2011.
- Spring '09