Atomicity
From Wikipedia, the free encyclopedia
In database systems, atomicity is one of the ACID transaction properties. An atomic transaction is a series of database operations which either all occur, or all do not occur ("fail", although failure is not considered catastrophic). A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.
One example of atomicity is in ordering airline tickets. Tickets must either be paid for and reserved on a flight, or neither paid for nor reserved. It is not acceptable for customers to pay for tickets without securing their requested flight or to reserve tickets without payment succeeding. One atomic transaction might include the booking not only of flights, but of hotels and transport, in exchange for the right money at the exact current exchange rate.
[edit] Orthogonality
Atomicity is not completely orthogonal to the other ACID properties of 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 transactions are atomic even in the face of external failures.
As a result of this, failure to detect errors and manually roll back the enclosing transaction may cause isolation and consistency failures.
[edit] Implementation
Typically, atomicity is implemented by providing some mechanism to indicate which transactions have been started and finished, or by keeping a copy of the data before any changes were made. Several filesystems have developed methods for avoiding the need to keep multiple copies of data, using journaling (see journaling file system). Many databases also support a commit-rollback mechanism aiding in the implementation of atomic transactions. These are usually also implemented using some form of logging/journaling to be able to track changes. These logs (often the metadata) are synchronized as necessary once the actual changes were successfully made. Unrecorded entries are simply ignored afterwards on crash recovery. Although implementations vary depending on factors such as concurrency issues, the principle of atomicity - ie. complete success or complete failure - remain.
Ultimately, any application-level implementation relies on operating system functionality which in turn makes use of specialized hardware to guarantee that an operation is non-interruptible by either software attempting to re-divert system resources (see pre-emptive multitasking) or resource unavailability (e.g. power outages). For example, POSIX-compliant systems provide the open(2) system call which allows applications to atomically open a file. Other popular system calls that may assist to achieve atomic operations from userspace consist of mkdir(2), flock(2), fcntl(2), rasctl(2) (NetBSD restartable sequences), semop(2), sem_wait(2), sem_post(2), fdatasync(2), fsync(2) and rename(2).
At the hardware level, atomic operations such as test-and-set (TAS), and/or atomic increment/decrement operations are needed. When these are lacking, or when necessary, raising the interrupt level to disable all possible interrupts (of hardware and software origin) may be used to implement the atomic synchronization function primitives. These low-level operations are often implemented in machine language or assembly language.
The etymology of the phrase originates in the Classical Greek concept of a fundamental and indivisible component; see atom.
