What is an ACID transaction?
ACID (Atomicity, Consistency, Isolation, Durability) is a set of database transaction management. For example, a transaction is made from one account to another account; a code first withdraws money from one account and then deposits it into the receiver account. There are two steps in this transaction; however there is possibility of failure. For example, the depositing step could fail while money has already withdrawn from the first account.
ACID prevents this kind of failure by ensuring that every step of transaction is done. The ACID features of a database are important in any mission-critical business application; particularly in on-line transaction processing systems. The Atomicity refers the ability of database management system to guarantee that all the transactions have taken place. If some part of the transactions is not preceded then none of the transactions takes place. Atomic transaction ensures that transactions are committed entirely and not partially.
Atomicity provides the “all or nothing” property of transactions which is critical in the database management system. The implementation of atomicity provides mechanisms to signify which transactions have been started and finished. It also can be implemented by keeping the data’s copy before any changes were made.
Consistency makes sure that only valid data is sent to the database. It guarantees that the database is not left half-finished in a transaction. A consistency transaction does not violate any integrity constraints during execution. In this transaction, database is being aborted; if it is left in an illegal state. If there is a failure in a part of the transaction, all of the changes are cancelled, leaving the database as before the transaction was initiated.
Isolation separates transactions from one another; until the whole process is finished. For example, operator in one bank cannot see the transferred funds on both accounts. It can only see one of them. With isolation, the transaction history is being serialized. This way, multiple transactions that occur at the same time will not give impact each other. It has four levels; serializable, repeatable read, read committed, and read uncommitted.
Serializability is where the property of a schedule (history) being serializable. It prevents overlapping of two or several transactions at the same time. In the repeatable read level, the transaction receives read locks on all retrieved data, but does not receive range locks. During read committed level, read locks are acquired on selected data and then released immediately at the end of transaction. In the end, the in read uncommitted step, only one transaction may see uncommitted changes made by other transaction.
Durability ensures that the database will keep track of the pending changes allowing server to recover from an abnormal termination. Durability use database backups and transaction logs to facilitate the restoration of committed transactions. Through this mechanism, the transaction can survive system failure including missing transactions. To implement durability, before acknowledging commitment, transaction’s log records are being burn to disk. However, in distributed transaction, all participating servers must know about all the stored data and check the consistency constraints, before commit can be acknowledged.
The implementation of ACID is not a simple matter; transaction processing needs a number of small changes to be made, including updating indices, which are used to speed up searches. There is a huge possibility that this operations sequence turns to fail due to several reasons; for example, it might run out of disk space.
As arranging database to perform all these operations at once is a difficult takes; which makes its essential to apply two different techniques; write ahead and shadow paging. The locks are required on all updated information, however it depends on the implementation of all the current read data. In write ahead logging, atomicity is guaranteed by making sure that information about all changes is written to log; before it is written to the database. This would allow database to maintain consistency; if there is a system crash.
However maintaining large number of locks can also result on substantial overhead or hurting concurrency. The alternative is the multi-version concurrency control. The database is responsible of taking care of some of the copies of any modified data. This way, the user is able to read data without acquiring any locks.
Without ACID system, everyday Internet occurrences; such as buying online products would be difficult; and there would be a huge potential of inaccuracy. Suppose a hundred people are buying the same product on the Internet; the ACID properties makes it possible for the merchant to keep these transactions from overlapping. This helps the merchant to avoid faulty inventory and account balances.
Passing the ACID test means that the appropriate data is safe to be stored, retrieved quickly and can be supported in multiple. It is a must for e-business or Web-based applications. This is why a lot of companies and individuals apply enterprise-level of database systems, like IBM DB2® Universal Database, Oracle 10g, or Microsoft® SQL Server, which fully compliant with the ACID test.
Sushil Jajodia, Larry Kerschberg, (1997). Advanced Transaction Models and Architectures. Springer.
Chapple, M (2002, Dec 13.). The ACID Model. Retrieved May 15
2007, from http://databases.about.com/od/specificproducts/