JPH09251413A - Lock controller and method therefor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To detect the deadlock that is caused when the data are operated in a data base system without giving any load to the data base system nor making a user interrupt the processing under execution. SOLUTION: If a lock acquisition means 302 is unable to immediately acquire a lock against the lock acquisition request given from a user, the means 302 starts a deadlock decision means 305. The means 305 checks a standby user table 306 to decide whether a deadlock occurs when the lock acquisition request is waited for. When the deadlock occurs, the acceptance of the lock acquisition request is rejected. When no deadlock occurs, a fact that the user who issued the lock acquisition request is waiting for the opening of lock is notified to the table 306 of the user who acquires the lock to a lock table 307 of the data 314. Then a deadlock is detected.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a lock operation method for data on a database system which is one of record storage systems on a computer, and more particularly to a method for detecting a deadlock.

[0002]

2. Description of the Related Art A database system is one of the record keeping systems on a computer. The database system stores data in a disk, which is a database storage area, and many users can access the data to obtain information or store information when needed. In the database system, when referring to or updating the accumulated data, it is possible for a plurality of users to perform the updating at the same time.

When updating or the like is performed, the updated data may be lost. In order to prevent such a situation, the database system exclusively manages the operation of other users on the data being updated or referred to. Lock control means is provided as means. That is, when the user operates the data, the user locks the data to be operated via the lock control means so that other users cannot operate the data at the same time. Then, when the data operation is completed, the lock of the operation target data is released via the lock control means so that another user can operate the data. As described above, by providing the lock control means and performing the lock operation, it becomes possible to exclusively manage the operation target data.

By providing the lock control means, a plurality of users do not operate the same data at the same time, but on the other hand, a problem of deadlock occurs.
A deadlock is a state in which a plurality of users are waiting for the release of data owned by each other, and the processing cannot be performed because the data cannot be acquired. For example, user A acquires a lock on data a,
When the user B has acquired the lock on the data b, the user B issues a lock acquisition request on the data a, and the user A issues a lock acquisition request on the data b, both users acquire each other. A deadlock occurs because it keeps waiting for the lock to be released on the existing data. When a deadlock occurs, the user's processing cannot continue, so the database system either prevents the deadlock from occurring or detects the deadlock and acquires the lock that causes the deadlock. Cancel the request.

As a technique known as a countermeasure against such deadlock, for example, a deadlock avoidance method based on all lock acquisition requests (Mamoru Maekawa)
"Software Execution / Development Environment", pp.194-19
9, Iwanami Shoten, 1993), Method of avoiding deadlock when requesting lock acquisition (Andrew S. Tanenabaum, Supervised by Saka text, Translated by Teruyo Onishi "MINIX Operating System", pp.161, ASCII Publishing, Heisei 3 Years), deadlock detection method after a certain time has passed after the request was issued (Tohru Shimoda, Nobuyuki Kawana, Riki Inazu)
There are three major technologies disclosed in the literature such as “OpenVMS”, pp.143-146, Kyoritsu Publisher, 1994). The conventional database system selectively employs any one of these techniques.

The deadlock avoidance method based on the all lock acquisition request is a method characterized in that information about all lock acquisition requests is collected before the user issues the lock acquisition request. In this way, the deadlock avoider creates a deadlock graph that gathers all lock acquisition requests that each user will make. When a lock acquisition request is issued from the user, the deadlock avoidance means analyzes the deadlock graph and determines whether a deadlock occurs. When it is determined that the deadlock does not occur, the fact that the user has acquired the lock or issued the acquisition request is recorded in the deadlock graph. When it is determined that deadlock will occur, the deadlock control means does not accept the request.

A deadlock avoidance method at the time of a lock acquisition request is characterized in that the deadlock detection means detects a deadlock and cancels the lock acquisition request every time the user issues a lock acquisition request to data. Is. In this method, when a user issues a lock acquisition request for data, the deadlock detection means updates the deadlock graph. Then, the updated deadlock graph is traced by the deadlock detection means to determine whether or not a deadlock has occurred. When it is determined that a deadlock will occur, the deadlock detection means does not accept the request.

