Beginning SQL

Chapter 11
In order to find and fix such situations, most DBMSs periodically scan for deadlocks by checking all the
locks held by the active transactions. If it detects a deadlock, the DBMS simply picks one transaction at
random and rolls it back, thereby releasing the locks it applied. That transaction is considered the “loser”
of the deadlock since the work already applied for that transaction is undone and must be rerun. The
other user can now gain control of the data they need to finish their transaction and release their locks.
The losing transaction receives an error message informing it of the deadlock loss and the ensuing rollback.
Of course, this is a highly simplified scenario. It is not only possible but also likely that a DBMS
sees deadlocks involving several different users, necessitating multiple rollbacks so that a single transaction
can proceed and release its locks.
This method of breaking deadlocks means that any transaction could potentially be rolled back even if
all of its SQL statements are perfectly valid and would otherwise process without error. Any statement,
even a simple SELECT statement, could be a deadlock loser and be rolled back. The statement is rolled
back not because of any fault of its own, but simply because it is involved in a deadlock and loses the
coin toss for which transaction gets rolled back. This is a small price to pay given the alternatives: a
deadlock or a database corruption.
If the deadlock loser is an actual person in an interactive program, the user can simply reenter the SQL
statements. In any program using SQL, the program must be prepared to handle the error codes that the
DBMS returns informing the code of the deadlock loss and consequent rollback. Typically, just as would
happen with a live user, the program simply resubmits the transaction.
In addition to lock levels, the next section discusses how you can also set parameters to your locks.
Setting Lock Parameters
Over time, the DBMSs from various vendors have evolved capabilities not necessarily provided in the
original SQL specifications. These capabilities may or may not be present in a given platform, and even
if present, they may act differently. Locks affect many different operations, and efficient locking is an
area that every vendor takes seriously. The vendors have provided the DBMS administrator various
parameters to use in adjusting the database, which are covered here.
Lock Size
As discussed earlier, most modern databases can lock data at various levels of granularity; thus a DBMS
may offer database-, table-, page-, and row-level locking.
Number of Locks
The DBMS typically has a lock pool with a finite number of locks available to all the transactions concurrently
processing. Thus, the total number of locks is distributed to and recovered from transactions as
the transactions begin and end. The administrator may need to adjust the total number of locks to allow
for very complex transactions or very large numbers of transactions. Likewise, limiting the number of
locks can force the DBMS to escalate locking earlier, increasing the efficiency of the database.
Escalation
316
The process of requesting locks, checking the locks against requests for data by other users, and other
such overhead can be very time-consuming. In an effort to minimize the overhead, the database may
escalate a set of locks. Escalation refers to the database’s ability to consolidate many locks at one level of
granularity into a single lock at a higher granularity. For example, if a transaction applies for hundreds