The ACID model is one of the oldest database theory concepts. It includes four goals that every database management system must try to achieve: atomicity, consistency, isolation and durability. If the database does not meet these four goals, it is not considered reliable. Databases that do meet these four goals are considered to be reliable and ACID compliant.
Let’s learn more about each component in the ACID model and the strategies used to support it.
Defining the ACID Model
Here are more specifics on the characteristics of the ACID model.
- Atomicity. Transactions are made up of multiple statements. Atomicity ensures that each transaction is treated as a single unit that either succeeds or fails. So, if any of the statements within a transaction fail, the whole transaction fails and the database is left unchanged.
- Consistency. Consistency ensures that only valid data is included in the database. If a transaction violates the database’s consistency rules, it will be stopped and the database will be unchanged. This prevents illegal transactions from taking place.
- Isolation. Isolation means that multiple transactions happening at the same time will not impact each other. Isolation supports concurrency control and prevents transactions from interfering with each other.
- Durability. Once a transaction is complete, it will remain that way, even if there is a system failure. Durability is ensured through database backups, transaction logs and other security measures.
Putting the ACID Model into Practice
The ACID model can be executed using several different strategies. For atomicity and durability, database administrators may use write-ahead logging (WAL) that places all transaction data in a special log. If the database were to fail, the administrator could check the log and compare its content to what’s in the database.
Another strategy is shadow-paging, which is where a shadow page is created with content that can be modified. Updates are added to the shadow page instead of the actual database, and the database is only updated when the edit has been completed.
The two-phase commit protocol is another strategy, ideal for distributed database systems. When data is modified, it’s split into two requests: a commit-request phase and a commit phase. In the commit-request phase, all databases affected by the transaction must confirm that they have received the request and are able to perform it. When confirmation has been received, the commit phase completes the data.
The ACID model can be difficult to understand at first, but Arkware is here to do the heavy lifting for you! Give us a call and we’ll find the best database solution for your needs.