In the deadlock detection method after a lapse of a fixed time after the request is generated, the deadlock detecting means detects the occurrence of the deadlock and cancels the lock acquisition request for the request in which the lock cannot be acquired even after the lapse of the fixed time. It is a method characterized by that. According to this method, the deadlock detection unit determines that there is a possibility of deadlock when the lock cannot be acquired within a certain time after the user issues a lock acquisition request to the data, and the deadlock is detected. Perform detection. When a deadlock is detected, the lock acquisition request from the user causing the deadlock is canceled to eliminate the deadlock.

[0009]

When the deadlock avoidance method based on the all lock acquisition request is used, all the lock acquisition requests issued by each user when the deadlock avoidance means creates a deadlock graph. Previous data information is needed. Considering this to all users, there is a possibility that deadlock will occur between all data, so there is a problem that this condition is difficult to apply to an actual database system.

In addition, when the deadlock avoidance method at the time of the second lock acquisition request is used, when the lock control means cannot immediately execute the lock acquisition even if the user issues the lock acquisition request, the deadlock avoidance means. Has a problem that the database system is overloaded because it updates and holds a complex deadlock graph in which all lock information is filled.

Finally, when the deadlock detection method is used after a fixed time has elapsed after the third request is issued, the deadlock cannot be detected until a fixed time has elapsed after the lock acquisition request is issued. Therefore, there is a problem that the processing of the user is interrupted during that time.

An object of the present invention is to solve the above-mentioned problems, to provide a method for reducing the number of users interrupting the processing, and taking measures against deadlock without imposing a load on the database system.

[0013]

In order to solve the above problems, in the lock control device of the present invention, when a user issues a lock acquisition request to data, lock control is performed to perform operations such as acquisition, release and cancellation of the lock. The means determines whether or not the lock to the data can be acquired by using the lock table that stores the user who acquires the lock, the lock release waiting user, and the release wait start time.

When the lock control means cannot immediately acquire the lock to the data, the deadlock determining means activated by the lock control means and detecting the occurrence of the deadlock determines the lock for each user who has acquired the lock. The deadlock occurrence detection is started using the waiting user table that describes the users waiting for the release of the deadlock.

When the lock acquisition is not completed within a certain time after issuing the lock acquisition request, the timeout canceling means is periodically activated to cancel the lock acquisition request.

According to the above construction, there are the following effects.

After the user issues the lock acquisition request to the data, the lock control means checks whether or not the user acquiring the lock is stored in the lock table of the data of the lock acquisition request. When the user who acquires the lock is not stored, the lock control means can immediately execute the lock acquisition, and thus acquires the lock to the data. When the user who has acquired the lock is stored, the lock control means waits for execution of the lock acquisition immediately, and therefore the lock control means activates the deadlock determination means.

The deadlock determination means examines the waiting user table, and a user who has already acquired the lock to the data releases the other data for which the user who issued the lock acquisition request has acquired the lock. Find out if you are waiting for. If the user is waiting, a deadlock will occur if the user is waiting for the execution of the lock acquisition request. Therefore, the deadlock determination means notifies the user that the deadlock will occur, and the lock acquisition request for the data. To cancel. If not waiting, the deadlock determination means describes in the waiting user table of the user who has acquired the lock to the data that the user waiting to release the lock to the data exists. Thereafter, the deadlock determination means notifies the lock control means that no deadlock occurs, and the lock control means waits for execution of the lock acquisition request.

As described above, after the user issues the lock acquisition request to the data, the deadlock determination means determines that a deadlock has occurred. Therefore, the user who issued the lock acquisition request waits for the lock acquisition execution and performs the processing. No need to interrupt.

Further, when the deadlock decision means makes a deadlock decision, instead of using a deadlock graph containing all lock information, the deadlock decision means waits for each user to release the lock to the data. Since the deadlock detection that can be detected by using the standby user table that is the table in which the user who has written is performed, it is not necessary to check all the lock information, and as a result, the load on the database system can be suppressed.

[0021]

BEST MODE FOR CARRYING OUT THE INVENTION A first embodiment of the present invention will be described below.

FIG. 1 shows that even if the user program 311 issues a lock acquisition request to the data 314, the data 31
A database including a deadlock determination program that determines whether a deadlock occurs by using the standby user table 306 when the lock cannot be acquired immediately because there is a user program 311 that has acquired the lock to 4 It is a figure which shows one Example of a system.

