Browse Prior Art Database

Succinct Technique to Support Concurrency Control for Database Data Cached in the Buffer Pool

IP.com Disclosure Number: IPCOM000106428D
Original Publication Date: 1993-Nov-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 4 page(s) / 151K

Publishing Venue

IBM

Related People

Mohan, C: AUTHOR [+3]

Abstract

A Database Management System (DBMS) such as DB2 uses buffering technique to cache frequently accessed data to minimize disk I/Os. For DBMS to support sub-page level locking granularity, i.e., row level locking or GO processing, i.e., allow data being read without locking, it is necessary to implement a buffer level serialization mechanism to ensure physical consistency of data when it is being referenced/updated.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 43% of the total text.

Succinct Technique to Support Concurrency Control for Database Data Cached in the Buffer Pool

      A Database Management System (DBMS) such as DB2 uses buffering
technique to cache frequently accessed data to minimize disk I/Os.
For DBMS to support sub-page level locking granularity, i.e., row
level locking or GO processing, i.e., allow data being read without
locking, it is necessary to implement a buffer level serialization
mechanism to ensure physical consistency of data when it is being
referenced/updated.

      This invention provides an efficient page latching technique at
buffer level to serialize concurrent read/write access against data
cached in the buffer pool.

      A page latch is an inexpensive (compared to locks)
serialization mechanism used to ensure physical consistency of pages.
Page latches have the notions of "mode","type", and "duration"
associated with them.  A page latch may be acquired in an X
(exclusive) or S (share) mode, with a conditional or unconditional
type, and for manual duration.  Once a page latch is held in an S
mode, it is guaranteed that no modifications to the page are
occurring (i.e., page is in physical consistent state).  Similar to
locking, an S page latch can concurrently be held by multiple
readers.  The X page latch can only be held by one updater.  Page
latch waiters are granted the requested latch in a First-In-First-Out
(FIFO) sequence.

      Before a data page can be updated, DBMS must first acquire the
page latch in an X mode on behalf of the updating transaction to
ensure that it has an exclusive control of the page while an updated
is being performed.  The X page latch will be released as soon as the
update is completed.  In general, a page latch should only be held in
short duration.  Similarly, a read transaction must first acquire a
page latch in S mode before the page can be referenced.

      Since page latching function is implemented in a buffer level,
it is a performance sensitive (e.g. code path length and storage
overhead) to come up a design for DBMS to support this function.  To
minimize storage overhead, this invention provides a technique which
uses only 8-byte storage area from each Buffer Control Block (BCB) to
implement the efficient page latching queuing mechanism.

      Following the same semantic as transaction locks, page latch
waiters are granted in a FIFO order.  The latch granting process is
suspended when the first incompatible latch waiter is encountered
(i.e. the requested page latch will not be granted to other
compatible waiters if they are behind the incompatible waiter).  With
the 8-byte PLCA, it is unable for DBMS to maintain the latch waiter
queue in a FIFO order.  Instead, the latch waiter will be enqueued to
the PCLA waiter's queue in a (Last-In-First-Out) LIFO order via a
Compare-
 -Double-Swap (CDS) CPU instruction.  A page latch requestor is
placed on the latch waiter's queue under one of the following
conditi...