ACID – Atomicity, Consistency, Isolation, Durability? – Information Systems Essay
ACID is an acronym that stands for Atomicity, Consistency, Isolation, and Durability. This term is used to describe enterprise level database transactions and the goals that every system must strive to achieve. The ACID model is one of the oldest and most important concepts of database theory and no database that fails to meet any of the four goals is considered reliable.
Atomicity is an all-or-none proposition. Suppose you define a transaction that contains an UPDATE, an INSERT, and a DELETE statement. With atomicity, these statements are treated as a single unit, and thanks to consistency (the C in ACID) there are only two possible outcomes: either they all change the database or none of them do. As we discussed in class this is important in situations like bank transactions where transferring money between accounts could result in disaster if the server were to go down after a DELETE statement but before the corresponding INSERT statement. It would simply not be acceptable for a bank system to only debit an account as it would in this system.
Consistency guarantees that a transaction never leaves the database in a semi finished state. If one part of the transaction fails, all of the pending changes are rolled back, leaving the database as it was before you initiated the transaction. Again as we discussed in class, when you delete a customer record, you should also delete all of that customer’s records from associated tables. A properly configured database wouldn’t let you delete the customer record, if that meant leaving remains of a customer’s records in a table such as invoices.
Isolation keeps transactions separated from each other until they’re finished. Transaction isolation is generally configurable in a variety of modes. For example, in one mode, a transaction blocks until the other transaction finishes. In a different mode, a transaction sees obsolete data. Suppose a user deletes a customer, and before the customer’s invoices are deleted, a second user updates one of those invoices. In a blocking transaction scenario, the second user would have to wait for the first user’s deletions to complete before issuing the update. The second user would then find out that the customer had been deleted, which is much better than losing changes without knowing about it.
Durability guarantees that the database will keep track of pending changes in such a way that the server can recover from an abnormal termination. Hence, even if the database server is unplugged in the middle of a transaction, it will return to a consistent state when it’s restarted. The database handles this by storing uncommitted transactions in a transaction log. By virtue of consistency (explained above), a partially completed transaction won’t be written to the database in the event of an abnormal termination. However, when the database is restarted after such a termination, it examines the transaction log for completed transactions that had not been committed, and applies them.