JPS62145349A - Intersystem data base sharing system - Google Patents

Abstract

PURPOSE:To allow systems to share data bases with a small communication overhead by providing plural data processors with subsystems which access common data resources respectively and lock managers. CONSTITUTION:Respective host computers 1-3 include operating systems 11-13, lock managers 21-23, and subsystems 31-36 one to one and common data resources are stored in common file devices 61-66. The common file devices 61-66 are connected to the host computers 1-3 and the subsystems 31-36 send lock requests to the lock managers 21-23 to acquire locks for the common data resources and then access the common data resources through the operating systems 11-13. The locks are made in block units. The subsystems 31-36 are equipped with buffer pools 41-46 and journal files 51-56.

Description

[Detailed Description of the Invention] [Field of Application of the Invention] The present invention relates to an inter-system database sharing method, and in particular to a shared data access control method for efficient access while guaranteeing the consistency of data resources. be.

[Background of the invention]

A method in which a plurality of data processing devices access a shared data resource while performing exclusive control on a block basis is described in, for example, Japanese Patent Laid-Open No. 57-64850 and Japanese Patent Laid-Open No. 57-64861. A method is known in which two data processing apparatuses are connected through a communication device and controlled while exchanging lock information with each other. That is, in this method, exclusive control is performed by granting a lock before issuing an instruction to a shared data resource. Furthermore, when the shared data no longer needs to be used, a lock release request is made and exclusive control is discontinued. However, these methods require data processing equipment and congruence.
Efforts have been made to reduce the communication overhead between two data processing devices by providing interest bins 1 to 1 for each class, but when three or more data processing devices access a shared data* source No consideration has been given to this.

Further, as an example of such a system, there is a system in which a special control device for performing exclusive control is provided separately from the data processing device, as described in Japanese Patent Laid-Open No. 59-81748. In other words, in this method, before using the shared data, the data processing device issues a lock block instruction to the control device that manages the shared data.
Exclusive control is performed, and when data no longer needs to be used, an unlock command is issued to the control device to release the data from use. Furthermore, this method allows three or more data processing devices to access shared data resources, and by entrusting exclusive control to a dedicated control device, the processing overhead of the data processing devices can be reduced. However, this method requires a special control device, and there is a problem in that this control device becomes the key to the performance and reliability of the entire system.

Further, in the above-mentioned conventional example, the publication does not contain any information regarding a method for determining whether the data contents in the buffer pool managed by the subsystem are valid or invalid. If there is no way to determine whether the data content is valid or invalid, each subsystem must perform input/output to the file device each time it accesses the data resource, and the effect of buffering the data resource (block) is can no longer be expected.

[Purpose of the invention]

An object of the present invention is to improve such conventional problems, and to reduce communication overhead when multiple data processing devices share and access data resources on a file device.
Another object of the present invention is to provide an inter-system database sharing method that can perform exclusive control without requiring special hardware. Another object of the present invention is to provide an inter-system database sharing method that allows multiple subsystems accessing shared data resources to determine whether the content of data in buffer pools managed by each subsystem is valid or invalid. It is in. Another object of the present invention is to select data resources in order to guarantee the consistency ratio of data*sources against various types of failures such as subsystem failures, communication equipment failures, and data processing equipment failures. The object of the present invention is to provide an inter-system database sharing method that prohibits access.

Furthermore, another object of the present invention is to provide a system in which, when a data processing device fails, the lock manager on another data processing device can quickly perform the function performed by a lock manager on that data processing device. The objective is to provide a method for sharing databases between users.

[Summary of the invention]

In order to achieve the above object, the inter-system database sharing method of the present invention includes a plurality of data processing devices, a communication device that interconnects the data processing devices, and a storage system for storing data resources shared by the plurality of data processing devices. wherein the data processing device includes one or more subsystems that each access the shared data resource, and a lock manager that exercises exclusive control over the subsystem's access to the shared data resource. There are characteristics. Furthermore, in the present invention, the shared data resource is logically divided, a data processing device is determined as a master for each set of divided data resources, and a lock request for the shared data resource is handled by a lock target resource. It is sent to the lock manager on the master data processing device, where exclusive control is performed.

