|
In database systems, atomicity is one of the ACID transaction properties. An atomic transaction is a database transaction which either completely occurs (commits), or has no effects (rolled back). Guaranteeing atomic transactions frees the programmer from worrying about accidentally making partial updates to the database. Atomicity is relied on to preserve the invariants in a system even if a group of operations fails mid-way. For example, if one were using a database to maintain a double-entry book-keeping accounting system (ignoring the redundancy here), a system invariant would be that any transaction must have a zero sum: if the amount of fixed assets in the business increases, the amount of cash must be reduced in kind. Atomicity allows a transaction that successfully increases the fixed assets but fails before reducing the amount of cash to be rolled back, restoring the number of fixed assets. The interface between database and programming environment may reintroduce problems that a programmer might naively expect atomic transactions to do away with. For instance, if an operation fails in a transaction, it is often the programmer's responsibility to detect that failure and manually roll back the transaction before retrying. Not doing so will result in a partially-completed transaction!
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. 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 copy 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, 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. See also | ||||||||
|
| |||||||||
 |
|
| |