Optimistic Versus Pessimistic Locking
Optimistic Versus Pessimistic Locking
Locks can be invoked in two basic styles. With optimistic locking, the assumption is made that no conflict will occur. Data are read, the transaction is processed, updates are issued, and then a check is made to see if conflict occurred. If not, the transaction is finished. If conflict did occur, the transaction is repeated until it processes with no conflict. With pessimistic locking, the assumption is made that conflict will occur. Locks are issued, the transaction is processed, and then the locks are freed.
Figures 9-8 and 9-9 show examples of each style for a transaction that is reducing the quantity of the pencil row in PRODUCT by five. Figure 9-8 shows optimistic locking. First, the data are read and the current value of Quantity of pencils is saved in the variable OldQuantity. The transaction is then processed, and assuming that all is OK, a lock is obtained on PRODUCT. (In fact, the lock might be only for the pencil row or it might be at a larger level of granularity, but the principle is the same.) After obtaining the lock, an SQL statement is issued to update the pencil row with a WHERE condition that the current value of Quantity equals OldQuantity. If no other transaction has changed the Quantity of the pencil row, then this
Figure 9-8
/* *** EXAMPLE CODE - DO NOT RUN *** */
Optimistic Locking
SELECT
PRODUCT.Name, PRODUCT.Quantity
PRODUCT.Name = Pencil ; Set NewQuantity = PRODUCT.Quantity – 5; {process transaction – take exception action if NewQuantity < 0, etc. Assuming all is OK: } LOCK PRODUCT; UPDATE
PRODUCT
SET
PRODUCT.Quantity = NewQuantity
WHERE
PRODUCT.Name = Pencil AND PRODUCT.Quantity = OldQuantity;
UNLOCK PRODUCT; {check to see if update was successful;
if not, repeat transaction}
Figure 9-9
/* *** EXAMPLE CODE - DO NOT RUN *** */ LOCK
PRODUCT;
Pessimistic Locking
SELECT
PRODUCT.Name, PRODUCT.Quantity
PRODUCT.Name = Pencil ; Set NewQuantity = PRODUCT.Quantity – 5; {process transaction – take exception action if NewQuantity < 0, etc. Assuming all is OK: } UPDATE
PRODUCT
SET
PRODUCT.Quantity = NewQuantity
WHERE
PRODUCT.Name = Pencil ;
UNLOCK
PRODUCT; {no need to check if update was successful}
Chapter 9 Managing Multiuser Databases
UPDATE will be successful. If another transaction has changed the Quantity of the pencil row, the UPDATE will fail. In either case, the lock is released. If the transaction failed, the process is repeated until the transaction finishes with no conflict.
Figure 9-9 shows the logic for the same transaction using pessimistic locking. Here, a lock is obtained on PRODUCT before any work is begun. Then, values are read, the transaction is processed, the UPDATE occurs, and PRODUCT is unlocked.
The advantage of optimistic locking is that locks are held for much less time than with pessimistic locking, because locks are obtained only after the transaction has finished. If the transaction is complicated or if the client is slow (due to transmission delays, the client doing other work, or the user getting a cup of coffee or shutting down without exiting the browser), optimistic locking can dramatically improve throughput. This advantage will be especially true if the lock granularity is large—say, the entire PRODUCT table.
The disadvantage of optimistic locking is that if there is a lot of activity on the pencil row, the transaction may have to be repeated many times. Thus, transactions that involve a lot of activity on a given row (purchasing a popular stock, for example) are poorly suited for optimistic locking.
In general, the Internet is a wild and woolly place, and users are likely to take unexpected actions, such as abandoning transactions in the middle. So, unless Internet users have been prequalified (by enrolling in an online brokerage stock purchase plan, for example), optimistic locking is the better choice in that environment. On intranets, however, the decision is more difficult. Optimistic locking is probably still preferred unless some characteristic of the application causes substantial activity on particular rows or if application requirements make reprocessing transactions particularly undesirable.