Furthermore, in the present invention, each lock manager has means for storing which subsystem has made the latest update to the shared data resource of which it is the master, and responds to lock requests from subsystems. As information, based on the above storage means.

Notifies whether the data content in the buffer pool managed by the lock requesting subsystem is valid or invalid.

In addition, in the present invention, each lock manager is able to manage data resources in the event of a failure of a subsystem or a failure of a communication device. '9Hold the lock to ensure sex, i!
! Selectively prohibit access to data resources. Furthermore, in the present invention, if each lock manager becomes inoperable due to a failure of a data processing device, another data processing device becomes the new master for the shared data resource for which the failed data processing device is the master. This allows access to shared data resources to continue.

Example of invention C] Embodiments of the present invention will be described below with reference to drawings.

The first UA is a block diagram of a computer system illustrating an embodiment of the present invention.

In Figure 1, three data processing machines Fj '111
An example is shown in which six subsystems 31 to 36 operating on r2.3 share and access file devices 61 to 66. Data processing devices (hereinafter referred to as hosts or host computers) are interconnected via one communication device 4 . As the communication device 4, the channel
There are several types of equipment, such as CTCA (transportation equipment) and communication equipment (CTCA). Each host computer has one operating system (11
~13), 1 lock manager (21~23), 1
one or more subsystems (31-36). Shared data resources are stored in shared file devices (61-66). The shared file devices (61-66) are connected to each host computer (1-3), and the subsystems (31-36) make lock requests to the lock managers (21-23) to obtain locks on the shared data Ft source. After acquiring the operating system (11-13
) to access shared data resources. The lock is
It is done in block position. Each subsystem (31 to 36
) bias the buffer pools (41-46) and journal files (51-56), respectively.

Shared data resources are divided into logical resource groups and
A master host computer is determined for each resource group. In this example.

