NoSQL concepts - Making Sense of NoSQL - page 25

When you click the Transfer button on the web page, two discrete operations must
happen in unison. The funds are subtracted from your savings account and then
added to your checking account. Transaction management is the process of making
sure that these two operations happen together as a single unit of work or not at all. If
the computer crashes after the first part of the transaction is complete and before the
second part of the transaction occurs, you'd be out $1,000 and very unhappy with
your bank.
Traditional commercial RDBMS s are noted for their reliability in performing finan-
cial transactions. This reputation has been earned not only because they've been
around for a long time and diligently debugged their software, but also because
they've made it easy for programmers to make transactions reliable by wrapping criti-
cal transactions in statements that indicate where transactions begin and end. These
are often called BEGIN TRANSACTION and END TRANSACTION statements. By adding
them, developers can get high-reliability transaction support. If either one of the two
atomic units doesn't complete, both of the operations will be rolled back to their ini-
tial settings.
The software also ensures that no reports can be run on the accounts halfway
through the operations. If you run a “combined balance” report during the transac-
tion, it'd never show a total that drops by 1,000 and then increases again. If a report
starts while the first part of the transaction is in process, it'll be blocked until all parts
of the transaction are complete.
In traditional RDBMS s the transaction management complexity is the responsibility
of the database layer. Application developers only need to be able to deal with what to
do if an entire transaction fails and how to notify the right party or how to keep retry-
ing until the transaction is complete. Application developers don't need to know how
to undo various parts of a transaction, as that's built into the database.
Given that reliable transactions are important in most application systems, the
next two sections will take an in-depth look at RDBMS transaction control using ACID ,
and NoSQL transaction control using BASE .

2.5.1 RDBMS transaction control using ACID

RDBMS s maintain transaction control by using atomic, consistent, independent, and
durable ( ACID ) properties to insure transactions are reliable. The following defines
each of the associated properties:
 Atomicity —In the banking transaction example, we said that the exchange of
funds from savings to checking must happen as an all-or-nothing transaction.
The technical term for this is atomicity , which comes from the Greek term for
“dividable.” Systems that claim they have atomic transactions must consider all
failure modes: disk crashes, network failures, hardware failures, or simple soft-
ware errors. Testing atomic transactions even on a single CPU is difficult.
 Consistency —In the banking transaction example, we talked about the fact that
when moving funds between two related accounts, the total account balance