Atomicity (database systems)
From Wikipedia, the free encyclopedia
In database systems, atomicity (or atomicness) forms one of the ACID group of transaction properties. In an atomic transaction, a series of database operations either all occur, or all do not occur ("fail", although the model does not regard failure as catastrophic). A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.
The etymology of the phrase originates in the Classical Greek concept of a fundamental and indivisible component; see atom.
One example of atomicity comes from ordering airline-tickets. Potential passengers must either:
- both pay for and reserve seats on a flight; OR
- neither pay for nor reserve seats
The booking-system does not treat it as acceptable for customers to pay for tickets without securing their requested flight or to reserve tickets without payment succeeding.
[edit] 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 manually roll back the enclosing transaction may cause failures of isolation and consistency.
[edit] 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 (see journaling file system). Many databases also support a commit-rollback mechanism aiding in the implementation of atomic transactions. Databases usually implement this using some form of logging/journaling to track changes. The system synchronizes the logs (often the metadata) 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, which in turn makes use of specialized hardware to guarantee that an operation remains non-interruptible: either by software attempting to re-divert system resources (see pre-emptive multitasking) or by resource-unavailability (such as 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 in achieving atomic operations from userspace include mkdir(2), flock(2), fcntl(2), rasctl(2) (NetBSD re-startable sequences), semop(2), sem_wait(2), sem_post(2), fdatasync(2), fsync(2) and rename(2).
The hardware level requires atomic operations such as test-and-set (TAS), and/or atomic increment/decrement operations. In their absence, or when necessary, raising the interrupt level to disable all possible interrupts (of hardware and software origin) may serve to implement the atomic synchronization function primitives. Systems often implement these low-level operations in machine language or in assembly language.
