Databases Reference
In-Depth Information
You don't want any magic to wreak havoc while you're looking the other way. In short, you want
your transaction to be protected.
This is a challenge that transactional database vendors have, which is investigated both in this
chapter and in Chapter 7. It's something that database users (and by “users” I include database
administrators, database developers, database architects and designers — anyone who uses a data-
base in any way) take for granted. Having become so accustomed to the way that a database works,
various things are now simply expected, just as you expect a letter to appear when you press a key on
your computer keyboard, oblivious to the complex programming by software developers that makes
it possible. When writing programs using very low-level languages, developers still need to consider
those types of things, but for all the other developers, there is a lot that can be taken for granted.
Nonetheless, the concepts used to protect your data should be understood. After all, you need to
allow many processes to access your databases at once, and therefore need to appreciate the differ-
ence between having some “magic” occur that has unexpected results, and controlling the behavior
that occurs when multiple processes want to act on the same pieces of data. Nothing should give
a database user the impression of magic, and the power of concurrency — coordinating multiple
processes — should be appreciated and leveraged.
Protecting data from unexpected results is achieved through a system of locks and latches. Latches,
which protect memory, are explained further in Chapter 7. This chapter is dedicated to locks, and
how you can use them to provide a level of protection to the transactions in your system. You will
look at what they are designed to preserve, how they do it, and the various options available for
consideration. You will also look at the plusses and minuses of locking, and see how locks can be
leveraged for your benei t. The point of this scrutiny is to enable as many processes as possible
accessing the data.
Scalability continues to drive computing technology; and as your systems demand increasingly heavy
workloads, locks become increasingly important also.
TRANSACTIONS
Just to ensure that we're all on the same page, let's quickly review what we're talking about when
we discuss transactions. The most common analogy used to understand database transactions is
the bank transaction. Beginning with the deposit, suppose you take $50 to the counter, resulting
in a credit transaction in that amount to your account. When you look at your account statement
when it arrives, you expect the transaction record to rel ect that you deposited $50, not $48 or
$52, depending on any fees or charges that might apply. This expectation actually stems from four
aspects of transactions that have been identii ed by experts and that should be protected: atomicity,
consistency, isolation, and durability, which form the neat acronym ACID. The following sections
i rst examine these in the context of the bank transaction, and then you will revisit them in the
context of your database.
A Is for Atomic
Atomic means indivisible — in this case, a collection of events being treated as a single unit.
When you take your money to the bank and deposit it, you expect the transaction to be completed
Search WWH ::
Custom Search