MBA (General) - IV Semester, Information Technology and E-Business, Unit 2.1
What Do You Need for Transaction Processing?
Data processing folks like to talk about the “ACID test” when deciding whether or not a database management system is adequate for handling transactions. An adequate system has the following properties
What Do You Need for Transaction Processing?
Data processing folks like to talk about the
“ACID test” when deciding whether or not a database management system is
adequate for handling transactions. An adequate system has the following
properties
Atomicity
Results of a transaction’s execution are either
all committed or all rolled back. All changes take effect, or none do. That
means, for Joe User’s money transfer, that both his savings and checking
balances are adjusted or neither are.
Consistency
The database is transformed from one valid
state to another valid state. This defines a transaction as legal only if it
obeys user-defined integrity constraints. Illegal transactions aren’t allowed
and, if an integrity constraint can’t be satisfied then the transaction is
rolled back. For example, suppose that you define a rule that, after a transfer
of more than $10,000 out of the country, a row is added to an audit table so
that you can prepare a legally required report for the IRS. Perhaps for
performance reasons that audit table is stored on a separate disk from the rest
of the database. If the audit table’s disk is off-line and can’t be written,
the transaction is aborted.
Isolation
The results of a transaction are invisible to
other transactions until the transaction is complete. For example, if you are
running an accounting report at the same time that Joe is transferring money,
the accounting report program will either see the balances before Joe
transferred the money or after, but never the intermediate state where checking
has been credited but savings not yet debited.
Durability
Once committed (completed), the results of a
transaction are permanent and survive future system and media failures. If the
airline reservation system computer gives you seat 22A and crashes a
millisecond later, it won’t have forgotten that you are sitting in 22A and also
give it to someone else. Furthermore, if a programmer spills coffee into a disk
drive, it will be possible to install a new disk and recover the transactions
up to the coffee spill, showing that you had seat 22A.
That doesn’t sound too tough to implement, does
it? A “mere matter of programming” as our friend Jin likes to say. Well, you
still need indexing.
