 |
Claims  |
|
|
We claim:
1. In a data processing system having a plurality of database management
systems (DBMSs) each having a local cache buffer (LCB) for storing data
pages each having a plurality of records for processing by transactions,
said DBMSs being coupled to a Shared Electronic Store (SES) and a shared
external store for stable storage of one or more databases, each said DBMS
also having first means for storing a local validation vector (LVV)
containing validity information for each said data page in said LCB and
having second means for storing a buffer control block (BCB) for each said
data page in said LCB, each BCB including an Input-Output-in-Progress
(IOP) flag indicating when set that Input/Output (I/O) activity exists for
the corresponding said data page, wherein said DBMS has Read-And-Register
(RAR) means for refreshing an invalid first data page in said LCB, said
RAR means operating to first reset the corresponding said LVV information
to show validity of said first data page and secondly copying a valid
version of said first data page from said SES to said LCB, a method to
ensure data coherency by serializing the testing of said LVV for validity
of a first said data page in said LCB and the reading by a transaction of
said first data page from said LCB, said method comprising the steps of:
(a) latching said first data page with a share (S) mode latch;
(b) testing said LVV to determine the validity of said first data page; and
(c) responsive to finding said first data page to be invalid, performing
the ordered steps of:
(c.1) latching said first data page with an exclusive (X) mode latch,
(c.2) setting said IOP flag in said BCB for said first data page,
(c.3) unlatching said first data page,
(c.4) replacing said first data page in said LCB with a valid copy through
said RAR means, and
(c.5) resetting said IOP flag in said BCB for said first data page.
2. The method of claim 1 wherein said latching step (c.1) comprises the
steps of:
(c.1.1) requesting a conditional exclusive (X) latch for said first data
page;
(c.1.2) responsive to rejection of said conditional X-latch because of a
pre-existing latch on said first data page, performing the steps of:
(c.1.2.1) removing from said first data page said S-latch obtained in said
latching step (a),
(c.1.2.2) requesting an unconditional exclusive (X) latch for said first
data page, and
(c. 1.2.3) responsive to receiving said unconditional X-latch, repeating
said testing step (b) and said performing step (c).
3. In a data processing system having a plurality of database management
systems (DBMSs) each having a local cache buffer (LCB) for storing data
pages each having a plurality of records for processing by transactions,
said DBMS being coupled to a global locking manager (GLM) for locking said
data pages and said records, and being coupled to a Shared Electronic
Store (SES) and to a shared external store for stable storage of one or
more databases, each said DBMS also having first means for storing a Local
Validity Vector (LVV) containing validity information for each said data
page in said LCB and having second means for storing a Buffer Control
Block (BCB) for each said data page in LCB, each said BCB including an
Input-Output-in-Progress (IOP) flag indicating when set that Input/Output
(I/O) activity exists for the corresponding said data page and a Dirty
Page (DP) flag indicating when set that the corresponding said data page
includes record modifications not yet written to stable storage, a method
for maintaining database coherency during the reading by a transaction of
at least one record in a first data page in one said LCB, said method
comprising the steps of:
(a) locking said at least one record in said first data page in share (S)
mode;
(b) latching said first data page with a share (S) mode latch;
(c) if said IOP flag for said first page is set, performing the steps of:
(c.1) if said DP flag for said first data page is set, skipping to and
performing reading step (e), otherwise
(c.2) performing the steps of:
(c.2.1) unlatching said first data page, and
(c.2.2) responsive to reset of said IOP flag for said first data page,
repeating said latching step (b) and said performing step (c);
otherwise
(d) performing the steps of:
(d.1) testing said LVV to determine validity of said first data page, and
(d.2) if said LVV shows said first data page to be valid, skipping to and
performing reading step (e), otherwise performing the steps of:
(d.2.1) latching said first data page with an exclusive (X) mode latch,
(d.2.2) setting said IOP flag in said BCB for said first data page,
(d.2.3) unlatching said first data page,
(d.2.4) replacing said first data page in said LCB with a valid copy of
said first data page from said SES,
(d.2.5) resetting said IOP flag in said BCB for said first data page, and
(d.2.6) repeating said steps (b) through (d); and
(e) reading said at least one record from said first data page in said LCB.
4. The method of claim 3 wherein said latching step (d.2.1) comprises the
steps of:
(d.2.1.1) requesting a conditional exclusive (X) latch for said first data
page;
(d.2.1.2) responsive to a preexisting latch by another process on said
first data page, performing the steps of:
(d.2.1.2.1) removing from said first data page said S-latch obtained in
said latching step (b),
(d.2.1.2.2) requesting an unconditional exclusive (X) latch for said first
data page, and
(d.2.1.2.3) responsive to receiving said unconditional X-latch, repeating
said performing step (d).
5. The method of claim 4 wherein said reading step (e) comprises the step
of:
(e.1) if said first data page is latched in exclusive (X) mode, downgrading
said first data page latch to share (S) mode.
6. The method of claim 3 wherein said locking step (a) is performed for all
of said first data page.
7. The method of claim 6 wherein said latching step (d.2.1) comprises the
steps of:
(d.2.1.1) requesting a conditional exclusive (X) latch for said first data
page;
(d.2.1.2) responsive to a preexisting latch by another process on said
first data page, performing the steps of:
(d.2.1.2.1) removing from said first data page said S-latch obtained in
said latching step (b),
(d.2.1.2.2) requesting an unconditional exclusive (X) latch for said first
data page, and
(d.2.1.2.3) responsive to receiving said unconditional X-latch, repeating
said performing step (d).
8. The method of claim 7 wherein said reading step (e) comprises the step
of:
(e.1) if said first data page is latched in exclusive (X) mode, downgrading
said first data page latch to share (S) mode.
9. In a data processing system having a plurality of database management
systems (DBMSs) each having a local cache buffer (LCB) for storing data
pages each having a plurality of records for processing by transactions,
said DBMSs being coupled to a Shared Electronic Store (SES) and a shared
external store for stable storage of one or more databases, each said DBMS
also having first means for storing a local validation vector (LVV)
containing validity information for each said data page in said LCB and
having second means for storing a buffer control block (BCB) for each said
data page in said LCB, each BCB including an Input-Output-in-Progress
(IOP) flag indicating when set that Input/Output (I/O) activity exists for
the corresponding said data page, wherein said DBMS has Read-And-Register
(RAR) means for refreshing an invalid first data page in said LCB, said
RAR means operating to first reset the corresponding said LVV information
to show validity of said first data page and secondly copying a valid
version of said first data page from said SES to said LCB, a method to
ensure data coherency by serializing the testing of said LVV for validity
of a first said data page in said LCB and the updating by a transaction of
said first data page in said LCB, said method comprising the steps of:
(a) latching said first data page with an exclusive (X) mode latch;
(b) testing said LVV to determine the validity of said first data page; and
(c) responsive to finding said first data page to be invalid, performing
the ordered steps of:
(c.1) setting said IOP flag in said BCB for said first data page,
(c.2) unlatching said first data page,
(c.3) replacing said first data page in said LCB with a valid copy through
said RAR means, and
(c.4) resetting said IOP flag in said BCB for said first data page.
10. In a data processing system having a plurality of database management
systems (DBMSs) each having a local cache buffer (LCB) for storing data
pages each having a plurality of records for processing by transactions,
said DBMS being coupled to a global locking manager (GLM) for locking said
data pages and said records, and being coupled to a Shared Electronic
Store (SES) and to a shared external store for stable storage of one or
more databases, each said DBMS also having first means for storing a Local
Validity Vector (LVV) containing validity information for each said data
page in said LCB and having second means for storing a Buffer Control
Block (BCB) for each said data page in LCB, each said BCB including an
Input-Output-in-Progress (IOP) flag indicating when set that Input/Output
(I/O) activity exists for the corresponding said data page and a Dirty
Page (DP) flag indicating when set that the corresponding said data page
includes record modifications not yet written to stable storage, a method
for maintaining database coherency during the updating by a transaction of
at least one record in a first data page in said LCB of one said DBMS,
said method comprising the steps of:
(a) locking said at least one record in said first data page in exclusive
(X) mode;
(b) latching said first data page with an exclusive (X) mode latch;
(c) if said IOP flag for said first data page is set, performing the steps
of:
(c.1) unlatching said first data page, and
(c.2) responsive to reset of said IOP flag for said first data page,
repeating said latching step (b) and said performing step (c); otherwise
(d) performing the steps of:
(d.1) testing said LVV to determine validity of said first data page, and
(d.2) if said LVV shows said first data page to be invalid, performing the
steps of:
(d.2.1) latching said first data page with an exclusive (X) mode latch,
(d.2.2) setting said IOP flag in said BCB for said first data page,
(d.2.3) unlatching said first data page,
(d.2.4) replacing said first data page in said LCB with a valid copy of
said first data page from said SES,
(d.2.5) resetting said IOP flag in said BCB for said first data page, and
(d.2.6) repeating said steps (b) through (d); otherwise
(e) setting said DP flag for said first data page if not already set; and
(f) writing an update to said at least one record in said first data page
in said LCB.
11. The method of claim 10 wherein said locking step (a) is performed for
all of said first data page.
12. A computer program product, for use with a data processing system
having a plurality of database management systems (DBMSs) each having a
local cache buffer (LCB) for storing data pages each having a plurality of
records for processing by transactions, said DBMSs being coupled to a
Shared Electronic Store (SES) and a shared external store for stable
storage of one or more databases, each said DBMS also having first means
for storing a local validation vector (LVV) containing validity
information for each said data page in said LCB and having second means
for storing a buffer control block (BCB) for each said data page in said
LCB, each BCB including an Input-Output-in-Progress (IOP) flag indicating
when set that Input/Output (I/O) activity exists for the corresponding
said data page, wherein each said DBMS has Read-And-Register (RAR) means
for refreshing an invalid first data page in said LCB, said RAR means
operating to first reset the corresponding said LVV information to show
validity of said first data page and secondly copying a valid version of
said first data page from said SES to said LCB, said computer program
product comprising:
a recording medium;
means, recorded on said recording medium, for directing said data
processing system to latch said first data page with a share (S) mode
latch;
means, recorded on said recording medium, for directing said data
processing system to test said LVV to determine the validity of said first
data page; and
means, recorded on said recording medium, for:
said data processing system to perform, responsive to finding
latching said first data page with an exclusive (X) mode latch,
setting said IOP flag in said BCB for said first data page,
unlatching said first data page,
replacing said first data page in said LCB with a valid copy through said
RAR means, and
resetting said IOP flag in said BCB for said first data page.
13. A computer program product for use with a data processing system having
a plurality of database management systems (DBMSs) each having a local
cache buffer (LCB) for storing data pages each having a plurality of
records for processing by transactions, said DBMS being coupled to a
global locking manager (GLM) for locking said data pages and said records,
and being coupled to a Shared Electronic Store (SES) and to a shared
external store for stable storage of one or more databases, each said DBMS
also having first means for storing a Local Validity Vector (LVV)
containing validity information for each said data page in said LCB and
having second means for storing a Buffer Control Block (BCB) for each said
data page in LCB, each said BCB including an Input-Output-in-Progress
(IOP) flag indicating when set that Input/Output (I/O) activity exists for
the corresponding said data page and a Dirty Page (DP) flag indicating
when set that the corresponding said data page includes record
modifications not yet written to stable storage, said data program product
comprising:
a recording medium;
means, recorded on said recording medium, for directing said data
processing system to lock said at least one record in said first data page
in share (S) mode;
means, recorded on said recording medium, for directing said data
processing system to latch said first data page with a share (S) mode
latch;
means, recorded on said recording medium, for unlatching said first data
page, and responsive to reset of said IOP flag for said first data page,
latching said first page with a share (S) mode latch, if said IOP flag for
said first data page is set and said DP flag for said first data page is
set;
means, recorded on said recording medium, for, testing said LVV to
determine validity of said first data page and for latching said first
data page with an exclusive (X) mode latch, setting said IOP flag in said
BCB for said first data page, unlatching said first data page, replacing
said first data page in said LCB with a valid copy of said first data page
from said SES, and resetting said IOP flag in said BCB for said first data
page, if said LVV shows said first data page to invalid; and
means, recorded on said recording medium, for directing said data
processing system to read said at least one record from said first data
page in said LCB.
14. A computer program product, for use with a data processing system
having a plurality of database management systems (DBMSs) each having a
local cache buffer (LCB) for storing data pages each having a plurality of
records for processing by transactions, said DBMSs being coupled to a
Shared Electronic Store (SES) and a shared external store for stable
storage of one or more databases, each said DBMS also having first means
for storing a local validation vector (LVV) containing validity
information for each said data page in said LCB and having second means
for storing a buffer control block (BCB) for each said data page in said
LCB, each BCB including an Input-Output-in-Progress (IOP) flag indicating
when set that Input/Output (I/O) activity exists for the corresponding
said data page, wherein said DBMS has Read-And-Register (RAR) means for
refreshing an invalid first data page in said LCB, said RAR means
operating to first reset the corresponding said LVV information to show
validity of said first data page and secondly copying a valid version of
said first data page from said SES to said LCB, said computer program
product comprising:
a recording medium;
means, recorded on said recording medium, for directing said data
processing system to latch said first data page with an exclusive (X) mode
latch;
means, recorded on said recording medium, for directing said data
processing system to test said LVV to determine the validity of said first
data page; and
means, recorded on said recording medium, responsive to finding said first
data page to be invalid, for:
setting said IOP flag in said BCB for said first data page,
unlatching said first data page,
replacing said first data page in said LCB with a valid copy through said
RAR means, and
resetting said IOP flag in said BCB for said first data page,
15. A computer program product, for use with a data processing system
having a plurality of database management systems (DBMSs) each having a
local cache buffer (LCB) for storing data pages each having a plurality of
records for processing by transactions, said DBMS being coupled to a
global locking manager (GLM) for locking said data pages and said records,
and being coupled to a Shared Electronic Store (SES) and to a shared
external store for stable storage of one or more databases, each said DBMS
also having first means for storing a Local Validity Vector (LVV)
containing validity information for each said data page in said LCB and
having second means for storing a Buffer Control Block (BCB) for each said
data page in LCB, each said BCB including an Input-Output-in-Progress
(IOP) flag indicating when set that Input/Output (I/O) activity exists for
the corresponding said data page and a Dirty Page (DP) flag indicating
when set that the corresponding said data page includes record
modifications not yet written to stable storage, said computer program
product comprising:
means, recorded on said recording medium, for directing said data
processing system to lock said at least one record in said first data page
in exclusive (X) mode;
means, recorded on said recording medium, for directing said data
processing system to latch said first data page with an exclusive (X) mode
latch;
means, recorded on said recording medium, for directing said data
processing system to unlatch said first data page if said IOP flag for
said first data page is set;
means, recorded on said recording medium, for directing said data
processing system to:
(a) test said LVV to determine validity of said first data page, and
(b) latch said first data page with an exclusive (X) mode latch, set said
IOP flag in said BCB for said first data page, unlatch said first data
page, replace said first data page in said LCB with a valid copy of said
first data page from said SES, and reset said IOP flag in said BCB for
said first data page, if said LVV shows said first data page to be
invalid;
means, recorded on said recording medium, for directing said data
processing system to set said DP flag for said first data page if not
already set; and
means, recorded on said recording medium, for directing said data
processing system to write an update to said at least one record in said
first data page in said LCB. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
CROSS-REFERENCE TO RELATED APPLICATION
This application is related by common inventorship and subject matter to
copending U.S. patent application Ser. No. 08/236,284 entitled "EFFICIENT
DESTAGING OF UPDATED LOCAL CACHE PAGES FOR A TRANSACTION IN A MULTISYSTEM
AND MULTIPROCESS DATABASE MANAGEMENT SYSTEM WITH A HIGH-SPEED SHARED
ELECTRONIC STORE" filed on even date herewith, assigned to the Assignee
hereof and entirely incorporated herein by this reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to system complexes embracing multiple
concurrent multi-user database processing systems coupled to a shared
external database store and particularly to a method for refreshing a
stale Local Cache Buffer (LCB) data page that serializes stale page
detection with re-reading of the fresh page from shared external
nonvolatile store (NVS) to maintain multisystem cache coherency under both
record and page locking granularities.
2. Description of the Related Art
Modern data processing system architecture provides for multiple Data Base
Management System (DBMS) instances, each servicing many concurrent users,
for processing a plurality of databases in a system complex (sysplex) that
includes a plurality of Central Processing Complexes (CPCs) each having
Local Cache Buffers (LCBs) commonly connected to a Shared Electronic Store
(SES) that includes nonvolatile storage (NVS) means for storing data
shared by the CPCs. The SES serves to "cache" data pages from a shared
external store that includes stable Direct Access Storage Devices (DASDs)
and the like. Because DASD data transfers are slowed by mechanical
actuator latency, the SES caching function can significantly improve
external store performance while offering complete data stability by
virtue of its nonvolatile character. Such a multisystem environment is
described in copending U.S. patent application Ser. No. 08/860,805 filed
on Mar. 30, 1992 by D. Elko et al. as "SYSPLEX SHARED DATA COHERENCY
METHOD AND MEANS", (Assignee Docket PO9-91-052), assigned to the Assignee
hereof and entirely incorporated herein by this reference.
In the database sysplex described by Elko et al., wherein a plurality of
independently-operating CPCs share data, global locking imposed by a
global locking manager (GLM) is required to maintain data coherency within
the different CPCs. The data coherency problem arises because sharing data
among a proliferation of processors may create multiple inconsistent data
page copies because of multiple paths to the data and because of
opportunities to locally modify the data. The above-cited Elko et al.
patent application describes a sysplex architecture in which each CPC
operates with a storage hierarchy that may include a private high-speed
hardware cache in each Central Processing Unit (CPU) of a CPC, a shared
hardware cache accessible to all of the private CPU caches within a single
CPC, a main store (MS) shared by all CPUs in a single CPC, a hardware
storage area (HSA) within each CPC that is associated with the local MS
but excluded from MS address space, an expanded store (ES) in each CPC
coupled to the local MS and a DASD director coupled to the local MS for
controlling DASD resources collocated with a single CPC.
A multiprocessor sysplex includes a plurality of such CPCs, where the
various DASD directors operate to control data flow between all CPCs and
all DASD resources so that any CPC can access any record on any DASD,
including records written by other CPCs in the sysplex. Each CPC has one
or more operating systems, where local CPC resources are logically
partitioned among the operating system plurality. Within each CPC, the
MS/ES storage combination is considered to be a single random access store
internal to the CPC, where data pages in MS are backed by stable pages in
ES and DASD in the usual manner. Some or all of the CPCs in a sysplex are
connected to a Shared Electronic Store (SES), each by a channel connected
to the corresponding local MS. In a hardware sense, a SES may be
considered to be a large random access memory (RAM) that may be used (but
need not be) in common by some or all CPCs connected to the SES. Connected
CPCs may use the SES to store shared data records and pages on a temporary
or semi-permanent basis. Thus, SES may be considered as a component of the
storage hierarchy in the sysplex, having a hierarchy level common to all
connected CPCs that roughly corresponds to the local ES level within each
CPC.
A fundamental feature of this sysplex architecture is the use of SES as a
high-speed cache for data normally stored in the sysplex common DASD
resource even though the CPC-SES-DASD physical connection may not be
organized as a direct hierarchy. Any CPC in the sysplex can access a
record much faster from SES than it can from common DASD storage because
the SES hardware speed is much faster than DASD access speed. Because SES
includes nonvolatile storage (NVS) and a cache cross-invalidation
capability, a DBMS instance can perform fast writes of modified ("dirty")
LCB data pages to the SES and thereby satisfy the
"force-to-stable-storage" requirement necessary for releasing global
transaction locks. The modified data pages in SES may then be
asynchronously destaged to DASD without holding up the release of global
transaction locks, thereby increasing processing efficiency without
compromising the normal database recovery features that rely on "stable
storage" of updated data pages.
Practitioners have proposed other strategies for reducing global locking
overhead in a multiprocess sysplex. For instance, in U.S. patent
application No. 07/869,267 now U.S. Pat. No. 5,408,653 filed on Apr. 15,
1992 as "EFFICIENT DATABASE ACCESS USING A SHARED ELECTRONIC STORE IN A
MULTISYSTEM ENVIRONMENT WITH SHARED DISKS", commonly assigned to the
Assignee hereof and entirely incorporated herein by this reference, Josten
et al. describe a protocol whereby, subject to a requirement for no
intersystem read-write interest in the subject database, a single DBMS
instance employs a "no-force-at-commit" protocol permitting it to write
database updates to external storage asynchronously (e.g., in "batch"
mode) after releasing global locks during transaction-commit processing.
This flexibility improves overall transaction response time and reduces
the global lock hold time, improving concurrency. However, the requirement
for intersystem cache "coherency" requires a local buffer manager (BM)
within a CPC to enforce a "force-at-commit" protocol whenever it detects
intersystem read-write interest in the database being processed. The
force-at-commit policy requires the DBMS instance to force (write) all
modified (dirty) LCB data pages to stable external storage before
releasing the committing transaction locks on those data pages. Moreover,
before the global locks are released, all other "interested" systems must
be notified of the forced data page updates through a cross-invalidation
protocol controlled by the SES element of the sysplex. The Write-Ahead
Logging (WAL) protocol is employed within each DBMS to ensure full
database recovery from any conceivable combination of hardware failures.
The above-cited Elko et al. patent application describes a detailed system
for ensuring data coherency in the Buffer Pool (BP) made up of the
combination of all local cache buffers (LCBs) for a plurality of DBMS
instances in all CPCs. Their method relies on data page storage and/or
registration within SES of all LCB data page copies, among other important
elements. To prevent multiple-version contamination (loss of coherency),
any DBMS instance in a CPC wanting to access (read or write) a record in
the sysplex common DASD pool must first register the data page containing
such record in a SES directory and preferably read the data page from the
SES cache if it exists there. Because each DBMS instance operates to
maintain local cache coherency independently within the sysplex, the SES
imposes global coherency controls that operate additionally to such
internal coherency controls. SES causes each DBMS instance in a CPC to
maintain Local Validity Vectors (LVVs) within the HSA of each CPC, each
LVV corresponding to a LCB Of a DBMS. Each CPC sets a vector bit from a
valid ("fresh") state to an invalid ("stale") state responsive to a SES
message showing a change in the latest global version of the corresponding
data page registered with SES, as part of the cross-invalidation
procedure.
For instance, a DBMS instance in a CPC making the change to a record in a
data page writes the changed page to SES. SES then consults a table to
determine which other DBMS instances in other CPCs are holding a copy of
the same data page in their LCBs and sends a message to each holding CPC
to reset the corresponding bit in the LVV held in the HSA of the holding
CPC. Importantly, because the HSA exists outside of the MS address space
within the CPC, special hardware instructions are required to set, reset
and test the LVV. If SES causes the CPC to set any vector bit to the
invalid state in the CPC's HSA, the CPC program in execution is not
disturbed or alerted in any way by such setting when it happens. CPC
programming continues without interruption or notice. However, this means
that each CPC program is independently responsible for testing the LVV bit
state when necessary to determine if any data page invalidation has
occurred. More importantly, the CPC program is also responsible for
"serializing" such validity testing with other page operations, such as
the refreshing of an invalid data page in LCB, to ensure that the
subsequent operation actually reflects the supposed page "freshness"
determined by the LVV bit test.
Each CPC controls the state of each LVV bit, corresponding to a data page
in LCB, and normally sets this bit to "invalid" responsive to a message
from SES signaling that an update to the same data page by some other CPC
has made the LCB copy stale. Before permitting a transaction to read or
write to a LCB data page, the CPC application programming tests the LVV
validity bit and, responsive to finding an invalid setting, "refreshes"
the LCB data page copy by sending a message to SES asking for the latest
copy, which also results in registering with SES that the "fresh" LCB copy
is cached in a DBMS instance in a CPC. It can be readily appreciated that
the related message flow between each CPC and the SES must be serialized
to avoid loss of data consistency of a cached data page in different
instances of a DBMS.
For instance, because it is possible for a SES-supported CPC to receive and
execute a cross-invalidate command against a designated LCB page after
interest in the page has been registered at the SES but before the
response to the read command under which the registration took place is
received, the update to the LVV by the CPC application programming must be
serialized with execution of the SES command. The application programming
must ensure that the LVV is not set to "valid" (without a new refresh)
after it is set to "invalid" by an intervening cross-invalidate command.
Otherwise, invalidation of a LCB data page may be undetected and result in
the loss of data integrity.
A problem arises because the LVV bit is reset to "valid" before the related
"refresh" (read-and-register) request is sent by CPC to SES, a procedural
requirement imposed to ensure that the local LVV bit entries never cause a
data integrity problem within the CPC arising from "missed"
cross-invalidate commands. The alternative method of resetting the LVV bit
to "valid" after reading the page from SES is unacceptable as it will
destroy the effect of an intervening cross-invalidate command from SES. By
first setting the bit to "valid", the CPC ensures that an intervening
cross-invalidate command from SES received during the refresh cycle is
read and understood.
While this restriction ensures data coherency across the multisystem, it
introduces a separate problem for concurrent transactions within a single
DBMS instance in the CPC. That is, after the LVV bit is set to "valid" but
before the completion of the data page refresh request is sent to SES, a
second concurrent (local) transaction may ask for access to the same data
page in LCB. When this second transaction queries the LVV bit, it
erroneously finds the stale LCB data page copy to be "valid". When the
first local transaction holds an exclusive page lock, this situation is
not a problem. However, for record locking granularity or shared page
locking, the second local transaction is not blocked from access to the
same data page.
These cache coherence control problems do not exist in single multi-user
systems. They arise as a result of the improved multisystem shared disk
environment. The serialization and local coherence control procedures
known in the art for preventing multiple-version data page contamination
disadvantageously impose efficiency burdens that tend to negate much of
the efficiency advantage offered by the sysplex multisystem shared
external store architecture. The related unresolved problems and
deficiencies are clearly felt in the art and are solved by this invention
in the manner described below.
SUMMARY OF THE INVENTION
This invention introduces local buffer page latches with page locking in a
multisystem shared disk environment to serialize Local Validity Vector
(LVV) verification and SES read and register (RAR) refresh processing.
Page latching is introduced for both page and record locking granularities
to force serialization of local Test Vector Entry (TVE) processing (to
read the LVV bit corresponding to the Local Cache Buffer (LCB data page)
and global SES Read-And-Register (RAR) processing (to refresh the LCB data
page). For page locking granularity, the page latches introduced by the
procedure of this invention may also be used to support unlocked read
processing in the local DBMS.
It is an object of the method of this invention to guarantee database
coherency across multiple processing systems coupled by a shared external
store through a single dual-granularity procedure for serializing local
page validity testing and global page refreshing and registration.
It is an advantage of the procedure of this invention that introducing page
latching for both page and record locking granularities provides a single
procedure to support either locking protocol for the database. It is
another advantage of the procedure of this invention that, for LCB data
page updates, page latching eliminates the test of a "write-intent-count"
field in the Buffer Control Block (BCB) for the LCB data page.
The foregoing, together with other objects, features and advantages of this
invention, will become more apparent when referring to the following
specification, claims and the accompanying drawing.
BRIEF DESCRIPTION OF THE DRAWING
For a more complete understanding of this invention, reference is now made
to the following detailed description of the embodiments as illustrated in
the accompanying drawing, wherein:
FIGS. 1A-1C show functional block diagrams illustrating the multisystem
environment for which the procedure of this invention is applicable, where
FIG. 1C represents a single computer processor complex (CPC);
FIG. 2 is a flow chart illustrating the procedure for a cached page read
operation in a single CPC system;
FIG. 3 is a flow chart illustrating the cached page read procedure of this
invention for a multisystem environment;
FIG. 4 is a flow chart illustrating a cached page update procedure for a
single CPC system;
FIG. 5 is a flow chart illustrating an asynchronous destaging procedure for
a single CPC system;
FIG. 6 is a flow chart illustrating a cached page update procedure using
record locking granularity for a single CPC system;
FIG. 7 is a flow chart illustrating an asynchronous destaging procedure for
a single CPC system with record-level locking granularity;
FIG. 8 is a flow chart illustrating the cached page update procedure of
this invention for either page or record locking granularities in a
multisystem environment; and
FIG. 9 is a flow chart illustrating an asynchronous destaging procedure for
a multisystem environment.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The Multisystem Sysplex Environment
FIG. 1A provides a functional block diagram exemplifying the multisystem
environment within which this invention operates. In FIG. 1A, two
processors 10 and 12 are shown. Each may include, for example, an IBM
System/390 central processor unit (CPU) having an IBM MVS operating
system. Each CPU executes a database management system (DBMS) | | |
