In database systems, atomicity is one of the ACID transaction properties. In an
atomic transaction, a series of database operations either all occur, or nothing
occurs. The series of operations cannot be divided apart and executed partially
from each other, which makes the series of operations "indivisible", hence the
name. A guarantee of atomicity prevents updates to the database occurring only
partially, which can cause greater problems than rejecting the whole series
outright. In other words, atomicity means indivisibility and irreducibility.
As a consequence, the transaction cannot be observed to be in progress by another
database client. At one moment in time, it has not yet happened, and at the next
it has already occurred in whole. The etymology of the phrase originates
in the Classical Greek concept of a fundamental and indivisible component;
see atom. Examples
An example of atomicity is ordering an airline ticket where two actions are
required: payment, and a seat reservation. The potential passenger
must either: both pay for and reserve a seat; OR
neither pay for nor reserve a seat. The booking system does not consider it
acceptable for a customer to pay for a ticket without securing the seat, nor to
reserve the seat without payment succeeding.
Another example is that if one wants to transfer some amount of money from one
account to another, then the user would start a procedure to do it. However, if
a failure occurs, then due to atomicity, the amount will either be transferred
completely or will not be even initiated. Thus atomicity protects the
user from losing money due to a failed transaction.
Orthogonality Atomicity does not behave completely
orthogonally with regard to the other ACID properties of the transactions. For
example, isolation relies on atomicity to roll back changes in the event of
isolation failures such as deadlock; consistency also relies on rollback in
the event of a consistency-violation by an illegal transaction. Finally,
atomicity itself relies on durability to ensure the atomicity of transactions
even in the face of external failures. As a result of this, failure to detect
errors and roll back the enclosing transaction may cause failures of
isolation and consistency. Implementation
Typically, systems implement atomicity by providing some mechanism to indicate
which transactions have started and which finished; or by keeping a copy of
the data before any changes occurred. Several filesystems have developed
methods for avoiding the need to keep multiple copies of data, using
journaling. Databases usually implement this using some form of
logging/journaling to track changes. The system synchronizes the logs as
necessary once the actual changes have successfully taken place. Afterwards,
crash recovery simply ignores incomplete entries. Although implementations vary
depending on factors such as concurrency issues, the principle of atomicity —
i.e. complete success or complete failure — remain.
Ultimately, any application-level implementation relies on
operating-system functionality. At the file-system level, POSIX-compliant
systems provide system calls such as open(2) and flock(2) that allow
applications to atomically open or lock a file. At the process level, POSIX
Threads provide adequate synchronization primitives.
The hardware level requires atomic operations such as Test-and-set,
Fetch-and-add, Compare-and-swap, or Load-Link/Store-Conditional, together
with memory barriers. Portable operating systems cannot simply block interrupts
to implement synchronization, since hardware that lacks actual concurrent
execution such as hyper-threading or multi-processing is now extremely rare.
In NoSQL data stores with eventual consistency, the atomicity is also
weaker specified than in relational database systems, and exists only in
rows. See also
Atomic operation Transaction processing
Long-running transaction Read-copy-update
References