Bitcoin Forum

ACID (database transactions)

A database transaction (http://en.wikipedia.org/wiki/Database_transaction), by definition, must be atomic, consistent, isolated and durable. Database practitioners often refer to these properties of database transactions using the acronym ACID.

atomic (http://en.wikipedia.org/wiki/Atomicity_(database_systems))
 In an atomic transaction, a series of database operations either all occur, or nothing occurs. A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright. In other words, atomicity means indivisibility and irreducibility.

consistent (http://en.wikipedia.org/wiki/Consistency_(database_systems))
 In database systems, a consistent transaction is one that starts with a database in a consistent state and ends with the database in a consistent state. Consistent state means that there is no violation of any integrity constraints. Consistency may temporarily be violated during execution of the transaction, but must be corrected before changes are permanently committed to the database. If the transaction would leave the database in an illegal state, it is aborted and an error is reported.

isolated (http://en.wikipedia.org/wiki/Isolation_(database_systems))
 In database systems, isolation is a property that defines how/when the changes made by one operation become visible to other concurrent operations
Concurrency control [...] The transaction-related mechanisms typically constrain the database data access operations' timing (transaction schedules) [...]  Constraining database access operation execution typically means reduced performance (rates of execution), [...] Often, when possible without harming correctness, the serializability property is compromised for better performance. However, recoverability cannot be compromised, since such typically results in a quick database integrity violation. [...]

durable (http://en.wikipedia.org/wiki/Durability_(database_systems))
 [...]  durability is the ACID property which guarantees that transactions that have committed will survive permanently. For example, if a flight booking reports that a seat has successfully been booked, then the seat will remain booked even if the system crashes. Durability can be achieved by flushing the transaction's log records to non-volatile storage before acknowledging commitment. In distributed transactions, all participating servers must coordinate before commit can be acknowledged. This is usually done by a two-phase commit protocol.


ACID failure examples: http://en.wikipedia.org/wiki/ACID#Examples

...

..

.

_

 ;)