The shared data resources stored in the shared file device [61 and 62 are stored in the resource group A and the shared file device fi1i1[
The shared data resources stored in files 63 and 64 are grouped into resource group B, the shared data resources stored in shared file system fiff65 and 66 are grouped into 52g group C, the master of resource group A is set to host l, and resource group B is set to 52g. Host the master of 2. The master of resource group C will be explained as post 3. The resource group classification and master i#portion are arbitrary, for example.

One host may be the master of two or more resource groups, or there may be a host that does not have any resource group that is the master. Furthermore, the number of resource groups and the number of hosts do not need to match. Classification of resource groups and assignment of masters can be performed by WRM according to system performance, as described later.

What actually issues lock requests is a transaction that operates under the control of each subsystem.

A transaction is assigned a unique identifier within each subsystem, and by combining this identifier with the subsystem identifier, a transaction can be uniquely identified within the system. Each transaction makes a lock request to a lock manager on the same host computer.

The lock miger that receives the request performs the necessary exclusive control processing if the master of the data resource (block) to be locked is the master of the own system, and if the master of the data resource (block) to be locked is the master of the other system. , forwards the lock request to the master host computer.

The lock requesting transaction does not need to be aware of which host computer is the master of the data resource to be locked. As is clear from the above description, each lock manager only needs to communicate with the master host computer of the data resource to be locked, and may also communicate with other host computers.
Consider a system consisting of 1 host computer, divide the shared data resources into n equal groups, and divide the shared data resources into n equal groups.
Suppose you assign a computer as the master. Assuming that a subsystem on a host computer accesses all shared data resources with equal probability, the expected value C of the number of equalizations that occur with one lock request issued by that subsystem is It is expressed by a linear equation and does not depend greatly on n.

C= (n-1,) X (1/n)=1-
(1/n) If there is a system in which all lock managers have the same lock information without specifying a master.

C= n −1 and the communication overhead will increase proportionally with n. Moreover, no communication occurs in the first place for resources whose master is the host computer of the lock requesting subsystem. Therefore, if it is known in advance that access to a shared data resource by a subsystem has locality, the master of the shared data resource mainly accessed by that subsystem is assigned to the host computer to which that subsystem belongs. By doing so, it is possible to reduce communication overhead.

FIG. 2 is a block diagram of the lock manager in FIG. 1. The exclusive control procedure will be explained in detail with reference to FIG.

For convenience, let us consider a case where the subsystem 31 on the host computer 1 issues a lock request to the lock manager 21.

(a) In the case of a lock request for a shared data resource yielding to resource group A: In this case, the master of the data resource to be locked.

Since it is a host [-computer 1], no communication occurs. When the lock manager 21 receives a lock request,
Resource group management table 130. Following the resource hash table 151, the first resource table 1 is searched. One resource table has one lock target data resource (
block). A 'rCFX table corresponding to the requested data resource to be locked is created and connected to the chain from the resource hash table 151. The resource hashish table 151 uses the resource name as a search key.

This is a table for searching resource tables using the hashing method. Next, the lock manager 21 creates a lock table 181 corresponding to each lock request,
Connect to the chain from the resource table. The lock table is also connected to a chain from the transaction table 141 corresponding to the transaction.

The above two chains allow the lock table to
It expresses which data resource of the runzaktion the lock request corresponds to. A lock request is granted immediately if no other locks exist on the subject data resource, or if the lock mode is compatible with the requested lock mode, even if other locks exist. If the data resource to be locked is already locked in a mode that is incompatible with the requested lock mode, the lock request is made to wait until the previous lock is released. In this embodiment, five types of lock modes are used, and compatibility among the five modes is determined according to the matrix of the third UA. The mode setting method may be any method other than that shown in FIG.

(b) In the case of a lock request for a shared data resource belonging to a resource group: In this case, the lock manager 21 refers to the resource group management table 130 and determines that the master of the lock pressure data resource is the host 1-computer 2. The lock request is transferred to the lock manager 22 on the host computer 2 using the communication function provided by the operating system 11. Upon receiving the transferred lock request, the lock miger 22 performs the same process as in case (a), and when the lock is granted, sends a response to that effect and transfers the lock on the host 1-computer l. manager 21
Send to. The lock manager 21 that received the response,
The resource group management table 130 and the resource hash table 152 are followed, the resource table 173 is searched (if the resource table does not exist, a new one is created), and the lock table 184 is created to connect the chain. What should be noted here is that in this case, the table corresponding to the lock request is stored in the lock manager 21 on the same host computer as the lock request source subsystem and the lock manager 21 on the master host computer of the lock target resource.
This means that it is set twice. This means that
This is related to the reconfiguration of lock information by the backup system, which will be described later. The above explanation is also the same when the subsystem 31 issues a lock request for a shared data resource belonging to resource group C.

Next, each subsystem's buffer pool (41 to 46)
This section explains how to synchronize the contents of .

Each subsystem (31-36) uses a respective buffer pool (41-46) to access shared data resources. If the data resource (block) to be accessed already exists in the buffer pool, the subsystem does not perform input/output with the shared file device @ (61 to 66), and the data in the buffer pool is By using the contents and performing input/output only when the data resource g (block) to be accessed is not in the buffer pool, the number of input/outputs to the shared file device Et (61 to 66) can be reduced. There is. However, since the buffer pool is held independently for each subsystem, in an environment in which data resources are shared by multiple host computers as in the case of the present invention, the data contents in the buffer pool of the local subsystem are not always the latest. (The data resource has been updated in another subsystem t1)
Such a situation may occur. Lock manager (21-2
3) notifies the lock requesting subsystem that an update has occurred in another subsystem (therefore, the contents of the block in the buffer pool are invalid) as response information to the lock request. This allows the subsystem to
I/O to the shared file device (61-66) is performed not for each individual access, but when necessary, i.e.
This only needs to be done if the data resource (block) to be accessed is not in the buffer pool, or if the data resource to be accessed is in the buffer pool but its contents have been invalidated because it has been updated by another subsystem chimney.

In order to provide the above response information, the lock manager (21~
23) sets an update synchronization map (161 to 163) for the resource group of which the own host computer is the master, and stores update processing of each subsystem. In this embodiment, the update synchronization map consists of N entries,
Each entry is 4 bytes. N corresponds to the size of the hash space (set of hash values) when hash sync is performed using the resource name as a key, and is specified in the system definition. The value of N is determined by the unit of data resource that stores update processing (the larger N is, the more detailed the update can be stored) and the memory required for the update synchronization map (N
(The larger the value, the more memory is required). In this embodiment, each entry in the update synchronization map consists of 4 bytes (32 bits).
Each bit corresponds to one subsystem. In the system shown in FIG. 1, six subsystems are in operation, so six of the 32 bits are actually used.

If the above bit is 1, if the subsystem corresponding to that bit has a data resource with a hash value corresponding to the corresponding entry in its own system's buffer pool, the contents of that data are valid. It means that.

Here, we will explain in detail how to use the update synchronization map.

The lock manager is a lock manager for Safsoam force 1, etc.;
1<, the bit corresponding to the subsystem in the update synchronization map entry corresponding to the hash value of the data resource to be locked is set to 1. At the same time, if the lock request described above is a lock for updating data resources (corresponding to the SU, PU, and EXMo1 locks in Figure 3), all other bits in the above entry are set to 0. Make it. The lock requesting subsystem is informed of the state of the corresponding bit in the bit that performs the bit manipulation as response information. If the value of this bit is 1, another subsystem has performed update processing on the data resource between the previous lock request made by the lock requesting subsystem and the current lock request. If the data resource exists in the buffer pool of the lock requesting subsystem, its contents are valid.

Conversely, if the value of this bit is 0, it means that another subsystem may have updated the corresponding data resource, and the lock requesting subsystem must always store the contents of the data resource in the shared file. Must be read from the device. By using the above method, data resources can be shared between subsystems without impairing the effectiveness of buffering performed by each subsystem.

Next, we will discuss countermeasures when various types of failures occur within the system. There are three types of failures: primary. (a)
Subsystem failure (b) communication device failure; (c) host computer failure (including operating system failure) The operation of the lock manager when the above three types of failure occur will be described below. This allows you to maintain the integrity of your data resources even if a failure occurs.

The system can continue to operate efficiently.

First, in the case of a subsystem failure, since access to the shared data resource is not completed, there is a possibility that the contents of the data may contain inconsistencies.

Therefore, it is necessary to prohibit access to the shared data resource that was held by the failed subsystem and maintain this prohibited state until the data restoration process is completed.

Now, using FIG. 2 as a block diagram of the lock manager 21, assume that the subsystem 31 fails. Processing of other lock managers and processing when other subsystems fail are all performed in the same way. In this embodiment, a subsystem failure is detected by a separately provided subsystem monitor and notified to the lock manager. The above-mentioned monitoring monitor is not included as one component of the present invention.

When the lock manager 21 detects a failure in the subsystem 31, it traces the subsystem management table 120 and the transaction tables 141 and 142 and creates a lock table 181 corresponding to the lock held by the subsystem 31.
, 182, 184°185. Next, the lock pending status is set in the lock table, and at the same time, the pending status and the pending lock mode are also recorded in resource table 1 No. 1.172, 173, and 174 corresponding to the data resource to be locked.

Thereafter, if another subsystem issues a lock request that is incompatible with the mode of the lock held for the data resource in the pending status, the lock manager 21 rejects the lock request. The suspension of the lock is released by the subsystem 31 reporting this to the lock manager 21 when the subsystem 31 recovers and completes the data restoration process. Through the above processing, in the event of a subsystem failure, it is possible to prohibit access to shared data resources that may have inconsistencies.

Next, the operation of the lock manager in the case of a communication device failure will be described. For convenience, the operation of the lock manager 21 will be described assuming that the communication device 4 has failed and communication between the host computers 1 and 2 has become impossible. The lock manager 21 rejects the lock request from the subsystems 31 and 32 on its own host computer 1 for the data resource g (data resource belonging to resource group B) that is mastered by the host computer 2 with which it is unable to communicate. 5i: Forbids access to source group B for 31.32.At the same time, the lock manager 21 prohibits access to source group B. At the same time, the lock manager 21 prohibits the subsystems 33. The lock held for the data resource (data resource that yields to resource group A) is placed in a pending state, and lock requests that are incompatible with the held lock are rejected. When i recovers, the communication between host computer 1 and host computer 2 is released. When i recovers, lock manager 21 and lock manager 22 mutually report the status of transactions on their own system to the other. For example, , the transaction corresponding to the I-transaction table 141 is terminated while the communication device is out of order.
4, but the release of the lock 184 cannot be communicated to the host computer 2, which is the master of the locked data resource 173. Upon communication recovery, the lock managers 22
recognizes the end of transaction 141 and releases the table corresponding to lock table 184 from its own tables. In this way, table misalignment between the lock miger and the lock miger can be eliminated. With the above processing, 1 communication i1
200, access from subsystems is prohibited to prevent inconsistencies in the contents of data resources.

It is possible to restore consistency between lock managers while recovering from a failure.

Finally, we describe the operation of the lock manager in the event of host computer failure (including operating system failure). If the host computer 1 fails, the lock manager 21 will no longer be able to operate, so the subsystems 33, 34, 35 on other host computers will fail.
．． 36 becomes inaccessible to the data FC@ (data resource that doubles over to the resource group) of which the host computer l is the master. It is undesirable for the inaccessible state to continue until the failure of the host computer 1 is recovered from the viewpoint of the unavailability of data resources.

Therefore, a backup system is provided for the lock manager 21 (this is called the original system), and when the lock manager 21 becomes inoperable, the backup system becomes the new master of resource group A and submits to resource group A. Enable continued access to data resources.

The method for selecting a backup system for the original system is as follows.
Optional. In this embodiment, the backup system of the host computer 1 is the host computer 2. For convenience, the backup system of the host computer 2 is designated as the host computer 3, and the backup system of the host computer 3 is designated as the host computer 1. Therefore, the host computer l
If resource group A fails, exclusive control regarding resource group A is
The lock manager 22 on the host computer 2 will do this.

The problem here is that when the lock manager 22 attempts to newly perform the function of the master of resource group A,
This means that it is necessary to have the same information as the lock information that the lock manager 21 was managing at the time it became inoperable. As mentioned above, if the host computer that is the master of the resource to be locked is different from the host computer that operates the subsystem, the lock information held by the subsystem is shared by the lock managers on both host computers. has the same lock information twice. For purposes of discussion, subsystem 33.3
The lock managers 21 and 23 hold information on the lock placed on the data resource by the resource group A. Therefore, the lock manager 22 communicates with the lock manager 23 so that the subsystems 33.34
It is possible to reconstruct the information on the locks held by 35.36 on the data resources belonging to resource group A. Based on the above explanation, if there is a means for the subsystem operating on the failed host computer to reconfigure the information on the locks that the local host computer has placed on the resources that are subject to data resource group A, which is the master, the bankup system It can be seen that the lock manager 22 can repurchase all necessary lock information.

In this embodiment, two types of means are prepared as means for reconfiguring lock information as described in 2. It is up to each individual whether to use only one of these two methods, to use both methods together to improve f3 reliability, or to use both methods and therefore not provide a backup for the master. The system administrator may decide this based on the characteristics of the system.

FIG. 1 is an explanatory diagram of the first means for reconfiguring lock information. With this means, when the lock manager 2I receives a lock request or an unlock request for a shared data resource residing in resource group A from a subsystem 31 or 32 on its own host computer, and grants or releases the lock, is communicated to the backup lock manager 22. Based on the above communication, the lock manager 22 sets a corresponding table group regarding the locks that the subsystems 31 and 32 have placed on the shared data resources belonging to the resource group A.

With this method, the bank-up type lock manager 22
Since the lock manager 21 retains the necessary lock information in the same table format as the original lock manager 21, no special processing is required even if the lock information needs to be reconfigured. However, this method increases the throughput overhead during normal subsystem operation.

Next, FIG. 5 is an explanatory diagram of a second means for reconfiguring lock information. Each subsystem records update processing performed by managed transactions in a journal file so that data resources can be restored to a consistent state when various types of failures occur. Therefore, by reading a subsystem's journal file, it is possible to identify the data*source that the subsystem is updating (ie, the data resource that is locked for update). Here, the reconfiguration of lock information in question relates to locks held by subsystems that were operating on the failed host computer, so locks for reference can be ignored. This is because the subsystem will stop working if the host computer fails, and the data resources that the subsystem is updating may contain inconsistencies, so access from other subsystems will not be possible. This is because, although it is necessary to prohibit access, there is no conflict in the data resource that the subsystem has only referenced, so there is no need to reconfigure the lock information to prohibit access.

In the case of Figure 5, the backup lock manager 22
When detecting a failure in host computer 1, journal file 5 of subsystem 31.32 + 5
2, subsystems 31 and 32 find the data resource belonging to resource group A that is being updated from the journal record of the transaction in progress, create a resource table and a lock table corresponding to that data resource, and hold it. state. With this method, when lock information needs to be reconfigured, it is necessary to read the subsystem's journal file and set up the table, but no extra overhead is incurred during normal subsystem operation. Note that in order for the lock manager 22 to be able to read the journal files 51 and 52,
Journal file IQ locations 51 and 52 must be connected to the host computer 2, but are not shown in FIG.

6 to 12 are flowcharts of locking and unlocking procedures according to the present invention.

In FIG. 6, each transaction makes a lock request to a lock manager on the same host computer. Search for the transaction table corresponding to the lock request source, and if it does not exist, create a new one (Step 10)
01), the resource group table containing the data resource to be locked is searched (step 1002). If the master of the data resource to be locked is the own system (step 1003
), searches for the resource table corresponding to the data resource to be locked, and if it does not exist, creates a new one (step 1004)
. Also, if the data resource is saved and is incompatible with the request lock mode (step 1005), an error return/error response is sent, and if it is compatible, a lock table is created and a chain is set (step 1005). 1
006).

In FIG. 7, if the lock is granted immediately (step 1007), an entry in the update synchronization map is searched,
Bit-like! Set pu in the response area (step +00
9). If the lock cannot be granted, the lock request is made to wait until the lock is granted (step 1008). The pin 1- corresponding to the lock request source subsystem in the update synchronization map entry is set to N (step 1010). Also.

If it is a lock request for update, the pins corresponding to other subsystems in the update synchronization map entry are cleared (steps 1011 and 1012).

In FIG. 8, if there is a backup system using the method shown in FIG. 4 and the lock request is from the local subsystem, table change information (lock permission) is communicated to the backup system (steps 1013 and 1014). ). Also,
If the lock request is from a subsystem on another system, a normal response is sent to the request source (step 1015, 1
．． 016). On the other hand, if the white type is not a lock request for the master data resource, in FIG. 9, the lock request is transferred to the master host 1- of the data resource to be locked and a response is waited for (step 10). If the response is not correct, send an error return step 101
．． 8) If there is a normal response, search the resource table corresponding to the data resource to be locked, and if not, create a new one (step 1019).