This database system uses data 31
A disk 313 serving as a record storage location of the computer 4, a plurality of computers 309 sharing the disk 313 and connected via a network 310,
User program 3 for issuing a lock acquisition request on 09
11 and the lock management computer 309 that centrally manages the lock acquisition request issued on each computer 309.
A lock communication program 312 that transmits a lock acquisition request issued on each computer 309 as a message
The lock management computer 309 receives the message and analyzes which of the lock acquisition program 302, the lock cancellation program 303, and the lock release program 304 of the lock control program 301 is to be executed, and the lock operation request acceptance program 300, and the lock. A lock acquisition program 302 that executes a lock acquisition request in the management computer 309, and a lock acquisition program 3
The lock table 307 of the data 314 that checks whether 02 can execute the lock acquisition immediately, the deadlock determination program 305 that is started when waiting for the lock acquisition that cannot be executed immediately, and which user program 311 is executed for each user program 311 It is composed of a waiting user table 306 indicating whether or not to wait for the end of processing, and a timeout cancel program 308 for canceling a deadlock that could not be detected by the deadlock determination program 305 by a timeout.

The standby user table 306 has a data name 400 that acquires the lock of each user program 311.
And a user program ID 401 waiting for the lock release of the user program 311 to the data 314.

The lock table 307 has a data name 400
And the user program ID 402 of the user program 311 that has acquired the lock to the data 314, the user program ID 403 that is waiting for the lock release because the lock acquisition request cannot be executed, and the user program 311 that is waiting for the lock start. It consists of time 404.

In the first embodiment, the lock management computer 309 is provided with the standby user table 306, and the user program 311 that cannot immediately execute the lock acquisition request refers to the standby user table 306 until the lock acquisition request can be executed. If it is waiting, determine whether it will be a cause of deadlock.If it is not a cause, wait until the lock acquisition is completed, and if it is a cause, deadlock is executed by not executing the lock acquisition request. The feature is that it can be avoided.

Next, in the above-mentioned database system, the deadlock avoidance processing procedure will be described with reference to the configuration diagram of FIG. 1, the flowcharts of FIGS. 2, 3, 4, and 5 and the table diagrams of FIGS. To do.

When the user executes a write operation or a read operation for data shared by a plurality of users, the user program 311 issues a lock acquisition request for the data 314.

When the computer 309 of the user program 311 which has issued the lock operation request to the data 314 is other than the lock management computer 309, the following processing is executed first. The user program 311 in each computer 309 issues a lock operation request to the data 314, activates each lock communication program 312, and transmits a lock acquisition request to the lock management computer 309 via the network 310. Lock operation request acceptance program 3 of lock management computer 309
00 receives the lock operation request message from the computer 309.

Lock operation request acceptance program 300
Alternatively, the computer 309 that issued the lock operation request
And the lock management computer 309 are the same, the user program 311 analyzes which program of the lock control program 301 is executed. Hereinafter, both cases will be referred to as a lock operation request acceptance program 300.

The lock cancel program 303 called from the lock control program 301 receives the data 314.
Start when the lock acquisition request is issued by the user program 311 but the lock cannot be acquired even when the user program 311 issues a lock cancellation request, or when the lock acquisition request issued by the user program is canceled for other reasons. To be done.

The lock release program 304 called from the lock control program 301 is the user program 3
11 completes the operation on the data 314, and the data 31
Fired when releasing the lock to 4.

The above-mentioned two lock cancel programs 303 and lock release programs 304 are not related to the problem to be solved by the present invention, and therefore will not be described here.

When the lock acquisition program 302 is called by the lock control program 301, the operation is performed in the following procedure.

Lock operation request acceptance program 300
Is performed as follows using the flowchart of the lock acquisition operation shown in FIG.

The lock acquisition program 302 is activated.
(Step 1) The lock acquisition program 302 determines whether or not there is a lock in the lock table 307 of the lock acquisition request destination data 314 (step 2). When there is no lock, the user program I is stored in the lock table 307.
Enter D401 and data name 400, and enter the data 314
To get a lock (step 2). The lock operation request acceptance program 300 is notified of the lock acquisition completion, and the process is terminated (step 1).

