The ACID Properties - Firebird

It is now more than 20 years since two researchers, Theo Haërder and Andreas Reuter, published a review paper describing requirements for maintaining the integrity of a database in a parallel updating environment. They distilled the requirements into four precepts defined as atomicity, consistency, isolation, and durability—abbreviated as ACID. Over the succeeding years, the ACID concept evolved as a benchmark for the implementation of transactions in database systems.

Atomicity

A transaction (also known as a unit of work) is described as consisting of a collection of data -transforming actions. To be “atomic,” the transaction must be implemented in such a way that it provides the “all -or -nothing illusion that either all of these operations are performed or none of them is performed.” The transaction either completes as a whole (commits) or aborts (rolls back).

Consistency

Transactions are assumed to perform correct transformations of the abstract system state—that is, the database must be left in a consistent state after a transaction completes, regardless of whether it commits or rolls back. The transaction concept assumes that programmers have mechanisms available to them for declaring points of consistency and validating them. In SQL, the standards provide for triggers, referential integrity constraints, and check constraints to implement those mechanisms at the server.

Isolation

While a transaction is updating shared data, the system must give each transaction the illusion that it is running in isolation; it should appear that all other transactions ran either before it began or after it committed. While data is in transition from a starting consistent state to a final consistent state, it may be inconsistent with database state, but no data may be exposed to other transactions until the changes are committed.

Next chapter explores the three levels of isolation for transactions that Firebird implements, along with the options available to respond to conflicts and prevent the work of one transaction from interfering with the work of another.

Durability

Once a transaction commits, its updates must be durable—that is, the new state of all objects made visible to other transactions by the commit will be preserved and irreversible, regardless of events such as hardware failure or software crashing


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Firebird Topics