Next, create a lock table and set up the chain (
Step 1020).

Next, in the case of unlocking, as shown in Figure 10,
Search the lock table corresponding to the lock to be released (step 1.021). In that case, the lock is on the master's data resource (step 1).
022), and if the system is a backup system using the method shown in Figure 4 and the unlock request is from the own subsystem (step 1023), the table change (lock release) is notified to the backup system (step 1024). .

If the unlock request is not from the own subsystem in the bank-up system shown in FIG. 4, the lock table is released (step 1025). Furthermore, as shown in Fig. 11,
When the last lock on the data resource is released (step 1026), the resource table is released (step 1027). In addition, if the last lock is not released, if there is a pending lock request for the data resource (step 1028), the pending lock request for the pending store that can be granted by this unlock request is released. (step 1029).

In addition, in FIG. 12, if the own system is not locked on the master's data resource (step 102
2) forwarding the unlock request to the master host of the target data resource (step 1030); Next, the lock table is released (step 1031). If the last lock on the data resource is released (step 1032), the resource table is released (step 103).
3).

〔Effect of the invention〕

As explained above, according to the present invention, data resources can be shared by multiple data processing devices without using special hardware and with a small communication overhead that does not depend much on the number of data processing devices. An economical and high-performance database sharing system can be constructed. Also.

