HP 3000 Manuals HP 3000 Manuals
Locking and Latching 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. * Latches. * Pins. 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. 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.