Databases Reference
In-Depth Information
Atomicity
— Either a transactional operation fully succeeds or completely fails. Nothing that
is inconsistent between the two states is acceptable. The canonical example that illustrates
this property is transferring funds from one account, say A, to another, say B. If $100 needs
to be transferred from A to B, $100 needs to be debited from (taken out of) A and credited
to (deposited into) B. This could logically mean the operation involves two steps: debit from
A and credit to B. Atomicity implies that if for some reason, debit from A occurs successfully
and then the operation fails, the entire operation is rolled back and the operation is not left
in an inconsistent state (where the money has been debited from A but not credited to B).
Consistency
— Consistency implies that data is never persisted if it violates a predefi ned
constraint or rule. For example, if a particular fi eld states that it should hold only integer
values, then a fl oat value is not accepted or is rounded to the nearest integer and then saved.
Consistency is often confused with atomicity. Also, its implication in the context of RDBMS
often relates to unique constraints, data type validations, and referential integrity. In a
larger application scenario, consistency could include more complex rules imposed on the
data but in such cases the task of maintaining consistency is mostly left to the application.
➤
➤
Isolation
— Isolation gets relevant where data
is accessed concurrently. If two independent
processes or threads manipulate the same data set,
it's possible that they could step on each other's
toes. Depending on the requirement, the two
processes or threads could be isolated from each
other. As an example, consider two processes,
X and Y, modifying the value of a fi eld V, which
holds an initial value V0. Say X reads the value
V0 and wants to update the value to V1 but before
it completes the update Y reads the value V0 and
updates it to V2. Now when X wants to write the
value V1 it fi nds that the original value has been
updated. In an uncontrolled situation, X would
overwrite the new value that Y has written, which
may not be desirable. Look at Figure 9-1 to view
the stated use case pictorially. Isolation assures that
such discrepancies are avoided. The different levels
and strategies of isolation are explained later in a
following section.
Durability
— Durability implies that once a
transactional operation is confi rmed, it is assured.
The case where durability is questioned is when a
client program has received confi rmation that a transactional operation has succeeded but
then a system failure prevents the data from being persisted to the store. An RDBMS
often maintains a transaction log. A transaction is confi rmed only after it's written to
the transaction log. If a system fails between the confi rmation and the data persistence, the
transaction log is synchronized with the persistent store to bring it to a consistent state.
➤
V
Read (V0)
X
V0
Y
V
X
Read (V0)
V0 -> VI
Y
Write (V1)
V
X
V1 -> ?
Y
Write (V2)
➤
FIGURE 9-1