When there is a lock, the deadlock judgment program 305 and the timeout cancellation program 30
8 is activated (steps 3 and 4). The timeout cancel program 308 is the lock table 30.
It is checked whether the release waiting time of 7 has exceeded the timeout limit time (step 6), and if it has passed (step 6), a timeout cancellation notice is sent to the lock acquisition program 302 (step 4) and the processing ends. Alternatively, when the lock acquisition program 302 notifies the lock acquisition completion (step 4), the process ends.

The deadlock judgment program 305 started above judges from the waiting user table 306 whether or not the user program 311 which has acquired the lock to the data is waiting for the user program 311 which issued the lock acquisition request. (Step 5). When waiting, a deadlock occurrence notification is sent to the lock acquisition program 302 (step 3).

When not waiting, the user program 311 issuing the lock acquisition request is entered in the standby user table 306 of the user program 311 acquiring the lock to the lock acquisition request destination data 314, and (step 5) Notify the lock acquisition program 302 that no deadlock has occurred (step 3).

When the lock acquisition program 302 receives a deadlock occurrence notification from the deadlock determination program 305 (step 3), it sends a deadlock occurrence notification to the lock operation request acceptance program 300 and ends (step 1). .

If the notification from the deadlock judgment program 305 is that a deadlock has not occurred, the notification from the timeout cancel program 308 is waited for. If the notification is a timeout cancellation, the lock operation request acceptance program 300 is notified of the timeout (step 1) and the process ends (step 3).

When the lock on the lock table 307 is released while waiting for the timeout cancel notification, the lock acquisition program 302 acquires the lock on the lock table 307, and (step 2) the timeout cancel program 308 and the lock operation request acceptance. Program 3
00 is notified of lock acquisition completion (step 4, step 1), and the process ends.

In the above embodiment, the user program 3
When the lock acquisition program 302 cannot immediately execute the lock acquisition request issued by 11, the deadlock determination program 305 uses the standby user table 306 in the management computer 309 instead of the deadlock graph that is generally used. Lock judgment is performed. Instead of managing the information in which the user programs 311 waiting for the end of processing of the user programs 311 are collectively stored as the standby user table 306 in the management computer 309, as shown in FIG. A standby user table 315 may be provided in the program 311 in which the user program ID 401 waiting for the end of the user's processing and the data name 400 are recorded.

Further, the lock of the lock acquisition request destination data 314 is the same as the user program 311 which has acquired the lock of the data 314 as the transmission destination of the message to be transmitted when the lock cannot be acquired immediately. All the user programs 311 waiting for
The user program 31 that acquires the lock on the data 314 only waits for the execution of the lock acquisition, and then starts in the order in which the lock on the data 314 can be acquired next.
When setting 1 or waiting for the execution of lock acquisition, when it becomes the order in which the next lock of the data 314 can be acquired in the user program 311 waiting for the lock release, the lock of the data 314 is acquired. An example in which the acquired user program 311 is used is also conceivable.

In the above-described embodiment, the lock management computer that centrally manages the lock acquisition request is determined to perform the lock management. However, for each data in the disk, the computer that manages the data is determined as the master computer of the data. The management of the lock operation request for the data may be all performed in the computer. In the second embodiment, an embodiment in which locks are distributed and managed will be described.

In the second embodiment, as shown in FIG. 7, the user program 311 in each computer 309 issues a lock operation request to the data 314, and the master computer 309 of the data 314 issues the lock operation request to the user program 311. When different from the computer 309 of
The lock communication program 312 is activated respectively, and the lock acquisition request is transmitted to the master computer 309 of the data 314 of the lock acquisition request destination via the network 310. The lock operation request acceptance program 300 of the master computer 309 receives the lock operation request message from the computer 309.

The lock operation request program 300 analyzes which program of the lock control program 301 is executed. Here again, only the case of the lock acquisition program 302 will be described.

In the second embodiment, when the lock acquisition program 302 cannot immediately acquire the lock to the lock table 307, the lock acquisition program 302 activates the deadlock determination program 305 (step 3),
The deadlock determination program 305 checks the standby user table 315 of the user program 311 that issued the lock acquisition request managed in the lock operation request acceptance program 300 (step 5), and acquires the lock acquisition request destination data 314. It is determined whether or not the user program 311 that is currently executing waits for the end of the processing of the user program 311 that issued the lock acquisition request.