According to the present invention, since each subsystem can determine the validity of data in the buffer pool, buffering techniques can be used even in an environment where data resources are shared. In addition, in the event of any type of failure, access to data resources can be selectively prohibited, ensuring data integrity.Furthermore, if a lock manager becomes inoperable, other lock managers can quickly Since the processing is delegated, the reliability and availability of the system can be improved.

[Brief explanation of drawings]

FIG. 1 is a block diagram of a computer system showing an embodiment of the present invention, FIG. 2 is an internal block diagram of the lock manager in FIG. 1, and FIG. 3 is a lock mode 1-1 in the present invention.
Figures 1 and 5 are diagrams showing examples of backup system settings in the present invention, and Figures 6 to 12 are diagrams showing locks showing one embodiment of the present invention. , is a flowchart 1- showing the unlocking procedure. 1.2, 3: Data processing device, 4: Communication device, II, 1
2,13: Operating system, 21.22,2
3: Lock manager, 31-36: Subsystem, 4
1-46: Buffer pool, 51-56: Journal file, 61-66: Shared file device, 100: Host management table. 120: Subsystem management table, 141. i42,
+43=transaction table, 151.152,
153: Resource hash table, 161.162,16
3: Update synchronization map, 1st to 175: Resource table,
181-186 Nirotsu 1st Ward 2nd Figure O: Rain and sky ×: Compatibility (1st 4th - Figure 5 Figuresho 6th) Dorishi 1 Thatch 2 Figure 1O Figure 11 Figure fII, 'Ro

Claims (2)

[Claims] (1) A plurality of data processing devices, a communication device that interconnects the data processing devices, and a file device that stores data resources shared by the data processing devices; In a computer system comprising one or more subsystems that access a shared data resource and a lock manager that exercises exclusive control over the subsystem's access to the shared data resource, logically dividing the shared data resource, In addition to determining the master data processing device for each set of divided data resources, each lock manager is informed of which subsystem has made the latest update to the shared data resource of which its own system is the master. When a lock request for a shared data resource is transferred to a lock manager on a data processing device that is a master of the data resource to be locked, the lock manager stores the storage means as response information to the lock request. An inter-system database sharing method is characterized in that a lock requesting subsystem performs exclusive control by notifying whether the data contents in a buffer pool managed by the subsystem are valid or not. (2) In the event of a failure in a subsystem or communication device, the lock manager suspends locks to maintain the integrity of the data resource, selectively prohibits access to the data resource, and If the shared data resource becomes inoperable due to a failure, a separate data processing device becomes the new master for the shared data resource for which the failed data processing device was the master. intersystem database sharing method.