ACID is acronym of Atomicity, Consistency, Isolation and Durability
Atomicity requires that database modifications must follow an all or nothing rule. Each transaction is said to be atomic if when one part of the transaction fails, the entire transaction fails and database state is left unchanged. It is critical that the database management system maintains the atomic nature of transactions in spite of any application, DBMS, operating system or hardware failure.
An atomic transaction cannot be subdivided, and must be processed in its entirety or not at all. Atomicity means that users do not have to worry about the effect of incomplete transactions.
Transactions can fail for several kinds of reasons:
- Hardware failure: A disk drive fails, preventing some of the transaction’s database changes from taking effect
- System failure: The user loses their connection to the application before providing all necessary information
- Database failure: E.g., the database runs out of room to hold additional data
- Application failure: The application attempts to post data that violates a rule that the database itself enforces, such as attempting to create a new account without supplying an account number
The consistency property ensures that the database remains in a consistent state; more precisely, it says that any transaction will take the database from one consistent state to another consistent state.
The consistency property does not say how the DBMS should handle an inconsistency other than ensure the database is clean at the end of the transaction. If, for some reason, a transaction is executed that violates the database’s consistency rules, the entire transaction could be rolled
back to the pre-transactional state – or it would be equally valid for the DBMS to take some patch-up action to get the database in a consistent state. Thus, if the database schema says that a particular field is for holding integer numbers, the DBMS could decide to reject attempts to put fractional
values there, or it could round the supplied values to the nearest whole number: both options maintain consistency.
The consistency rule applies only to integrity rules that are within its scope. Thus, if a DBMS allows fields of a record to act as references to another record, then consistency implies the DBMS must enforce referential integrity: by the time any transaction ends, each and every reference in the database must be valid. If a transaction consisted of an attempt to delete a record referenced by
another, each of the following mechanisms would maintain consistency:
- Abort the transaction, rolling back to the consistent, prior state;
- Delete all records that reference the deleted record (this is known as cascade delete); or,
- nullify the relevant fields in all records that point to the deleted record.
These are examples of Propagation constraints; some database systems allow the database designer to specify which option to choose when setting up the schema for a database.
Application developers are responsible for ensuring application level consistency, over and above that offered by the DBMS. Thus, if a user withdraws funds from an account and the new balance is lower than the account’s minimum balance threshold, as far as the DBMS is concerned, the
database is in a consistent state even though this rule (unknown to the DBMS) has been violated.
Isolation refers to the requirement that other operations cannot access or see data that has been modified during a transaction that has not yet completed. The question of isolation occurs in case of concurrent transaction, (i.e. transaction occurring at the same time) and with the same database. To preserve the database consistency, the need of isolation arises. Each transaction must remain unaware of other concurrently executing transactions, except that one transaction may be forced to wait for the completion of another transaction that has modified data that the waiting transaction requires. If the isolation system does not exist, then the database may remain in an inconsistent state. This may happen as in case of concurrent transaction, one transaction may leave some data-items in mid process and at the same time another concurrent transaction may try to access/alter the same data-item which may cause data inconsistency and may leave the database in an inconsistent
Durability is the ability of the DBMS to recover the committed transaction updates against any kind of system failure (hardware or software). Durability is the DBMS’s guarantee that once the user has been notified of a transaction’s success, the transaction will not be lost. The transaction’s data changes will survive system failure, and that all integrity constraints have been satisfied, so the DBMS won’t need to reverse the transaction. Many DBMSs implement durability by writing transactions into a transaction log that can be reprocessed to recreate the system state right before any later failure. A transaction is deemed committed only after it is entered in the log.
Durability does not imply a permanent state of the database. A subsequent transaction may modify data changed by a prior transaction without violating the durability principle.
Thanks for reading the article.
Please comment if you have any questions or suggestions. Thanks