When not waiting, since deadlock has not occurred, the completion of lock acquisition is waited for. At that time, the deadlock determination program 305 activates the lock communication program 312 (step 6), and the lock table 30
User program 311 that has acquired the lock to 7
The user program 311 that issued the lock acquisition request
Sends a message that it is waiting for the lock in the lock table 307 to be released. The user program 311 having received the message manages the information in the standby user table 315 in each user program 311.

Since deadlock occurs while waiting, the deadlock determination program 305 notifies the lock operation request acceptance program 300 of the occurrence of deadlock (step 3).

Also, the lock of the lock acquisition request destination data 314 is already released to the user program 311 that has acquired the lock to the data 314 as the transmission destination of the message to be transmitted when the lock cannot be acquired immediately. All the user programs 311 waiting for
When waiting for the execution of the lock acquisition, only the user program 311 which has begun to wait in the order in which the lock for the data 314 can be acquired next becomes the user program 311 which acquires the lock for the data 314, or waits for the execution of the lock acquisition. In this case, in the user program 311 waiting for the release of the lock, when it becomes the order in which the lock for the data 314 can be acquired next, the example in which the user program 311 that acquires the lock for the data 314 is used Can also be considered.

When a lock cannot be acquired immediately and waiting for the release of the data of the lock acquisition request destination, it is determined whether a deadlock condition occurs, and then it is determined whether or not to wait. Deadlock can be avoided.

[0053]

As described above, since the deadlock determination means determines that a deadlock has occurred after the user issues the lock acquisition request to the data, the user who issued the lock acquisition request must wait for the lock acquisition execution and interrupt the processing. Disappears.

When the deadlock decision means makes a deadlock decision, instead of using the deadlock graph containing all the lock information, the user waiting for each user to release the lock to the data. Since the deadlock detection that can be detected using the standby user table that is the table in which is written, it is not necessary to check all lock information, and as a result, the load on the database system can be suppressed.

[Brief description of drawings]

FIG. 1 is a configuration diagram of a database system that centrally manages lock information and a standby user table in a lock management computer.

FIG. 2 is a flowchart of a lock operation request acceptance program in FIG.

FIG. 3 is a flowchart of a lock acquisition program in FIG.

FIG. 4 is a flowchart of a deadlock determination program in FIG.

5 is a flowchart of a timeout cancel program in FIG.

FIG. 6 is a configuration diagram of a database system in which lock information is centrally managed in a lock management computer and a standby user table is managed for each user program.

FIG. 7: Determines a master computer that manages data,
Data lock information is a block diagram of a database system managed in the computer.

FIG. 8 is a configuration diagram of a standby user table.

FIG. 9 is a configuration diagram of a lock table.

[Explanation of symbols]

300 ... Lock operation request acceptance program, 301 ...
Lock control program, 302 ... Lock acquisition program, 303 ... Lock cancel program, 304
... lock release program, 305 ... deadlock determination program, 306 ... user waiting program, 307 ... lock table, 308 ... timeout cancel program, 309 ... computer, 310 ... network, 311 ... user program, 312 ... lock communication program, 313 ... Disc, 31
4 ... data, 315 ... standby user table managed in the lock operation request acceptance program.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Inventor Hideo Takahashi 12 stock companies at 890 Kashimada, Sachiku-ku, Kawasaki City, Kanagawa Prefecture Hitachi, Ltd. 12 shares of Hitachi, Ltd. information and communication development headquarters at number 890 (72) Inventor Miyoko Kawamura 12 shares of Hitachi, Ltd. information and communication development headquarters at 890 Kashimada, Saiwai-ku, Kawasaki, Kanagawa

Claims (1)

[Claims] 1. A computer that centrally manages lock information, a lock table that stores a user who has acquired a lock, a lock release waiting user, and a release wait start time.
A lock control means for receiving a lock operation request from the user and performing the operation using the lock table, and a user and data waiting for the release of the lock for each user who has acquired the lock are described. The waiting user table recorded in the computer that manages the information and the lock acquisition program that is started when the lock acquisition program cannot immediately execute the lock acquisition operation, and detects the occurrence of deadlock using the standby user table Deadlock determination means for entering the user waiting to release the lock to the data, and timeout canceling means that is periodically activated to cancel the request after a certain time has elapsed after issuing the lock acquisition request. A lock control device comprising: