 |
Claims  |
|
|
We claim:
1. In a database system including a plurality of database management
systems (DBMS's), direct access storage connected to the DBMS's for
storage of one or more databases, and a shared store connected to the
DBMS's to temporarily store data for rapid access by the plurality of
DBMS's, wherein:
said DBMS's provide data from one or more databases to transactions for
database processing:
a method for maintaining coherency of a database with respect to said
plurality of DBMS's, the method comprising the following steps:
(1) responsive to a request by a first transaction to a first DBMS for data
from a designated database, the request being in the absence of any other
transaction requests to any other DBMS for updating the designated
database:
(1a) at the first DBMS, obtaining the data from the direct access storage
without checking for the data in the shared store;
(1b) executing the first transaction by conducting a transaction operation
at the first DBMS; and
(1c) committing the first transaction; and following the commitment of the
first transaction:
(2) responsive to a request by a second transaction to the first DBMS for
data from the designated database, the request being substantially
concurrent with a request by a third transaction to a second DBMS for
updating the designated database;
(2a) at the first DBMS, if the data requested by the second transaction is
in the shared store, obtaining the data from the shared store, otherwise
obtaining the data from the direct access storage;
(2b) executing and committing the third transaction at the second DBMS;
(2c) synchronously with the commitment of the third transaction, writing
data updated by the third transaction from the second DBMS to the shared
store.
2. The method of claim 1, wherein in step (2) the request by the second
transaction is a request for updating data in the designated database,
step (2a) including:
(2ai) first, exclusively locking a data object in the designated database
to be updated by the second transaction for the first DBMS;
(2aii) next, if the data object is in the shared store, obtaining the data
object from the shared store, otherwise obtaining the data object from the
direct access storage;
(2aiii) further, executing and committing the second transaction on the
data object at the first DBMS;
(2aiiii) synchronously with commitment of the second transaction at the
first DBMS, writing the data object to the shared store; and
(2av) then, unlocking the data object.
3. The method of claim 1, step (1b) further including:
(1bi) executing an updating operation on the data at the first DBMS; and
(1cl) asynchronously with the commitment of the first transaction, writing
the data to the direct access storage.
4. The method of claim 1, wherein step 2(c) further includes providing
notification of updating the data at the second DBMS to all other DBMS's.
5. In a database system including a plurality of database management
systems (DBMS's), direct access storage connected to the DBMS's for
storage of one or more databases, a shared store connected to the DBMS's
to temporarily store data for rapid access by the plurality of DBMS's, and
a locking mechanism for granting access to a database, a method for
maintaining coherency of a database with respect to said plurality of
DBMS's, the method comprising the following steps:
granting sole access to a first DBMS for acquiring data from a designated
database;
at the first DBMS, during said sole access, obtaining the data from the
direct access storage;
executing a transaction operation on the data at the first DBMS;
during said sole access, generating a request for access to the designated
database from a second DBMS;
responsive to the request from the second DBMS, writing updated data of the
designated database from the first DBMS to the direct access storage and
removing all non-updated data of the designated database from the first
DBMS; and
changing the sole access of the first DBMS and granting the second DBMS
access to the designated database.
6. The method of claim 5, wherein the second granting step includes
granting shared access to the second DBMS for updating the designated
database, further including:
changing the sole access of the first DBMS to shared access;
at the second DBMS, updating data of the designated database and writing
the updated data of the designated database to the shared store; and
at the first and second DBMS's, obtaining required data of the designated
database from the shared store or from the direct access storage if the
required data is not in the shared store.
7. The method of claim 6, further including:
at the second DBMS, surrendering access to the designated database;
changing the access of the first DBMS to sole access;
at the first DBMS, during said sole access, obtaining data from the direct
access storage.
8. The method of claim 5, wherein the second granting step includes
granting shared access to the database for reading pages in the designated
database, further including:
changing the access of the first DBMS to shared access;
at the first DBMS, obtaining pages of the designated database without
locking the pages;
updating the pages at the first DBMS and writing the updated pages to the
shared store; and
at the second DBMS, obtaining pages of the designated database from the
shared store or from the direct access storage if the pages are not in the
shared store.
9. The method of claim 5, wherein before the step of generating a request
from the second database:
the step of obtaining data from the direct access storage includes
obtaining pages of the designated data base without locking the pages; and
the step of executing a transaction includes updating the pages; the method
further including:
returning updated pages from the first DBMS to the direct access storage.
10. In a database system including a plurality of database management
systems (DBMS's), direct access storage connected to the DBMS's for
storage of one or more databases, a shared store connected to the DBMS's
to temporarily store data for rapid access by the plurality of DBMS's, a
log mechanism for each DBMS in which transaction records are written in a
monotonically-increasing sequence, and a locking mechanism for granting
access to a database by a locking procedure in which a lock on a
designated database is granted to a requesting DBMS, the lock being
conditioned to denote:
a first mode in which a single DBMS is updating data resources in the
designated database; or
a second mode in which two or more DBMS's have been granted access to
update data resources in the designated database;
a method for recovery of the designated database in response to failure of
the shared store, the method executed while writing transaction records of
incremental changes to the designated database to the logs of all DBMS's
having access to the designated database, and including the steps of:
(a) at a first DBMS which holds the lock in the first mode, writing updates
of the designated database to the direct access storage;
(b) providing notification to the first DBMS of a request by a second DBMS
to update the designated database;
(c) at the first DBMS, in response to the notification:
writing a database conversion log record denoting a change of the
designated databases from a non-store-dependent state in which updates to
the designated database are written to the direct access storage to a
store-dependent state in which updates to the designated database are
written to the shared store;
writing to the direct access storage all updates of the designated database
which have not yet been written to the direct access storage; and
downgrading the lock to the second mode;
(d) at the second DBMS, obtaining the lock in the second mode and updating
the designated database;
(e) at the first and second DBMS's, writing to the shared store all updates
of the designated database;
(f) in the event of a failure of the shared store, inspecting the mode of
the lock, and:
marking the designated database as store dependent in response to the
second mode of the lock;
recovering the designated database using transaction records in the DBMS's
logs; and
barring access to the designated database in response to the store
dependent marking until recovery is completed.
11. The method of claim 10, wherein in the event of failure of the shared
store and the locking mechanism the following steps are performed instead
of step (f):
inspecting the logs of all DBMS's for store dependent entries;
in response to the store dependent entry for the designated database,
marking the designated database as store dependent;
recovering the designated database using transaction records in the DBMS's
logs; and
barring access to the designated database during recovery processing in
response to the store dependent marking until recovery is completed.
12. The method of claim 10 further including the steps of:
before failure of the shared store;
granting the lock in the second mode to a plurality of DBMS's, updating the
designated database and then surrendering the lock at the plurality of
DBMS's until a single remaining DBMS holds the lock in the second mode;
and
at the single remaining DBMS, writing all updates for the designated
database which are in the shared store to the direct access storage,
purging the updates from the shared store, writing a database conversion
log record denoting a change of the designated database from the store
dependent to the non-store dependent state, and upgrading the lock to the
first mode in which the single remaining DBMS is updating the designated
database; and wherein step (f) now includes:
in the event of failure of the shared store, inspecting the mode of the
lock and marking the designated database as non-store dependent in
response to the first mode of the lock, recovering any databases which are
store dependent, and permitting access to the designated database during
the recovery process; otherwise,
if the lock fails, inspecting the logs of the DBMS's for database
conversion log records and, in response to the database conversion log
record denoting a change in the designated database from a store-dependent
to a non-store dependent state marking the designated database as
non-store dependent, recovering all store-dependent databases, and
permitting access to the designated database during recovery. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
CROSS REFERENCE TO RELATED APPLICATION
This application is related to U.S. patent application Ser. No. 07/628,211,
now U.S. Pat. No. 5,267,835 filed Dec. 14, 1990, entitled "NON-BLOCKING
SERIALIZATION FOR CACHING DATA IN A SHARED CACHE", commonly assigned with
this application; U.S. patent application Ser. No. 07/627,315, now U.S.
Pat. No. 5,287,473 filed Dec. 14, 1990, for "NON-BLOCKING SERIALIZATION
FOR REMOVING DATA FROM A SHARED CACHE", commonly assigned with this
application; U.S. patent application Ser. No. 07/656,567, filed Feb. 15,
1991, for "FAST INTER-SYSTEM PAGE TRANSFER IN A DATA SHARING ENVIRONMENT
WITH RECORD LOCKING", commonly assigned with this application; U.S. patent
application Ser. No. 07/790,241, now U.S. Pat. No. 5,301,290, filed Dec.
8, 1991, for "METHOD FOR MANAGING DATABASE RECOVERY FROM FAILURE OF A
SHARED STORE IN A SYSTEM INCLUDING A PLURALITY 0F TRANSACTION-BASED
SYSTEMS OF WRITE-AHEAD LOGGING TYPE", commonly assigned with this
application; U.S. patent application Ser. No. 07/493,562, now U.S. Pat.
No. 5,301,290, filed Mar. 14, 1990, for "HIERARCHICAL INVALIDATION FOR
DISTRIBUTED CACHES", commonly assigned with this application; U.S. patent
application Ser. No. 07/512,615, priority date Mar. 13, 1987, for "DYNAMIC
SOLE INTEREST IN MULTIPLE SYSTEM LOCKING WITH HIERARCHIES", commonly
assigned with this application.
FIELD OF THE INVENTION
This invention relates to methods for managing computer storage in
distributed systems. More particularly, the invention concerns a method
for minimizing the amount of time to access current data in a database
which may be stored wholly in a DASD-oriented external storage subsystem,
or partly in the external storage subsystem and partly in a shared
high-speed electronic store, while maintaining data coherency with respect
to multiple user systems.
DESCRIPTION OF RELATED ART
In a database system wherein a plurality of independently-operating
computer systems-share data, global locking is employed to maintain
coherency of data with respect to the different systems. A. J. Gore, in
COMPUTER ARCHITECTURE AND DESIGN, Addison Wesley, 1989, discusses the data
coherency problem as one in which sharing data among a proliferation of
processors raises the possibility that multiple, inconsistent copies of
data may exist because of multiple paths to the data resulting from
multiple opportunities to locally modify the data.
The coherency problem has been addressed in the context of a
multi-computer, data-sharing system which includes multiple levels of
storage. In such a system, a secondary level of storage consists of one or
more direct access storage devices (DASD's) which are shared by
independently-operating computer systems. Each computer system includes a
database management system (DBMS) which provides access to databases
stored on the DASD-oriented external storage subsystem. Such a subsystem
may be referred to as a "shared disks" (SD) system.
The first two incorporated applications propose an architecture in which
inter-system caching is provided in the form of a high-speed, frequently
accessed shared electronic store (SES). For various reasons, data is
entered into the SES by the database systems after acquisition from DASD's
and local processing. The SES is used as a store-in cache, where a version
of data can be more recent than the version stored on the DASD subsystem.
In this context, each DBMS possesses and maintains, in its own internal
storage, a buffer to which data is fetched for access by one or more
locally-executing applications. Each DBMS further includes a buffer
manager (BM) for allocating buffer space and for controlling references to
it. The buffer manager has access to tables, lists, and other structures
containing information about the buffer.
Assuming that a database includes hierarchically-ordered data structures of
different granularity, it can be appreciated that these data structures
can be locally cached in the buffer of a DBMS. The buffer manager
coordinates the movement of these structures between its buffer and
external storage via the SES and/or DASD.
A DBMS obtains data and places it in its local buffer in response to
transactional activity generated by applications executing on the DBMS's
processor. Such applications generate read and write operations which, in
turn, utilize the local buffer for access to the data.
Global locking is employed to serialize access by applications to database
contents. In this invention, each DBMS includes a local lock manager (LLM)
for controlling access to locally-stored data structures among other
resources. Locking is mandated by the need for coherency among data
structures in general, and among versions of the same data structure in
the multi-DBMS environment where multiple local buffers exist.
An operating system such as MVS used in the IBM System/370 includes a
hierarchy of locks for various resources in the system. Locks have a name,
a scope, and exclusivity. To support inter-system locking, a global lock
manager cooperates with the LLM's to manage the granting of locks. Global
locking in a shared disk system is covered in detail in IBM Research
Report RJ8017, published Mar. 15, 1991, entitled "RECOVERY AND
COHERENCY-CONTROL PROTOCOLS FOR FAST INTERSYSTEM TRANSFER AND
FINE-GRANULARITY LOCKING IN A SHARED DISKS TRANSACTION ENVIRONMENT", C.
Mohan, et al.
The maintenance and management of global locking, while necessary to
support inter-system coherency of data in the above-described environment,
has substantial costs in the form of increased transaction pathlength and
response time. A significant challenge is, therefore, posed in the
multi-system environment: to maintain coherency of data among the
plurality of systems, while reducing transaction pathlength and response
time.
SUMMARY OF THE INVENTION
The principal objective of this invention is, therefore, to maintain
coherency of data in a multi-DBMS environment with shared access to
DASD-based external storage and shared access to a high-speed electronic
cache, while reducing the overheads of global locking.
The objective is achieved in this invention as a result of the inventors'
critical observation that local knowledge on the part of a DBMS buffer
manager of "intersystem interest" (another system's intention to read or
update) in a database can be exploited to efficiently manage the movement
of data between the local buffer and external storage by selecting a
buffer management policy which best accommodates the level of interest.
Relatedly, the DBMS also exploits the level of intersystem interest on the
parent resource (that is, the database) to possibly avoid lock calls to a
global lock manager for the child resources (for example, records or
pages). Therefore, awareness of the level of intersystem interest in a
database on the part of buffer manager can significantly reduce the
overhead of coherency of pages of that database in a multi-system
environment. For example, if, in the face of no intersystem interest in a
database, a DBMS follows a "no-force-at-commit" policy, it can write
database updates to DASD asynchronously to transaction commit processing.
This improves transaction response time and reduces the lock hold time for
better concurrency. If, on the other hand, a buffer manager detects
intersystem interest in a database, it, according to the invention,
follows a "force-at-commit" policy for maintaining coherency. Relatedly,
"force-at-commit" requires a DBMS, before releasing locks on pages which
are updated by a transaction, to ensure that they are written to storage
and that other systems are notified of the changed pages before the
updating transaction releases locks upon commitment. In the invention, in
order to compensate for the overhead of DASD I/O activities and
transaction commit processing, the updated pages are written to SES, whose
fast read/write capability shortens the transaction commitment processing
and decreases the system response time to transactions.
The invention exploits the knowledge of intersystem interest on a database
by allowing a DBMS to selectively follow the no-force policy when it is
the only system using the database or all systems using the database are
only reading it, or the force policy when one system is updating the
database and other systems are reading it or multiple systems are updating
the database.
The invention further permits the level of intersystem interest in a
database to change at any time and enables all concerned DBMS's to
dynamically adjust to such a change.
The method based on these observations involves a multisystem complex
including a plurality of database management systems (DBMS's), direct
access storage connected to the DBMS's for storage of one or more
databases, and a shared store connected to the DBMS's to temporarily store
data for rapid access by the plurality of DBMS's. In such a system, the
DBMS's provide data from one or more databases to transactions for
database processing. The method maintains coherency of a database with
respect to the plurality of DBMS's by the following steps:
responsive to a first transaction request to a first DBMS for data from a
designated database in the absence of any other transaction requests to
any other DBMS for updating data from the designated database:
at the first DBMS, data is obtained from the direct access storage; and
a transaction operation is executed and committed on the data at the first
DBMS; and
responsive to a second transaction request directed to the first DBMS for
data from a designated database which is concurrent with a third
transaction request to a second DBMS for updating data in the designated
database:
if the data is in the shared store, the data is obtained by the first DBMS
from the shared store, otherwise, the data is obtained from the direct
access storage;
an updating transaction operation on the data is executed and committed at
the second DBMS; and
synchronously with commitment of the transaction operation, the data is
placed in the shared store.
Since the updating of data at one system and placement in the shared store
may invalidate other versions of the same data at other systems, the other
systems are notified of the update either directly by the updating system
or by registration of relevant information in the global lock manager
which enables another system to detect that it has an invalid copy of the
data.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram illustrating the multi-system environment within
which the invention operates.
FIG. 2 is a flow diagram illustrating the essential steps in the method of
the invention.
FIGS. 3A and 3B illustrate lock tables maintained in the system of FIG. 1.
FIG. 4 is a block diagram illustrating the data structures managed by a
buffer manager in the practice of the invention.
FIG. 5 illustrates a DBMS log with an entry denoting the first update of a
database according to the invention.
FIG. 6 is a table illustrating compatability of buffer manager database-P
lock modes.
FIG. 7 is a table illustrating determination of the mode of a cached state
of a database based on intersystem interest in the database.
FIG. 8 is a table illustrating buffer manager processing and downgrade of
the cached state of a database when intersystem interest in the database
changes.
FIG. 9 is a flow diagram illustrating the processing steps required to
establish, maintain, and change intersystem interest at one DBMS according
to the invention.
FIG. 10 is flow diagram illustrating the DBMS processing steps which are
executed when one DBMS changes the mode of its database lock in response
to a change in intersystem interest caused by the request for access to
the database by another DBMS.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Refer to FIG. 1 for an understanding of the multi-system environment within
which the invention operates. In FIG. 1, two CPU's processor 1 and
processor 2 are illustrated. Each can comprise, for example, an IBM
System/360 or 370 architected CPU having an IBM MVS operating system. An
IBM System/360 architected CPU is fully described in Amdahl et al, U.S.
Pat. No. 3,400,371, issued on Sep. 3, 1968. Configuration involving CPU's
sharing access to external storage is set forth in the incorporated patent
applications and in Luiz et al, U.S. Pat. No. 4,207,609, issued Jun. 10,
1980.
Each CPU executes a database management system (DBMS) 10, 20. A DBMS
includes a local lock manager (LLM) 11, 21 and a buffer manager (BM) 12,
22. Each BM maintains a local buffer 13, 23 for storage of data. Each DBMS
serves one or more applications 14, 24, responding to the requirements of
application-generated transactions for reading and updating data.
For purposes of this invention, it is asserted that data is available on
DASD-based external storage 30 (hereinafter "DASD") in the form of one or
more databases, each including a hierarchical structure of pages and
records, with each page including one or more records.
FIG. 1 illustrates the relationship of organized storage to each processor.
As shown, each CPU accesses both an internal storage in the form of a
local buffer and external storage in the form of DASD 30 and a high-speed,
store-in cache 32. The cache 32 is referred to hereinafter as a "shared
electronic store" or "SES". The DASD 30 is the ultimate repository of
databases, with data pages being selectively moved from the DASD 30 to the
buffers 13, 23 over data paths 17, 27. The data paths 17, 27 are
conventional I/O couplings between CPU operating systems and DASD 30. The
SES 32 is provided for store-in caching of pages which have been brought
into the buffers 13, 23 for transaction processing. The SES 32 is written
to, and read from, over high-speed links such as fiber optic links 18 and
28 which couple the SES 32 and processors 1 and 2. The SES 32 includes
control logic which is invoked by issuing commands, such as Read and
Write, by the logic in the BM's over links 19, 29.
The DBMS's 10, 20 also maintain respective logs 36, 37 for recovery
purposes in the event of failure. Log-based database recovery is a
well-understood feature of database systems whose accommodation of the
method of the invention is explained later.
Typically, an application invoking the DBMS 10 would reference a page by an
address which names the database containing the page and identifies the
page. If the page is not available in the buffer 13, it must be obtained
either from the DASD 30 or the SES 32.
Coherency of data with respect to the plurality of processors in the system
illustrated in FIG. 1 is ensured by global lock management embodied in a
global lock manager (GLM) 33 with connections to each LLM 11, 21. It is
assumed that the DBMS's 10, 20 support record level concurrency between
transactions. This allows intra-system and inter-system concurrency on a
record within a page. However, the unit of coherency between systems is a
page. This is because the local buffer manager deals with a page as a unit
of I/O. In the explanation that follows, it is assumed that the GLM is an
autonomous component which can be executed in its own CPU, or in a
co-processing mode in the CPU of one of the DBMS's. Further, it is assumed
that the LLM's and GLM communicate by well-known message passing or mail
drop techniques.
INTERSYSTEM INTEREST
The invention avoids or reduces the overheads of coherency based on the
knowledge of level of intersystem interest on a database. For the purpose
of this description, the level of inter-system interest on a database, in
increasing order can be:
(a) level A interest in which only one system is using the database, or all
systems using the database are only reading it;
(b) level B interest in which one system is updating the database and other
systems are reading it; and
(c) level C interest wherein multiple systems are updating the database.
In the invention, the buffer manager component of a DBMS is made aware of
the level of inter-system interest in a database. Investing the BM with
this awareness avoids or reduces the overheads of coherency of pages of
that database in the environment of FIG. 1.
For example, to maintain coherency in a shared disks environment while
following a no-force-at-commit policy, a DBMS would acquire global locks
including a page-cache lock in Share mode on every page which is locally
cached in the buffer pool and a page-cache lock in Update mode to update a
page. These global locks are in addition to transaction locks and have
message overhead.
To maintain coherency while following a force-at-commit policy in a
multi-system environment, a DBMS must ensure that pages are written to
disks and other systems are notified of changed pages before releasing
page locks. The inventors observe that the overhead of disk I/O procedures
in transaction commit processing can be reduced significantly by using the
shared electronics store with fast read/write capability. Therefore,
updated pages can be forced to this store quickly. However, in spite of
the shared electronics store, it is contemplated that a no-force policy is
faster, less costly, and more efficient than a force policy. Having
knowledge of the inter-system interest in the database allows the DBMS to
selectively follow the no-force policy when there is level-A interest in a
database and the force policy when there is level-B or level-C interest in
that database.
Another optimization occurs from informing a DBMS as to inter-system
interest. Previously, in a multi-system environment with shared disks, the
provision of subpage concurrency within a page required the DBMS to
acquire a page-cache lock to serialize concurrent updates to a page from
different systems. However, in level-B interest when only one system is
updating the database and others are reading it, there is no need for the
updating system to acquire a page-cache lock on the page, since it knows
no other system will update it.
In summary, informing the DBMS of the level of inter-system interest in the
multi-system environment of FIG. 1 provides several significant and
unexpected optimizations. When operating at level A interest, a DBMS can
follow a no-force-at-commit policy. Significantly, this means that when
only one DBMS is accessing a database and is updating that database, it
can follow a no-force-at-commit policy and group I/O operations with DASD
for batch processing and without the requirement to synchronize the
writing of each update to DASD with commitment of the updating
transaction. When a DBMS is operating at level A interest, global
page-cache locking is not required. When operating at level B interest,
only one system is updating; therefore, that one system is not required to
obtain a page-cache lock to serialize concurrent updates to the page.
The invention, therefore, is based upon the provision of inter-system
interest information to the DBMS's of a system with shared disks and a
shared electronics store and the investment of the systems with the
ability to selectively implement no force or force policies in response to
changing inter-system interest information and further to implement
page-cache locking policies in response to the same information. This is
significant because prior art systems declare a static policy for
inter-system use of a database. For example, in the prior art, a database
is declared for read only or for read/write use by multiple system prior
to its use in a declared mode. Change of such policy requires an explicit
action by means which are external to the DBMS. In the invention, a DBMS
observes and reacts to the change of inter-system interest in a dynamic
way that requires no external action and that provides the optimizations
enjoyed by reduction of coherency overhead described above.
In the preferred embodiment, the DBMS is informed as to current state and
change in inter-system interest by the GLM, using an in-place hierarchical
locking scheme for caching pages of a database. In the preferred
embodiment, the hierarchy includes a database-P (physical) lock on a
database, from which page-P locks on database pages descend. In the
invention, the BM exploits this hierarchical locking scheme for adapting
to the changes of inter-system interest in a database. In the invention,
BM locking on a database is different than transaction locking on objects.
The purpose of BM locking is to maintain cache coherency in a multi-system
environment and has no meaning in a single system environment. The P locks
are system level locks, not transaction level locks. Furthermore, in the
invention, BM locks are negotiable in that the LLM is made aware that in
the case of contention or other activity with reference to a database-P
lock, a BM procedure (a "P lock exit") must be invoked. The negotiability
of the database-P lock enables a BM to react dynamically to a change of
inter-system interest. Management of the inter-system P locks by the
global lock manager is discussed below.
THE INVENTION
FIG. 2 illustrates the essential steps of the invention for a given DBMS.
Initially, access will be sought to a database which has not been opened
at the DBMS. The request is denoted in step 40. While the database is
being opened at this DBMS, BM locking on the requested database will be
inspected in step 42 to determine whether another system is currently
using the database. If not, the database is acquired, opened, a database-P
lock is acquired and tabled at the GLM 33 and the negative exit is taken
from decision 42 to step 43. In step 43, in the absence of any other
interest in the database, the using DBMS can manage its buffer according
to a no-force policy and can dispense with the acquisition of page-P locks
for updates to pages in this database. Since the database-P lock is
negotiable, any time another system requests (block 44) the database-P
lock in a mode which is incompatible with existing held modes, or which
causes a change in the resultant mode, the GLM 33 will inform the DBMS.
The other DBMS's request is evaluated in step 45. If the request is such
that it would result in intersystem read/write (level B) interest or in
intersystem write-write (level C) interest, the positive exit is taken
from step 45 and the buffers of all DBMS's accessing this database will be
managed by a force policy in which pages with committed updates are
written to the shared store by the updating system and requests for pages
from this database are satisfied by looking first to the shared store and
then to the DASD. A necessary step of this force policy is notifying other
systems of updates to pages. Such notification can be direct by
inter-system message transfer, in which the updating system informs the
other systems of the update and the other systems acknowledge the message.
The data sharing mode of the IMS products available from the assignee
employs this technique by means of a "buffer invalidation message".
Alternatively, information signifying page update by one system can be
provided to all other systems by means of information maintained at the
GLM for this purpose. In this regard, see, for example, the third
incorporated U.S. Patent Applica | | |
