Transaction
lastmod 2018-10-02created 2015-10-253 edits
ACID
ACID (atomicity, consistency, isolation, durability) is an acronym for the properties that guarantee database transactions are executed safely. Jim Gray defined these characteristics of reliable transaction systems in the late 1970s and developed technology to enforce them automatically.
In 1983, Andreas Reuter and Theo Härder described this while coining the term ACID.
In a database, a single logical unit of execution on data is called a transaction. For example, a bank account transfer can be called a transaction: the transfer itself may be implemented internally in several steps, but as a whole, 'decreasing the amount in the sender's account' and 'increasing the amount in the recipient's account' must happen as a single operation.
- Atomicity is the ability to guarantee that the operations involved in a transaction are not partially executed and then aborted. For example, a funds transfer may succeed or fail, but it must not be the case that only taking money out of the sender succeeds while putting money into the recipient fails. Atomicity ensures that execution never fails after running only partway through like this.
- Consistency means that whenever a transaction completes successfully, the database is always kept in a consistent state. If an integrity constraint says every account must have a balance, any transaction that violates it is aborted.
- Isolation means guaranteeing that, while a transaction is running, operations of other transactions cannot interfere. This means no operation outside the transaction can see data in an intermediate state. Even if a bank manager runs a query during a transfer, they cannot see both sides of a transfer between particular accounts. Formally, isolation means the transaction execution history must be serial. For performance reasons, this property is the most flexible constraint. See the related documentation for details.
- Durability means that a successfully executed transaction must be reflected permanently. It must persist even through system problems, DB consistency checks, etc. Typically every transaction is logged, and the state before a system failure can be restored. A transaction can be considered committed only after everything has been saved to the log.
Transactional memory
Transactional memory is an approach that simplifies concurrent programming by allowing a group of load and store instructions to execute atomically. It is a concurrency control mechanism for controlling access to shared memory in concurrent computing, a concurrency control structure similar to database transactions.
Hardware transactional memory
Hardware transactional memory systems include modifications to processors, caches, and bus protocols to support transactions.
Software transactional memory
Software Transactional Memory (STM), in computer science, is a concurrency control structure similar to database transactions for controlling access to shared memory in parallel computing.
Software transactional memory provides transactional memory semantics in a software runtime library or programming language, and requires minimal hardware support (typically an atomic compare-and-swap instruction or an equivalent instruction).
The load-link/store-conditional (LL/SC) provided by many RISC processors can be regarded as the most basic form of transactional memory support. However, LL/SC generally operates on data the size of a native machine word.
See also
- Synchronization
-
ACID(This document) -
Transactional memory(This document) -
Hardware transactional memory(This document) -
Software transactional memory(This document) - [Recommended] Multiversion concurrency control (MVCC) (a common implementation method for database transactions)
Favorite site
- NAVER D2: How does a DBMS manage transactions?
- Transaction & Concurrency Control
- Implementing a simple REST-based distributed transaction - Part 1