Atomicity in DBMS – A Comprehensive Guide

The idea of atomicity is a fundamental transaction management principle in the Database Management Systems (DBMS) world. One of the ACID properties (Atomicity, Consistency, Isolation, Durability) guarantees the all-or-nothing transaction execution of a database. If all the operations inside a transaction are treated as indivisible units, the transaction is considered atomic, and all operations either succeed or fail.

In this article, we discuss the role of atomicity in a DBMS, its impact on data integrity, and its influence on the reliability of database systems. This establishes four properties of DBMS data known as the ACID properties so that data can be reliable. Atomicity in DBMS is one of an application’s ACID properties where the transactions aren’t committed unless the entire transaction is completed successfully. This article highlights what atomicity in DBMS means and why it is necessary.

Understanding Atomicity in Detail

In the context of a database management system, the ACID model consists of Atomicity, Consistency, Isolation, and Durability concepts used to denote the transaction, making the database reliable. DBMS atomicity says that a transaction must be completed or not at all, and there’s no in-between, so transactions never partially occur. An atomic transaction in a database management system is a sequence of indivisible, irreducible database actions; either everything happens or nothing happens.

This form of atomicity assures you of atomicity, so you know that you won’t get rid of the entire series up front: incomplete database modifications will lead to more problems than just rejecting the entire series. As such, no other database client has witnessed this progress. It has not happened yet at one point; from another, it has entirely happened, or it just doesn’t have any changes if the transaction in progress is cancelled.

Every transaction is a unit of work and has two key operations:

• Commit: This triggers the changes if this happens and the transaction is complete.
• Abort: When this happens, the business does not get to enter the database, nor would the transaction take place.

The database is atomic, meaning there are no incomplete manipulations, and the database remains consistent. A typical example of this is order processing. If a person places an order and makes payment for the total order, the whole order will be processed, and the person will receive the order. However, if the order does not get processed at all, then there is no shipment of the order. The atomicity is mainly accomplished by processes such as journaling, logging, or operations system calls.

To establish atomicity in a Database Management System (DBMS) and ensure that either all operations within a transaction are completed or none are executed, several techniques are commonly used:

Undo Log

A transaction makes changes that are stored on an undo log until they are committed. If the transaction fails, the database is guaranteed to be “consistent”—no changes have been made—by rolling the transaction back and using the undo log to reverse the changes.

Redo Log

Redo log records the changes after a transaction has been committed. If a commit is complete after running a database update but before the new changes are written to disk, the redo log provides a means of reapplying those changes to keep data intact.

Two-Phase Commit

A distributed system employs the two-phase commit protocol for committing or aborting a transaction, so all nodes either commit or abort it. This results in atomic execution across multiple nodes and assures consistency in the whole system.

Locking

Multiple transactions cannot read and write data concurrently until the locking mechanisms are removed. Locking prevents conflicts and keeps the database consistent by requiring a single transaction to edit only a given piece of data at a time.

Journaling

For example, file systems use a journaling mechanism to record changes, allowing them to be atomic since a record of what changed is kept in some way prior to changes being final. This allows them to recover from failures without compromising the integrity of data.

System Calls and Synchronisation Primitives

Operating systems provide system calls, which help execute atomic transactions without interference, using open() and flock() and synchronisation mechanisms like POSIX threads.

Hardware-Level Operations

Atomicity is maintained by keeping atomic operations at the hardware level, analogous to Test-and-set, Fetch-and-add, Compare-and-swap, and Load-Link, Store-Conditional, using memory barriers.

Read more: What Are the Major Components of DBMS

Examples

This atomicity has already been discussed in DBMS. Some examples should help clarify the concept of atomicity.

Example 1) Atomicity in Online Food Delivery Systems

Imagine an online food delivery system. When a customer orders, two critical actions must occur: entering the restaurant’s email address, processing the payment, and notifying the restaurant to prepare the food. To ensure a transaction’s validity, both actions must be completed. While the restaurant is unaware that the customer pays for a meal, the payment is successful, and this is just another opportunity for the customer to pay for a meal that never gets prepared. On the other hand, if the food is being made but payment fails, the restaurant loses without getting paid. For this reason, both of these actions must be atomic — they either happen or don’t.

Example 2) Atomicity in E-commerce purchases

Imagine a person purchasing a product from an e-commerce website. The purchase involves two main steps: Putting the payment into the platform’s vault, debiting it from the customer’s account, and updating the inventory there. If the inventory update fails, even if the payment was deducted successfully, the customer will end up with a confirmed order for an unavailable product. In alternate cases, when the payment fails first but the inventory is updated, the system will mark it out of stock without charging the customer. Both become imperative: in order for the transaction to be complete and consistent, both steps have to succeed together.

Also read: DBMS Interview Questions with Answers

Conclusion

In conclusion, the principle of atomicity is important in assuring the integrity and reliability of database transactions. The concept guarantees the same treatment of transactions in the same way they are indivisible units, and hence, either that transaction commits all its changes or none of them. The consistency of the database is important, but this property is particularly important to protect while many operations are being carried out. Every transactional statement in a database management system should succeed or fail atomically – in the case of power outages, mistakes, or system crashes. Imagine a money transfer transaction — in such a transaction, debiting and crediting must happen at the same time or not at all.

What constitutes an atomic transaction depends on which situation the atomic transaction is being executed. A database system that is able to do atomicity guarantees has to continue doing so even if the electric supply or the underlying operating system or software that does the database fails. Building a robust database system that can recover from failures and errors is dependent on the ability to enforce atomicity. For more information about other ACID properties in DBMS, visit here.