Browse Prior Art Database

Fine Granularity Locking to Support High Data Availability in a Client/Server Database Management System

IP.com Disclosure Number: IPCOM000114843D
Original Publication Date: 1995-Feb-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 226K

Publishing Venue

IBM

Related People

Chen, M: AUTHOR [+2]

Abstract

As computing environments are undergoing an evolution from centralized systems towards architectures characterized by the collective power of many individual systems, it has recently become very attractive to employ a client/server computing environment for database transaction processing in order to answer the increasing demand for better capacity, availability and cost-performance. Among others, a very important issue for the success of such an environment is the concurrency and coherency control. In a client/server database management system (DBMS), a large amount of data is usually stored and managed by the server, whereas clients are allowed to access from the server, via a predetermined protocol, the data required for their running applications.

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

Fine Granularity Locking to Support High Data Availability in a Client/Server
Database Management System

      As computing environments are undergoing an evolution from
centralized systems towards architectures characterized by the
collective power of many individual systems, it has recently become
very attractive to employ a client/server computing environment for
database transaction processing in order to answer the increasing
demand for better capacity, availability and cost-performance.  Among
others, a very important issue for the success of such an environment
is the concurrency and coherency control.  In a client/server
database management system (DBMS), a large amount of data is usually
stored and managed by the server, whereas clients are allowed to
access from the server, via a predetermined protocol, the data
required for their running applications.  A certain amount of
recently accessed data is cached in clients for later use to improve
the overall performance.  For the reason of concurrency control,
locking schemes are used to prevent multiple users from updating the
same data simultaneously.  Lock contention causes a significant
amount of lock waiting time, which, in turn, seriously increases the
transaction response time, and degrades the system throughput.  Also,
provisions are needed to ensure the coherency control so that not
only can data modified by one client be timely available to others
but also every client is properly made aware of the freshness of its
local data.  The effects of concurrency and coherency control for a
client/server DBMS are entangled, and their complexity, as well as
impact on system performance, grows with the number of clients in the
system.  Consequently, the increasing number of clients that a server
aims to deal with nowadays has made it very important to develop
effective schemes to efficiently tackle the concurrency and coherency
control for a client/server DBMS.  Locking granularity, referring to
the data unit on which the DBMS can impose a lock, determines the
level of concurrency allowed, and is thus crucial to system
performance.  The system should lock only those data to be updated so
as to minimize the level of lock contention.  The finest locking
granularity adopted in today's DBMS is a record.  However, since each
lock requires some memory and operational overhead, the finer the
locking unit, the more locks the system has to handle.  Furthermore,
record level locking introduces higher complexity for the
corresponding storage management to cope with the coherency control.
Specifically, the length of a record in database applications may
vary after an update.  Thus, after receiving a record of changed
length from a client, to accommodate that record into the data page
where that record used to reside, the server may need to reshuffle
records within a page, or even move records across pages.  As a
result, due to the intrinsic difficulties with record level locking,
m...