Database Tuning: Principles, Experiments, and Troubleshooting Techniques
Learn to improve transferable skills that will facilitate in tuning many database systems on numerous hardware and operating systems.
TABLE OF CONTENTS Database Tuning: Principles, Experiments, and Troubleshooting Techniques
2.2: Locking and Concurrency Control
2.2 Locking and Concurrency Control
Database applications divide their work into transactions. When a transaction executes, it accesses the database and performs some local computation. The strongest assumption that an application programmer can make is that each transaction will appear to execute in isolation without concurrent activity. Because this notion of isolation suggests indivisibility, transactional guarantees are sometimes called atomicity guarantees. [1] Database researchers, you see, didn't bother to let 20th-century physics interfere with their jargon.
The sequence of transactions within an application program, taken as a whole, enjoys no such guarantee, however. Between, say, the first two transactions executed by an application program, other application programs may have executed transactions that modified data items accessed by one or both of these first two transactions. For this reason, the length of a transaction can have important correctness implications.
Suppose that an application program processes a purchase by adding the value of the item to inventory and subtracting the money paid from cash. The application specification requires that cash never be made negative, so the transaction will roll back (undo its effects) if subtracting the money from cash will cause the cash balance to become negative.
To reduce the time locks are held, the application designers divide these two steps into two transactions.
-
The first transaction checks to see whether there is enough cash to pay for the item. If so, the first transaction adds the value of the item to inventory. Otherwise,...
Copyright Elsevier Science (USA) 2003 under license agreement with Books24x7
