GB2188177A - Computer system for sharing a data resource - Google Patents
Computer system for sharing a data resource Download PDFInfo
- Publication number
- GB2188177A GB2188177A GB8703191A GB8703191A GB2188177A GB 2188177 A GB2188177 A GB 2188177A GB 8703191 A GB8703191 A GB 8703191A GB 8703191 A GB8703191 A GB 8703191A GB 2188177 A GB2188177 A GB 2188177A
- Authority
- GB
- United Kingdom
- Prior art keywords
- lock
- resource
- data
- data resource
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/526—Mutual exclusion algorithms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/52—Indexing scheme relating to G06F9/52
- G06F2209/522—Manager
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
Abstract
In a computer system having a plurality of host data processors (1-3), a communication unit (4) for interconnecting the data processors and a file unit (61 - 66) for storing a common data resource shared by the data processors, the common data resource is logically divided into groups 61,62; 63,64; 65,66 associated with the respective hosts 1;2;3, a host being thus assigned to each group of the data resource as master of that group. A lock request to the common data resource is sent to a lock manager (21,22,23) on the host which is the master of the data resource group to be locked, and exclusive control is performed thereto. The hardware overhead for control of access to the resource is thus reduced. The hosts may provide for mutual back-up in the event of failure (Figures 4,5). <IMAGE>
Description
SPECIFICATION
Background of the invention
The present invention relates to a computer system in which a plurality of data processors access a common data resource, and to a control system for efficiently access the data resource while assuring matching thereof.
In a computer system in which a plurality of data processors share a data source such as a file, a so-called exclusive control is effected so that if one data processor is accessing the data resource, the other data processors are prevented from accessing in order to prevent improper data from being used. lpformation for indicating the occupation by a data processor is called lock information. In a system in which a plurality of data processors access the common data resource while they effect the exclusive control on block by block basis of the data resource, data processors are coupled with each other through a communication unit by which the lock information is exchanged. In this system, however, a communication overhead takes place because of the exchange of the lock information.
In another known system, a special control unit for effecting the exclusive control is provided separately from the data processors. In this system, the processing overhead of the data processor can be reduced because the exclusive control is effected by the separate control unit, but the special control unit is required and it may be a bottle neck of the performance and reliability of the entire system.
The above prior art system does not have means for determining the validity of data content in a buffer pool in the data processor. Without such means, the data processor must read necessary data from a file unit which stores the data resource into a buffer each time the data processor accesses to the data resource, and the buffer pool can no longer function as a cache memory.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide an exclusive control system by which a plurality of data processor access a common data resource, which system has less communication overhead and does not need special hardware.
It is another object of the present invention to provide an exclusive control system which selectively inhibits the data resource from being accessed in order to assure matching of the data resource for various failures such as subsystem failure, communication unit failure and data processor failure.
It is other object of the present invention to provide an exclusive control system in which if one or a plurality of data processors fail simultaneously or sequentially, a function which has been performed by a lock manager on the failed data processor can be quickly performed by a lock manager on other data processor.
In accordance with the present invention, the common data resource is logically divided, and a master data processor is assigned to each set of divided data resources. Each data processor has a lock manager for effecting the exclusive control. A lock request to the common data resource is sent to the lock manager on the data processor which is a master for the data resource to be locked, and the exclusive control is effected by the lock manager. An alternate data processor is provided in one set of data resources, and if a trouble occurs in the master data processor, the alternate data processor is operated.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows a block diagram of a typical computer system including the present invention,
Figure 2 shows a block diagram of lock managers 21, 22 and 23 of Figure 1,
Figure 3 shows a matrix for illustrating compatibility of a lock mode,
Figures 4 and 5 show backup systems, and
Figures 6to 12 show flow charts of locklunlock procedures of the lock manager.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Figure 1 shows a block diagram of a typical computer system to which the present invention is applied. In
Figure 1, six subsystems 31-36 operating on three data processors 1, 2 and 3 access common file units 61-66.
The data processors (hereinafter called hosts or host computers) are interconnected through a communication unit 4. Examples of the communication unit 4 are a channel-to-channel coupling adaptor (CTCA), a communication control processor (CCP) and a loop network. Each host computer comprises one operating system 11-13, one lock manager 21-23 and one or more subsystem 31-36. A common data resource is stored in common file units 61-66. The common file units 61-66 are connected to the host computers 1-3, and the subsystems 31-36 access the common data resource through the operating systems 11-13 after they have issued lock requests to the lock managers 21-23 to lock the common data resource. The locking is done block by block. The subsystem is provided in the host computer and it is a control mechanism to control the execution of an application program.Specifically, it is a transaction management system in an on-line system.
Each subsystem 31-36 is provided with a buffer pool 41-46 and a journal file 51-56. Each lock manager 21-23 records log information of the operation of the system in a common system control file 7.
The common data resouce is divided into logical resource groups, and a master host computer is assigned to each of the resource groups. In the present embodiment, the common data resources stored in the common file units 61 and 62 are allocated to a resource group A, the common data resources stored in the common file units 63 and 64 are allocated to a resource group B, and the common data resources stored in the common file units 65 and 66 are allocated to a resource group C. A master of the resource group A is the host 1, a master of the resource group B is the host 2, and a master of the resource group C is the host 3. The division of the resource groups and the allocation of the masters may be made in any manner. For example, one host may be masters of two or more resource groups, or there may be a host which has no master resource group.The number of resource groups and the number of hosts need not be equal. The division of the resource groups and the allocation of the masters relate to a system performance and can be adjusted in accordance with a system characteristic.
It is a transaction which is operated under control of the subsystems that actually issues a lock request. The transaction is assigned with an identifier which is unique in each subsystem. By combining this identifier with an identifier of the subsystem, the transaction can be uniquely identified in the system. Each transaction issues the lock request to a lock manager on the same host computer. The lock request is issued with designation of a lock mode, a resource group and a name of data block required. If the master of the data resource (one data block) to be locked is in its own system, the requested lock manager effects necessary exclusive control, and if the master of the data resource (one data block) to be locked is in other system, the requested lock manager transfers the lock request to the master host computer.The transaction which requests the lock need not know what host computer is the master of the data resource to be locked. As seen from the above description, each lock manager needs only to communicate with the master host computer (OS) of the data resource to be locked and need not communicate with other host computers. Assume that the system comprises n host computers, the common data resource is divided into n groups and each host computer is assigned as a master. If a subsystem on a host computer accesses to all common data resources at an equal probability, an expected number cof times of communication generated for one lock request issued by the subsystem is c#(n-1 )x1/n=1 -1/n and it does not largely depend on n.If the master is not assigned and all lock managers have the same lock information, cn-1 and the communication overhead increases in proportion to n. For the resource in which the host computer to which the subsystem issuing the lock request is the master, no communication takes place. Accordingly, if it is previously known that there is a locality in the access by the subsystem to the common data resource, the communication overhead can be reduced by assigning the master of the common data resource to which the subsystem mainly accesses, to the host computer to which the subsystem belongs.
Figure 2 shows a table configuration of the lock manager 21-23. Asystem control table 100 stores host computer numbers of its own system, chain information of a host control table 110, chain information of a subsystem control table 120 and chain information of a resource control table 130. The host control table 110 stores host status information to indicate whether the host computers are in operation, in failure or in termination status, communication status information to indicate whether communication to the host is permitted or not, or whether synchronization in communication failure recovery is under way or not, the host computer numbers of the hosts, chain information of the subsystem control table 120 of the subsystem which works on the host computer and the host computer number of a backup host.The subsystem control table 120 stores status information of the subsystem to indicate whether the subsystem is in operation or in failure or in termination status, identifiers of the subsystems, chain information of the next subsystem control table, chain information of the backup table, and chain information of the transaction table. The resource control table 130 stores identification names of the resource groups, host computer number of the host computer which effects the exclusive control, status information to indicate that the host computer which effects the exclusive control is active and in operation, chain information of a resource Hash table, chain information of an updating synchronization map, and chain information of a reserved bit map table.The transaction tables 141-143 store a transaction identifier uniquely assigned in the subsystem, an identifier of the subsystem which assigns the transaction table, chain information of the next transaction table when synonym of the transaction in the subsystem occurs, the number of locks which th transaction has, status information to indicate whether the transaction is in a waiting status or not and whether it is the transaction of its own system or not, and chain information of the lock table assigned at the first lock request of the transaction. For the transaction generated in other host computer, the transaction table is prepared when a lock request is issued to its own host computer. Forthetransaction generated in its own host computer, the transaction table is prepared when the transaction is generated.For the latter case, the transaction table may be prepared when the lock request is issued. The resource Hash tables each 151-153 store chain information of the resource table. The updating synchronization maps 161-163 each comprise N 4-byte (32 bit) entires, where N is a Hash space (a set of Hash values) when Hashing is done by using a resource name as a key. The resource tables 171-175 each store a name of resource to be locked, chain information of the resource table assigned next to the synonym generation, a serial number of a resource group to which the resource belongs, a total number of locks to the resource, a lock mode permitted to the resource, status information to indicate whether the resource is reserved or not, and chain information of the lock table which assigned the resource at the first lock request.
The lock tables 181-186 each store an address of the resource table, chain information of the lock table assigned at the next lock request to the lock request for the resource, chain information of the next lock table in the transaction when two or more lock requests are issued in one transaction, a lock mode at the time of lock request, and status information to indicate whether the lock is in a waiting status or not or in a reserved status or not. The backup tables 191-196 each are a bit sequence table for the Hash space (Hash value) Hashed by using the resource name as a key. The reserved bit map tables 201-203 each are the same as the backup table, that is, a bit sequence table for the Hash space.
The exclusive control means of the lock manager for effecting the exclusive control is explained in detail with reference to the tables of Figure 2. The control means is implemented by a program in the present embodiment, and an embodiment thereof is shown in Figure 6 et seq. For a sake of convenience of explanation, let us assume that the subsystem 31 on the host computer 1 issues a lock request to the lock manager 21.
(1) Lock request to the common data resource belonging to the resource group A (the resource group A is
designated);
Since the master of the data resource to be locked is the host computer 1, no communication takes place.
When the lock manager 21 receives the lock request accompanied with a request lock mode from the subsystem, it searches the resource table 171 by tracing the resource control table 130 and the resource Hash table 151. It checks whether the resource to be locked has been registered as to-be-locked resource. One resource table corresponds to one to-be-locked data resource (one data block in a file). If there is no resource table corresponding to the requested to-be-locked data resource, a new resource table is prepared and it is connected to a chain extending from the resource Hash table. The resource Hash table 151 is a table used to search the resource table by the Hashing method by using the resource name as a key. The lock manager 21 prepares the lock table 181 for the lock request and connects it to a chain extending from the resource table.
The lock table 181 is also connected to a chain extending from the transaction table 141 for the transaction. By those two chains, which data resource of the transaction the lock table corresponds to is indicated. The lock request issued by the subsystem is immediately accepted unless other lock is on the data resource in question on if other lock is on the data resource but the lock mode held in the resource table is compatible with the requested lock mode. The acceptance is made by comparing the lock request mode and the lock mode stored in the resource table. If a lock mode which is not compatible with the requested lock mode exists, the lock request is held unaccepted until the preexisting lock is released. In the present embodiment, fine types of lock modes are used and the compatibility among the modes is shown in a matrix of Figure 3.The modes may be set in other way than that shown in Figure 3.
(2) Lock request to the common data resource belonging to the resource group B:
The lock manager 21 refers to the resource group control table 130 to determine that the master of the data resource to be locked is the host computer 2 and transfers the lock request to the lock manager 22 on the host computer 2 by using a known communication function provided in the operating system 11. When the lock manager 22 receives the transferred lock request, it processes it in the same manner as (1), and when the lock is permitted, it informs the permission to the lock manager 21 on the host computer 1. When the lock manager 21 receives the response, it searches the resource table 173 (or prepares a new resource table if it is not present) by tracing the resource group control table 130 and the resource Hash table 152, and prepares the lock table 184 to connect the chain.It should be noted that the resource table and the lock table for the lock request are doubly set for the lock manager 21 on the same host computer as that of the lock requesting subsystem and the host computer 2 of the master of the resource to be locked. This relates to reconfiguration of the lock information by the backup system. When the subsystem 31 issues the lock request to the common data resource belonging to the resource group C, the operation is the same as that described above.
A method for synchronizing the contents of the buffer pools 41-46 of the subsystems is explained.
Each of the subsystems 31-36 accesses to the common data resource by using the buffer pools 41-46. The data read from the file is temporarily stored in the buffer pools 41-46 and it is utilized by the subsystem. Thus, when the same data is repeatedly used, the access to the file can be omitted. If the data resource (block) to be accessed is present in the buffer pool, the subsystem does not exchange the data with the common file units 61-66 but uses the data in the buffer pool. Only when the data resource (block) to be accessed is not present in the buffer pool, the subsystem exchanges the data with the common file units 61-66. In this manner, the number of times of access to the common file units 61-66 is reduced.However, since each subsystem has its own buffer pool, it may happen, under an environment where the data resource is shared by a plurality of host computers, that the data content in the buffer pool of its own subsystem is not always latest one (the data resource has been updated by other subsystem). The lock managers 21-23 each inform, as response information to the lock request, to the requesting subsystem that the updating was done by the other subsystem (and hence the content of the block in the buffer pool is invalid).As a result, the subsystem accesses the common file units 61-66 not each time but on necessary basis, that is, only when the data resource to be accessed (the block of the requested name) is not present in the buffer pool, or when the data resource to be accessed is present in the buffer pool but the content thereof is invalid because it was updated by the other subsystem.
In order to supply the response information, the lock managers 21-23 each store the updating of the subsystem in the updating synchronization maps 161-163 for the resource group in which its own host computer is the master. Namely, a bit of an area corresponding to the updated resource name is set to "1". In the present embodiment, the updating synchronization map comprises N entries each consisting of four bytes, where N represents a size of the Hash space (a set of Hash values) when the Hashing is done by using the resource name as a key, and it is specified by a system definition. N should be determined in balance of a size of unit of the data resource in which the updating is stored (the smaller the unit is, the more finely is the updating stored) and a size of memory necessary for the updating synchronization map (the smaller the unit of the data resource is, the larger memory is required). One entry is used for the updating control for one block, or one entry is used for the updating control for a plurality of blocks. In the present embodiment, each entry of the updating synchronization map consists of four bytes (32 bits) and each bit corresponds to one subsystem. In the system shown in Figure 1, since six subsystems are in operation, six out of 32 bit in each entry are actually used.When the bit is "1", it means that the content of the data is valid if the subsystem corresponding to the bit has the data resource having the Hash value for the entry, in the buffer pool of its own system.
A method for using the updating synchronization map is explained in detail. When the lock manager accepts the lock request from the subsystem, it sets "1" in the bit corresponding to the subsystem in the entry of the updating synchronization map corresponding to the Hash value of the data resource to be locked. If the lock request is a lock to update the data resource (in the present embodiment, the lock in the SU, PU or EX mode), all other bits in the entry are set to "0". For example, when the lock of the first subsystem is accepted, a bit pattern of the entry is "100000". If the lock of the second subsystem is accepted, the bit pattern is changed to "010000". To the lock requesting subsystem, the status of the bit corresponding to the subsystem immediately before the bit manipulation is conveyed as response information.In the above example, if the lock of the first subsystem is accepted when the bit pattern is "100000", "1" is responded to the first subsystem and the bit pattern is changed to "010000". Then, if the lock of the first subsystem is accepted, "0" is returned. If the bit is "1", it means that other subsystem has not updated the data resource during a time period from the previous lock request to the current lock request by the lock requesting subsystem to the data resource. If the data resource is present in the buffer pool'of the lock requesting subsystem, the content thereof is valid. If the bit is "0", it means that other subsystem may have updated the data resource, and the lock requesting subsystem must read the content of the data resource from the common file unit.In this manner, the data resource may be shared by the subsystems without sacrificing the effect of buffering by the subsystems.
Measures to failures in the system are now discussed. The failures include; (1) failure of the subsystem (2) failure of the communication unit (3) failure of the host computer (including failure of the operating system)
The operations of the lock managers for the above three failures are explained. Even if the failure is generated, the operation of the system can be efficiently carried out while matching of the data resources is maintained.
The operation for the subsystem failure is first explained. When the subsystem fails, the data content may include inconsistency because the access to the common data resource is not completed. Accordingly, it is necessary to inhibit the access to the common data resource locked by the failed subsystem and hold the inhibit state until the data recovery is completed. Referring to the tables used by the lock manager 21 shown in
Figure 2, the operation when the subsystem 31 fails is explained. The operation of other lock manager and the operation when other subsystem fails are similar. In the present embodiment, the failure of the subsystem is detected by a subsystem monitor and it is informed to the lock manager. The subsystem monitor is provided to detect the activation and termination of the subsystem and abnormal termination of the subsystem.
When the lock manager 21 detects the failure of the subsystem 31, it searches the lock tables 181, 182, 184 and 185 corresponding to the locks held by the subsystem 31 by tracing the subsystem control table 120, and the transaction tables 141 and 142. The lock reserve status is set in the lock table, and the reserve status and the reserved lock mode are recroded in the resource tables 171, 172, 173 and 174 corresponding to the data resources to be locked. If the lock request which is not compatible with the reserved lock mode is issued from other subsystem to the data resource which is in the reserve status, the lock manager 21 rejects the lock request. The lock reservation is released when the subsystem 31 recovers and completes the data recovery and reports it to the lock manager 21.Since the lock of the reference system (SR, PR in Figure 3) does not update the data resource, there is no inconsistency of the data resource. Thus, in the subsystem failure and the data processor failure, the lock of the reference system is not reserved but opened. If the subsystem fails in the above processing, the access to the common data resource which may include inconsistency can be
inhibited.
The operation of the lock manager when the communication unit fails is explained. For a sake of convenience of explanation, let us assume that the communication between the host computer 1 and the host computer 2 is disabled by the failure of the communication unit 4. Because the host computer 2 (which is disabled to communicate) rejects the lock requests from the subsystems 31 and 32 in its own host computer 1 to the data resource (belonging to the resource group B) which is the master, the lock manager 21 inhibits the access to the resource group B to the subsystems 31 and 32. The lock manager 21 also reserves the locks which the subsystems 33 and 34 on the host computer 2 (which is disabled to communicate) hold to the data
resource belonging to the resource group A, and rejects the lock request which is not compatible with the
reserved lock.In the communication unit trouble, the subsystem which has acquired the lock is in operation, and it may refer to the data resource by the acquired lock to update other data resource. In order to maintain the security of the data resource, the lock of the reference system is also reserved.
The access inhibit status and the lock reserve status are released when the failure of the communication unit is recovered. When the cornmunication between the host computer 1 and the host computer 2 is restored, the lock manager 21 and the lock manager 22 each reports the transaction status of its own system to the other.
For example, if the transaction corresponding to the transaction table 141 is completed during the failure of the communication unit, the transaction releases the reserved locks 181 and 184, but the release of the lock 184 is not communicated to the host computer 2 which is the master of the data resource 173 to be locked.
When the communication recovers, the transaction status is reported to each other so that the lock manager 22 recognizes the end of the transaction 141 and releases the table corresponding to the lock table 184 from the table of its own system. In this manner, the shift of the tables between the lock managers is. avoided. Thus, when the communication unit fails, the access from the subsystem is inhibited to prevent the inconsistency from being generated in the data resource, and the matching of the lock managers can be recovered as the failure is recovered.
Finally, the operation of the lock manager when the host computer fails (including the failure of the operating system). When the host computer 1 fails, the lock manager 21 cannot operate and the subsystems 33,34, 35 and 36 on other host computers cannot access to the data resource (belonging to the resource group
A) in which the host computer 1 is the master. It is not desirable from the standpoint of availability of the data resource that the unaccessable state lasts until the failure of the host computer 1 is recovered. Accordingly, one or more spare lock managers (backup systems), are provided for the lock manager 21 (original system), and when the lock manager 21 is disabled, the backup system functions as the master of the resource group A so that the access to the data resource to the resource group A can be continued.The backup system to the original system may be arbitrarily selected. The backup system is designated by the system definition and the order of the system definition corresponds to the order of backup for the original system. For example, the lock managers 22 and 23 are defined in the host control table in this order as the backup systems to the lock manager 21, and when the lock manager 21 is disabled, the master of the resource group A shifts to the lock manager 22 if it is in operation, and shifts to the lock manager 23 if the lock manager 23 is disabled and the lock manager 23 is in operation.In the present embodiment, it is assumed that the backup systems of the host computer 1 are defined in the order of the host computers 2 and 3, the backup systems of the host computer 2 are defined in the order of the host computers 3 and 1, and the backup systems of the host computer 3 are defined in the order of the host computers 1 and 2. Accordingly, if the host computers 2 and 3 are in operation and the host computer 1 fails, the exclusive control to the resource group A is effected by the lock manager 22 on the host computer 2.
It should be noted that when the lock manager 22 contemplates to perform the function of the master of the resource group A, it must have the same information as the lock information which the lock manager 21 has controlled when it was disabled. As described above, when the host computer which is the master of the resource to be locked is different from the host computer with which the subsystem operates, the lock information held by the subsystem has the same lock information in the lock managers on the both computers. In the above example, the lock information given to the data resource belonging to the resource group A for subsystems 33 and 34 are held by the lock managers 21 and 22, and the lock information given to the data resource belonging to the resource group A for the subsystems 35 and 36 are held by the lock managers 21 and 23.The lock manager 22 communicates with the lock manager 23 to reconfigure the lock information given to the data resource belonging to the resource group A for the subsystems 33, 34,35 and 36. However, if the lock manager 23 fails simultaneously with the lock manager 21, the lock information cannot be reconfigured. Thus, the following two means are provided to reconfigure the lock information.
Whether one of the two means is used, or both are used or none of them is used, that is, the backup for the master is not provided, is determined by a system manager beforehand in accordance with a characteristic of the system.
The first means is explained below. This means transfers the exclusive control information under processing to one or more backup system lock managers, exclusive control information for one transaction processed in the subsystem at a time to buffer the exclusive control information. In order to reduce the communication overhead due to the backup of the exclusive control information, "journal acquisition" is reported to the lock manager before the log information is acquired by the journal file unit in the transaction of each subsystem, and when the "journal acquisition report" or "a collective unlock request" issued at the end of transaction is received by the lock manager, the lock manager transfers the exclusive control information acquired to that time at a single transfer. The explanation is made with reference to Figures 2 and 4.For the sake of convenience of explanation, let us assume that the transaction of the subsystem 31 on the host computer 1 acquires the lock of the common data resource of the resource groups A and B and then reports the journal acquisition and requests the collective unlock to the lock manager 21. (The journal is log information of the transaction of the subsystem. The update log of the common data resource is also stored in the journal file unit and used by the subsystem for the recovery after the failure of the subsystem and as the recovery information after the failure of the file unit.) When the lock manager 21 receives the report of the journal acquisition, it searches the lock tables 181 and 184 by tracing the subsystem control table 120 and the transaction control table 141 of Figure 2. The resource tables 171 and 173 are searched from referring to the lock tables 181 and 184, memory location of the backup information is Hashed by using the resource name as a key, and the backup tables 191 and 192 corresponding to the resource group are searched. The backup information in which the bits corresponding to the Hash values of the backup tables 191 and 192 are set to "1" are transferred to the backup system lock managers 22 and 23 as shown in Figure 4. When the lock manager 21 receives the collective unlock request, it searches the table and transfers to the backup system lock managers 22 and 23 the backup information in which the bits corresponding to the Hash values are set to "0".
The lock managers 22 and 23 updates the backup tables 191 and 192 of its own system from the backup information. By the present means, the backup system lock managers 22 and 23 hold the lock information necessary for the backup in synchronism with the lock manager 21 of the original system. In the present system, the lock information to be backed up may be only the lock request of the updating system (SU, PU, EX in Figure 3), or the data resource in which the backup system is the master may not be transmitted because it is stored in the backup system lock manager.
A method for using the backup tables 191-196 and the reserve bit tables 201-203 is now explained. When the computer system 1 fails, the backup system lock managers 22 and 23 record the backup tables 191-196 of their own systems into the common system control file 7 of Figure 1. (The information is succeeded when the exclusive master is transferred to the computer system before the subsystems 31 and 32 of the failed computer system 1 recover.) Since the lock manager 23 is in operation, the lock manager 22 informs it to the lock manager 23 in order to transfer the exclusive master controlled by the lock manager 21 to its own system.
When the lock manager 23 receives the message, it temporarily reserves the lock request to the resource group A and sends to the lock manager 22 the acquired lock information relating to the resource group A, and waits for the reception of the end of transfer message from the exclusive master. (As to a lock request relating to the source group A which is waiting for acquisition of lock in the lock manager 23, the lock request is cancelled and again issued to a new exclusive master after completion of the exclusive master change.) The lock manager 22 reconfigures the lock information relating to the resource group A acquired from the lock manager 23 and logically ORs the bit sequences of the backup table 191 to the resource group A of the subsystem 31 and the backup table 194 to the resource group A of the subsystem 32, and stores the result into the resource bit map table 201 of the resource control table 130. Then, it writes own master number into the source control table 130 of the resource group A, records the updated information and the contents of the backup tables 191-196 into the common system control file, and sends the end of exclusive master transfer message to the lock manager 23. When the lock manager 23 receives the end of exclusive master transfer message, it updates the exclusive master information of the resource group A of its own system, releases the temporary reserve status and then issues the lock request relating to the resource group A to the lock manager 22 on the computer system 2.When the lock manager 22 receives the lock request relating to the resource group A, it Hashes by using the resource name as a key and checks whether the bit on the reserve bit map table 201 of the resource group A corresponding to the Hash value is "1" or "0". If it is "1", it means the reserve status and it is informed to the requesting unit. If the bit is "0", the exclusive control is performed. In the multi-trouble of the computer system, the sending lock may be reserved by the above procedure, and the exclusive master may be transferred to continue the exclusive control.
The second means is explained with reference to Figure 5. This means reads the journal which is the log of the transactions of the subsystems from the journal file to specify the data resource being updated in the transaction of the subsystem (the resource which requests the lock for updating), and reconfigures the lock information. The access to the reconfigured lock information from other subsystems is inhibited because the data resource may include inconsistency due to the updating.
In Figure 5, since the lock manager 23 of the backup system is in operation, when the lock manager 22 of the backup system detects the failure of the host computer 1, it reads the journal files 51 and 52 of the subsystems 31 and 32, collects the data resource relating to the resource group A being updated by the subsystems 31 and 32, and prepares and reserves the resource table corresponding to the data resource and the lock table. When the lock information is to be reconfigured, it is necessary to read the journal file of the subsystem to set the table, but no extra overhead is necessary in the normal subsystem operation. In order for the lock manager 22 to read the journal file units 51 and 52, it is necessary that the journal file units 51 and 52 are connected to the host computer 2. This is not shown in Figure 1.
Figures 6to 12 show flow charts of a lock manager control program which implements the lock/unlock means by the lock managers 21-23 described above.
Each transaction issues the lock request to the lock manager on the same host computer. The lock manager responds thereto by starting the lock processing program and searches for the transaction table corresponding to the lock requesting transaction as shown in Figure 6, and if there is no such table, it prepares a new table (step 601). It searches for the resource group table to which the data resource to be locked belongs (step 602).
If the status of the resource group table is in the process of exclusive master transfer (step 603), the termination of the exclusive master transfer is monitored (step 604). If it is not in the process of the exclusive master transfer, the exclusive master information in the resource group table is checked, and if the master of the data resource to be locked is of its own system (step.605), the resource table for the data resource to be locked is searched, and if there is no such table, a new table is prepared (step 606). If the data resource to be locked has been reserved on the reserve bit map table (step 607) or it has been reserved on the data resource table and is not compatible with the lock mode (step 608), error return/error response is sent, and if it is compatible, a lock table is prepared to set a chain (step 609).
In Figure 7, if the lock is immediately permitted (step 701), the entry of the updating synchronization map is searched and the bit status is set in the response area (step 703). If the lock is not permitted, the lock request stands by until it is permitted (step 702). The bit in the updating synchronization map entry corresponding to the lock requesting subsystem is set to "1" (step 704). If it is the lock request for updating, the bits in the updating synchronization map entry corresponding to other subsystems are cleared (steps 705,706).
In Figure 8, if the lock request is from the subsystem on other system, a normal response is sent to the requesting subsystem (steps 801,802). On the other hand, if it is not the lock request to the data resource whose master is not in its own system, the lock request is transferred to the master of the data resource to be locked (Figure 9) and a response is monitored (step 901). If the response indicates that the exclusive master is being transferred (step 902), the process returns to the step 604 of Figure 6. If the exclusive master is not being transferred and the response is not a normal response, the error return is sent to the requesting subsystem (step 903).If it is the normal response, the resource table corresponding to the data resource to be locked is searched, and if there is no such table, a newtable is prepared (sten 904). A lock table is prepared and a chain is set (step 905).
A flow of unlock is explained with reference to Figure 10. When the transaction is over, the unlock processing is started. The lock table corresponding to the lock to be released and the resource group table are searched (step 1001). If the exclusive master is being transferred, the termination of the transfer of the exclusive master is monitored (steps 1002,1003), and if the exclusive master is not being transferred and if there is a backup system shown in Figure 4 and the request is not the collective unlock from the subsystem of its own system, it is Hashed by using the resource name in the resource table as a key to prepare the backup information for lock information to be cancelled based on the unlock request, which is stacked in the buffer (steps 1004, 1005). If the lock is for the data resource whose master is in its own system, the lock table is released (steps 1005, 1006). As shown in Figure 11, if it is the release of the last lock for the data resource (step 1101),the resource table is released (step 1102). If it is not the release of the last lock, and if there is a waiting lock request to the data resource (step 1103), the waiting is released for the waiting lock request which is permitted by the unlock request (step 1104). If it is the collective unlock request (step 1105), and if all locks of the transactions which are subject of the collective lock request are not released (step 1106), the process branches to the step 1001 of Figure 10 where the next lock is released.If the all locks of the transactions have been released and there is a backup system of Figure 4 and the collective unlock request is from its own subsystem (step 1107), the backup information stacked in the buffer is informed to the backup system in the step 1006 of Figure 10.
In Figure 12, the unlock request is transferred to the host of the master of the corresponding data resource (step 1201) and the lock table is released (step 1202). If it is the release of the last lock to the data resource (step 1203), the resource table is released (step 1204).
In accordance with the present invention, the sharing of the data resource by a plurality of data processors is attained with a small communication overhead which does not significantly depend on the number of data processors. Accordingly, an economic and high performance shared data base system can be structured.
Claims (8)
1. A computer system having a data resource and a plurality of data processors for issuing lock requests to said data resource, comprising:
a lock manager provided for each of said data processor for performing exclusive control for the lock request to a portion of said data resource, and
communication means for connecting said data processors and transferring the lock request among said lock managers.
2. A computer system according to Claim 1 wherein said lock manager processes by itself the lock request to a portion of said data resource to which the ~ k manager performs the exclusive control, issued from the data processor in which the lock manager is provided, and transfers to other lock manager through said communication means the lock request to a portion of said data resource to which said other lock manager performs the exclusive control, issued from the data processor in which the lock manager is provided.
3. A computer system according to Claim 1 wherein said lock manager includes lock memory means for storing lock status of each area of a portion of said data resource to which the lock manager performs the exclusive control, said area having a predetermined amount of memory and means for comparing the lock status stored in said lock memory means with the issued lock request to determine whether the lock request is to be permitted or not.
4. A computer system according to Claim 1 wherein said lock request includes designation of type of lock, and said lock manager permits the lock request if the lock status indicates that the portion is not locked and the type of lock which is compatible with the lock designated by the lock request.
5. A computer system according to Claim 3 wherein each data processor includes buffer means for storing the portion of said data resource whose lock request is permitted, said lock manager includes buffer control means for indicating one of the buffer means which most recently stores, said area for each said area of the portion of said data resource to which the lock manager performs the exclusive control, and the data processor uses the portion of said data resource stored in said buffer means when the lock request is permitted and said buffer means into which the portion of said data resource to be locked by the lock request is stored is the buffer means stored in said buffer control means, and otherwise accesses said data resource.
6. A computer system according to Claim 3 wherein each of said data processors processes a plurality of transactions, issues the lock request at the start of the transaction and issues a request to release the lock at the end of the transaction, and said lock manager responds to the request to release the lock to erase the lock status stored in said lock memory means.
7. A method of exclusive control of a data resource in a computer system having the data resource and a plurality of data processors for issuing lock requests to said data resource, comprising the steps of:
determining whether the lock request is to a predetermined portion of said data resource;
if the lock request is so in the determining step, performing the exclusive control to the lock request, and
if not, transferring the lock request to other data processor.
8. A computer system substantially as hereinbefore described with reference to, and as illustrated in, the accompanying drawings.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP61039219A JPS62197858A (en) | 1986-02-26 | 1986-02-26 | Inter-system data base sharing system |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| GB8703191D0 GB8703191D0 (en) | 1987-03-18 |
| GB2188177A true GB2188177A (en) | 1987-09-23 |
| GB2188177B GB2188177B (en) | 1989-11-08 |
Family
ID=12547027
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB8703191A Expired GB2188177B (en) | 1986-02-26 | 1987-02-12 | Computer system having data resource and a pluralyt of data processors sharing the data resource and a control method therefor |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JPS62197858A (en) |
| GB (1) | GB2188177B (en) |
Cited By (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2637998A1 (en) * | 1988-10-14 | 1990-04-20 | Nec Corp | System for processing of locking |
| EP0366432A2 (en) * | 1988-10-25 | 1990-05-02 | Hewlett-Packard Company | Method and apparatus for bus lock during atomic computer operations |
| EP0366433A2 (en) * | 1988-10-25 | 1990-05-02 | Hewlett-Packard Company | Multiprocessor interlock |
| EP0405861A2 (en) * | 1989-06-30 | 1991-01-02 | Digital Equipment Corporation | Transferring data in a digital data processing system |
| FR2655168A1 (en) * | 1989-10-20 | 1991-05-31 | Digital Equipment Corp | MECHANISM FOR NOTIFICATION OF FAILURE. |
| EP0457308A2 (en) * | 1990-05-18 | 1991-11-21 | Fujitsu Limited | Data processing system having an input/output path disconnecting mechanism and method for controlling the data processing system |
| US5167022A (en) * | 1988-10-25 | 1992-11-24 | Hewlett-Packard Company | Multiprocessor bus locking system with a winning processor broadcasting an ownership signal causing all processors to halt their requests |
| US5210865A (en) * | 1989-06-30 | 1993-05-11 | Digital Equipment Corporation | Transferring data between storage media while maintaining host processor access for I/O operations |
| US5239637A (en) * | 1989-06-30 | 1993-08-24 | Digital Equipment Corporation | Digital data management system for maintaining consistency of data in a shadow set |
| US5247618A (en) * | 1989-06-30 | 1993-09-21 | Digital Equipment Corporation | Transferring data in a digital data processing system |
| US5432929A (en) * | 1992-09-09 | 1995-07-11 | International Business Machines Corporation | Storage subsystem having a modifiable key-lock |
| EP0679994A2 (en) * | 1994-04-28 | 1995-11-02 | International Computers Limited | High availability computer system |
| US5546536A (en) * | 1989-06-30 | 1996-08-13 | Digital Equipment Corporation | Log for selective management of specific address in a shadow storage system |
| WO1998043163A1 (en) * | 1997-03-24 | 1998-10-01 | Emc Corporation | An agent-implemented locking mechanism |
| EP0911731A2 (en) * | 1997-10-24 | 1999-04-28 | Digital Equipment Corporation | Order supporting mechanisms for use in a switch-based multi-processor system |
| EP1117190A2 (en) * | 2000-01-13 | 2001-07-18 | Nec Corporation | Dual transmission spreading system for CDMA communication apparatus |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5392397A (en) * | 1992-03-30 | 1995-02-21 | International Business Machines Corporation | Command execution system for using first and second commands to reserve and store second command related status information in memory portion respectively |
| US7013305B2 (en) | 2001-10-01 | 2006-03-14 | International Business Machines Corporation | Managing the state of coupling facility structures, detecting by one or more systems coupled to the coupling facility, the suspended state of the duplexed command, detecting being independent of message exchange |
| JP3910997B2 (en) | 2003-07-02 | 2007-04-25 | 聰 山竹 | Image database system |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0049423A2 (en) * | 1980-10-06 | 1982-04-14 | International Business Machines Corporation | Multiprocessor system |
| EP0081056A2 (en) * | 1981-11-27 | 1983-06-15 | International Business Machines Corporation | A data processing network having a distributed data file access control |
| EP0147295A2 (en) * | 1983-12-26 | 1985-07-03 | Fujitsu Limited | Data processing system including a plurality of multiprocessor systems |
| EP0166984A2 (en) * | 1984-06-29 | 1986-01-08 | International Business Machines Corporation | A multiprocessor resource locking system and its method of operation |
-
1986
- 1986-02-26 JP JP61039219A patent/JPS62197858A/en active Pending
-
1987
- 1987-02-12 GB GB8703191A patent/GB2188177B/en not_active Expired
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0049423A2 (en) * | 1980-10-06 | 1982-04-14 | International Business Machines Corporation | Multiprocessor system |
| EP0081056A2 (en) * | 1981-11-27 | 1983-06-15 | International Business Machines Corporation | A data processing network having a distributed data file access control |
| EP0147295A2 (en) * | 1983-12-26 | 1985-07-03 | Fujitsu Limited | Data processing system including a plurality of multiprocessor systems |
| EP0166984A2 (en) * | 1984-06-29 | 1986-01-08 | International Business Machines Corporation | A multiprocessor resource locking system and its method of operation |
Cited By (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2637998A1 (en) * | 1988-10-14 | 1990-04-20 | Nec Corp | System for processing of locking |
| US5167022A (en) * | 1988-10-25 | 1992-11-24 | Hewlett-Packard Company | Multiprocessor bus locking system with a winning processor broadcasting an ownership signal causing all processors to halt their requests |
| EP0366432A2 (en) * | 1988-10-25 | 1990-05-02 | Hewlett-Packard Company | Method and apparatus for bus lock during atomic computer operations |
| EP0366433A2 (en) * | 1988-10-25 | 1990-05-02 | Hewlett-Packard Company | Multiprocessor interlock |
| US5175829A (en) * | 1988-10-25 | 1992-12-29 | Hewlett-Packard Company | Method and apparatus for bus lock during atomic computer operations |
| EP0366433A3 (en) * | 1988-10-25 | 1991-08-21 | Hewlett-Packard Company | Multiprocessor interlock |
| EP0366432A3 (en) * | 1988-10-25 | 1991-08-21 | Hewlett-Packard Company | Method and apparatus for bus lock during atomic computer operations |
| US5210865A (en) * | 1989-06-30 | 1993-05-11 | Digital Equipment Corporation | Transferring data between storage media while maintaining host processor access for I/O operations |
| EP0405861A2 (en) * | 1989-06-30 | 1991-01-02 | Digital Equipment Corporation | Transferring data in a digital data processing system |
| US5239637A (en) * | 1989-06-30 | 1993-08-24 | Digital Equipment Corporation | Digital data management system for maintaining consistency of data in a shadow set |
| US5247618A (en) * | 1989-06-30 | 1993-09-21 | Digital Equipment Corporation | Transferring data in a digital data processing system |
| EP0405861A3 (en) * | 1989-06-30 | 1991-11-27 | Digital Equipment Corporation | Transferring data in a digital data processing system |
| US5546536A (en) * | 1989-06-30 | 1996-08-13 | Digital Equipment Corporation | Log for selective management of specific address in a shadow storage system |
| FR2655168A1 (en) * | 1989-10-20 | 1991-05-31 | Digital Equipment Corp | MECHANISM FOR NOTIFICATION OF FAILURE. |
| US5548743A (en) * | 1990-05-18 | 1996-08-20 | Fujitsu Limited | Data processing system with duplex common memory having physical and logical path disconnection upon failure |
| EP0457308A3 (en) * | 1990-05-18 | 1992-11-04 | Fujitsu Limited | Data processing system having an input/output path disconnecting mechanism and method for controlling the data processing system |
| EP0457308A2 (en) * | 1990-05-18 | 1991-11-21 | Fujitsu Limited | Data processing system having an input/output path disconnecting mechanism and method for controlling the data processing system |
| US5432929A (en) * | 1992-09-09 | 1995-07-11 | International Business Machines Corporation | Storage subsystem having a modifiable key-lock |
| EP0679994A2 (en) * | 1994-04-28 | 1995-11-02 | International Computers Limited | High availability computer system |
| EP0679994A3 (en) * | 1994-04-28 | 1997-07-30 | Int Computers Ltd | High availability computer system. |
| WO1998043163A1 (en) * | 1997-03-24 | 1998-10-01 | Emc Corporation | An agent-implemented locking mechanism |
| US5913227A (en) * | 1997-03-24 | 1999-06-15 | Emc Corporation | Agent-implemented locking mechanism |
| EP0911731A2 (en) * | 1997-10-24 | 1999-04-28 | Digital Equipment Corporation | Order supporting mechanisms for use in a switch-based multi-processor system |
| EP0911731A3 (en) * | 1997-10-24 | 2000-08-09 | Compaq Computer Corporation | Order supporting mechanisms for use in a switch-based multi-processor system |
| EP1117190A2 (en) * | 2000-01-13 | 2001-07-18 | Nec Corporation | Dual transmission spreading system for CDMA communication apparatus |
| EP1117190A3 (en) * | 2000-01-13 | 2004-02-18 | Nec Corporation | Dual transmission spreading system for CDMA communication apparatus |
| US6813239B2 (en) | 2000-01-13 | 2004-11-02 | Nec Corporation | Dual transmission spread processing circuit system for CDMA communication apparatus |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2188177B (en) | 1989-11-08 |
| JPS62197858A (en) | 1987-09-01 |
| GB8703191D0 (en) | 1987-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| GB2188177A (en) | Computer system for sharing a data resource | |
| US7376651B2 (en) | Virtual storage device that uses volatile memory | |
| US8032492B2 (en) | Simultaneous activation of virtual devices | |
| US5151988A (en) | Intersystem data base sharing journal merge method | |
| US7809887B2 (en) | Computer system and control method for the computer system | |
| US5604863A (en) | Method for coordinating executing programs in a data processing system | |
| US7149787B1 (en) | Apparatus and method for mirroring and restoring data | |
| US5737600A (en) | Method and system for log management in a coupled data processing system | |
| US4480304A (en) | Method and means for the retention of locks across system, subsystem, and communication failures in a multiprocessing, multiprogramming, shared data environment | |
| US5781910A (en) | Preforming concurrent transactions in a replicated database environment | |
| US5423037A (en) | Continuously available database server having multiple groups of nodes, each group maintaining a database copy with fragments stored on multiple nodes | |
| JP2894676B2 (en) | Asynchronous remote copy system and asynchronous remote copy method | |
| US6370626B1 (en) | Method and apparatus for independent and simultaneous access to a common data set | |
| CN101567805B (en) | Method for recovering failed parallel file system | |
| US6807642B2 (en) | Cluster system having virtual raid, computer for the cluster system, and parity calculation method in the cluster system | |
| US20070043726A1 (en) | Affinity-based recovery/failover in a cluster environment | |
| US6438654B1 (en) | Castout processing for duplexed cache structures | |
| WO1997045790A1 (en) | Method and apparatus for independent and simultaneous access to a common data set | |
| JPS62105247A (en) | Management of data base system | |
| JP3222125B2 (en) | Database sharing method between systems | |
| JP2685530B2 (en) | How to manage shared data | |
| JPS62145349A (en) | Intersystem data base sharing system | |
| EP0049423B1 (en) | Multiprocessor system | |
| US7428558B2 (en) | Persistent restore of virtual devices | |
| Brereton | Management of replicated files in a UNIX environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PCNP | Patent ceased through non-payment of renewal fee |
Effective date: 20020212 |