Concurrent access to database objects, buffers, and other shared elements
in a DBEnvironment is regulated by means of three kinds of controls
within ALLBASE/SQL:
Locks regulate access to tables, pages, and rows of data when different
users contend for them.
Latches regulate system access to in-memory resources such
as buffers, ensuring that one buffer operation is complete before
another is allowed to proceed. Pins are used to keep resources in memory
instead of allowing ALLBASE/SQL to swap them out by the
LRU (least recently used) algorithm.
Detailed information about concurrency control, including locking,
appears in the chapter "Concurrency Control through Locks and Isolation
Levels" in the ALLBASE/SQL Reference Manual.
To monitor locking activity, run SQLMON and go to the Load and Lock
screens.
The following paragraphs highlight some specific
performance-related issues.
Locks |
 |
A lock is a logical object that is created in memory whenever a user
or the ALLBASE/SQL system
accesses data at the RC, CS, or RR isolation levels. Physically,
a lock is represented in the ALLBASE/SQL runtime control block
as a 92-byte lock control block. Individual transactions
issue lock requests for the specific objects that are required for
data access. ALLBASE/SQL then either grants the request or places
the transaction on a wait queue, requiring the transaction to wait
until a lock is released.
ALLBASE/SQL maintains a specific area in shared memory for deadlock
detection. As a lock request is registered, it is compared with
existing locks and with other requests in the wait queue, and if
a deadlock is discovered, the transaction with the lowest priority
(highest priority number as assigned in the BEGIN WORK statement)
is rolled back.
Each table, page, or row that is
locked receives its own lock control block. For example,
if you are using a large PUBLICROW table and locking individual rows,
the transaction may require the allocation of many separate 92-byte
control blocks. Space for control blocks is configured for the
DBEnvironment as a whole when you specify a number of runtime
control block pages. ALLBASE/SQL also uses these pages for other
types of control blocks, but lock management is the single
largest user of the runtime control block.
Latches |
|
A latch regulates access to a data structure in memory. Latches
are generally held for a very short period of time. An example
is a memory-to-memory copy of a data page. While the copy takes
place, it is important that no other transaction is allowed to
alter the content of the data structure.
The most commonly latched objects in ALLBASE/SQL are buffer pages,
though other data structures are also latched.
ALLBASE/SQL latches both data and log pages. For the log buffer,
latching is the only mechanism used to regulate concurrent access.
Log records are not locked.
Like locks, latches are also represented in shared memory as
control blocks, but these are not allocated following a user's
request; instead, they are allocated
when the DBEnvironment starts up. Latches are more efficient
than locks, because deadlocks are not automatically detected in
latching. Instead, deadlocks are avoided. Unlike locking,
latching does not require the overhead necessary for deadlock detection.
Pins |
|
A pin is similar to a latch, but its purpose is more specialized.
A pin freezes a data structure (such as a page)
in ALLBASE/SQL shared
memory so that it cannot be overwritten while it is being read or
written by a transaction. Multiple transactions can pin the same
data structure. So long as one pin is still in place, the structure
cannot be overwritten. After a read or write is complete, the data
structure is unpinned.
Sequence of Events in Locking Data |
|
Once a lock request is granted, a data page is pinned to a buffer frame
in ALLBASE/SQL
memory, then the page is latched while data is accessed
by a transaction. When the access is complete,
the latch is released, and the pin is
released. The lock may be released or held, depending on the kind of
lock and the isolation level of the transaction. In the case of updates
and repeatable reads, locks are held until the transaction ends with
a COMMIT WORK or ROLLBACK WORK statement.
