 |
» |
|
|
|
|
|
5.11 How does ALLBASE/SQL use locking?
Key points
- ALLBASE/SQL uses locks to regulate concurrent access to the same data.
- Locking is needed to ensure data integrity in a multi-user environment.
Without appropriate locking, you might incorrectly overwrite changes made by
other users, or read uncommitted data.
- Locking can degrade performance in two ways:
- Locking reduces concurrency.
- Deadlocks sometimes occur.
- A well tuned application has a high rate of concurrency and a low rate of
deadlock. In reality, however, a tradeoff is usually necessary. A low rate
of deadlock is often achieved by locking more of the data than you actually
need (for example, locking the entire table instead of most of the pages in
the table). This strategy tends to increase the lock wait time for other
transactions. Conversely, a short wait time for locks is usually achieved by
locking small portions of the data. This strategy can increase the number of
deadlocks.
- ALLBASE/SQL supports a variety of lock granularities, lock types, table types,
and isolation levels to enable a transaction to lock only what is necessary
to keep other transactions from interfering with its work (these concepts will
be explained in this module). ALLBASE/SQL application developers can use
these features to develop programs that maximize concurrency and minimize
deadlocks.
- Remember that locks are released when a transaction terminates. It is
important that all transactions are terminated properly. All of the following
SQL statements can be used to terminate transactions:
COMMIT WORK,
ROLLBACK WORK, RELEASE, STOP DBE, and TERMINATE USER.
Page last updated on November 29, 1995
|
|
|
Printable version
