ACID properties are an important concept for databases or data sharing techniques.
The acronym stands for Atomicity, Consistency, Isolation, and Durability.
The ACID properties of a DBMS allow safe sharing of data.
Without these ACID properties, everyday occurrences such using computer systems to buy products would be difficult and the potential for inaccuracy would be huge. Imagine more than one person trying to buy the same size and color of a sweater at the same time — a regular occurrence. The ACID properties make it possible for the merchant to keep these sweater purchasing transactions from overlapping each other — saving the merchant from erroneous inventory and account balances.
The atomicity property identifies that the transaction is atomic. An atomic transaction is either fully completed, or is not begun at all.
Any updates that a transaction might affect on a system are completed in their entirety.If for any reason an error occurs and the transaction is unable to complete all of its steps, the then system is returned to the state it was in before the transaction was started.
An example of an atomic transaction is an account transfer transaction. The money is removed from account A then placed into account B. If the system fails after removing the money from account A, then the transaction processing system will put the money back into account A, thus returning the system to its original state.
- atomicity is maintained in the presence of deadlocks
- atomicity is maintained in the presence of database software failures
- atomicity is maintained in the presence of application software failures
- atomicity is maintained in the presence of CPU failures
- atomicity is maintained in the presence of disk failures
- atomicity can be turned off at the system level
- atomicity can be turned off at the session level
A transaction enforces consistency in the system state by ensuring that at the end of any transaction the system is in a valid state. If the transaction completes successfully, then all changes to the system will have been properly made, and the system will be in a valid state.
Looking again at the account transfer system, the system is consistent if the total of all accounts is constant. If an error occurs and the money is removed from account A and not added to account B, then the total in all accounts would have changed. The system would no longer be consistent. By rolling back the removal from account A, the total will again be what it should be, and the system back in a consistent state.
When a transaction runs in isolation, it appears to be the only action that the system is carrying out at one time.
If there are two transactions that are both performing the same function and are running at the same time, transaction isolation will ensure that each transaction thinks it has exclusive use of the system.
This is important in that as the transaction is being executed, the state of the system may not be consistent.
The transaction ensures that the system remains consistent after the transaction ends, but during an individual transaction, this may not be the case. If a transaction was not running in isolation, it could access data from the system that may not be consistent. By providing transaction isolation, this is prevented from happening.
Durability refers to the ability of the system to recover committed transaction updates if either the system or the storage media fails.
Maintaining updates of committed transactions is critical. These updates must never be lost. The ACID property of durability addresses this need.
Features to consider for durability:
- recovery to the most recent successful commit after a database software failure
- recovery to the most recent successful commit after an application software failure
- recovery to the most recent successful commit after a CPU failure
- recovery to the most recent successful backup after a disk failure
- recovery to the most recent successful commit after a data disk failure