Editing Atomicity (database systems)

{{short description|Property of the ACID database system}}
{{More citations needed|date=April 2020}}
In [[database system]]s, '''atomicity''' ({{IPAc-en|ˌ|æ|t|ə|ˈ|m|ɪ|s|ə|t|i}}; from {{langx|grc|ἄτομος|átomos|undividable}}) is one of the [[ACID]] (''Atomicity, Consistency, [[Isolation (database systems)|Isolation]], [[Durability (database systems)|Durability]]'') transaction properties. An '''atomic transaction''' is an ''indivisible'' and ''[[Irreducibility|irreducible]]'' series of database operations such that either ''all'' occur, or ''none'' occur.<ref>{{cite web
| access-date = 2011-03-23
| publisher = Webopedia
| title = atomic operation
| date = 25 November 2003
| quote = An operation during which a processor can simultaneously read a location and write it in the same bus operation. This prevents any other processor or I/O device from writing or reading memory until the operation is complete.
| url = http://www.webopedia.com/TERM/A/atomic_operation.html}}</ref> A guarantee of atomicity prevents partial database updates from occurring, because they can cause greater problems than rejecting the whole series outright. 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 (or nothing happened if the transaction was cancelled in progress).

An example of an atomic transaction is a monetary transfer from bank account A to account B. It consists of two operations, withdrawing the money from account A and saving it to account B. Performing these operations in an atomic transaction ensures that the database remains in a [[Data consistency|consistent state]], that is, money is neither lost nor created if either of those two operations fails.<ref>{{cite web
| url = http://archive.oreilly.com/pub/a/onjava/2001/11/07/atomic.html
| url-status = dead
| archive-url = https://web.archive.org/web/20160303090517/http://archive.oreilly.com/pub/a/onjava/2001/11/07/atomic.html
| archive-date = 2016-03-03
| title = Atomic File Transactions, Part 1
| last = Amsterdam
| first = Jonathan
| website = O'Reilly
| access-date = 2016-02-28
}}</ref>

The same term is also used in the definition of First normal form in database systems, where it instead refers to the concept that the values for fields may not consist of multiple smaller values to be decomposed, such as a string into which multiple names, numbers, dates, or other types may be packed.

==Orthogonality==
Atomicity does not behave completely [[Orthogonal (computing)|orthogonally]] with regard to the other [[ACID]] properties of transactions. For example, [[Isolation (database systems)|isolation]] relies on atomicity to roll back the enclosing transaction in the event of an isolation violation such as a [[Deadlock (computer science)|deadlock]]; [[Consistency (database systems)|consistency]] also relies on atomicity to roll back the enclosing transaction in the event of a consistency violation by an illegal transaction.

As a result of this, a failure to detect a violation and roll back the enclosing transaction may cause an isolation or consistency failure.

==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 ([[read-copy-update]]).  Several filesystems have developed methods for avoiding the need to keep multiple copies of data, using journaling (see [[journaling file system]]). Databases usually implement this using some form of logging/journaling to track changes. The system synchronizes the logs (often the [[metadata]]) as necessary after changes have successfully taken place. Afterwards, crash recovery 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|operating-system]] functionality.  At the file-system level, [[POSIX]]-compliant systems provide [[system call]]s such as <code>open(2)</code> and <code>flock(2)</code> that allow applications to atomically open or lock a file. At the process level, [[POSIX Threads]] provide adequate synchronization primitives.

The hardware level requires [[linearizability|atomic operations]] such as [[Test-and-set]], [[Fetch-and-add]], [[Compare-and-swap]], or [[Load-Link/Store-Conditional]], together with [[memory barrier]]s. Portable operating systems cannot simply block interrupts to implement synchronization, since hardware that lacks concurrent execution such as [[hyper-threading]] or [[multi-processing]] is now extremely rare.{{Citation needed|date=December 2016}}

==See also==
* [[Atomic operation]]
* [[Transaction processing]]
* [[Long-running transaction]]
* [[Read-copy-update]]

==References==
{{reflist}}

{{DEFAULTSORT:Atomicity (Database Systems)}}
[[Category:Data management]]
[[Category:Transaction processing]]