JP2834036B2 - Lock controller - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a lock controller for a shared resource in transaction processing, and more particularly to a lock controller for releasing a deadlock caused by locking of a shared resource by re-executing a transaction.

[0002]

2. Description of the Related Art In a conventional lock controller, a shared resource is locked in two modes, a shared mode in which the shared resource is shared and an exclusive mode in which the shared resource is exclusively used. The exclusive control is performed according to the exclusive control rule shown in FIG. 2 (for the conventional lock controller, see, for example, Mamoru Maekawa “Software execution / development environment”, Section 4.7 “Extension to shared resources”).

A typical transaction processing program using a conventional lock controller reads one record from a file, updates a part of the fields in the record, and writes the record to update the record.

In this situation, a record to be read is locked in the shared mode, and the same record is locked in the exclusive mode when the record is written.
Such an operation of re-locking the resource locked in the shared mode in the exclusive mode in the same transaction in the same transaction is called lock upgrade.

For example, in a file reading process, it is unclear whether the file will be updated later at the time of reading. Therefore, it is common to lock in the shared mode at the time of reading and lock in the exclusive mode at the time of writing. Lock upgrade occurs. If the transaction processing program is divided into a plurality of subroutines for control table and resource locking, the calling routine locks the resource locked in shared mode in exclusive mode in the called routine. Locking also requires a lock upgrade.

Upgrading locks on records that are not updated frequently is not a problem, but upgrading locks on records that are updated frequently (such records are called hot spots) causes deadlock. . As shown in FIG. 3, when three transactions 41, 42 and 43 read the hot spot 44 and lock it in the shared mode at close time, and issue a lock request in the exclusive mode to write the record, as shown in FIG. Since this is a lock request in the exclusive mode for the resource locked by the other transaction in the shared mode, the three transactions wait for each other and a deadlock occurs.

[0007] It is said that most deadlock causes for relational databases are due to lock upgrades to this hot spot (eg, Jim Gray, Andreas Reuter).
"TRANSACTION PROCESSING"
Section 7.8.2 "Update Mode"
Locks ").

In the transaction processing, when a deadlock occurs in the lock controller, the deadlock is notified to the transaction monitor, and the transaction monitor releases the deadlock by suspending one or more transactions included in the deadlock. Is generally used.

The suspended transaction is re-executed by the transaction monitor after rolling back resources such as a database accessed by the transaction.

[0010]

The conventional lock controller described above has a disadvantage that the deadlock is not efficiently released.

That is, when N transactions read a hot spot and lock it in a shared mode in a close time and make a lock request in an exclusive mode to write a record, the number of times the transaction is interrupted and re-executed is determined. The estimate is as follows.

In order for the lock in the exclusive mode to succeed, the transaction must be locked by a transaction other than one transaction that locks in the exclusive mode. -One transaction must be interrupted. The interrupted N-1 transactions are re-executed, locked in the shared mode as before the interruption, and issued a lock request in the exclusive mode to read the hot spot and write the record. In order to release the deadlock, N-2 transactions must be suspended again. Therefore, when N transactions cause a deadlock due to a lock upgrade for a hot spot, the number of transaction interruptions is 1 + 2 +... + (N−2) + (N−
1) = N (N-1) / 2 times.

The process of suspending a transaction involves a lot of overhead because it is necessary to roll back resources accessed until immediately before the transaction was suspended. In particular, when N transactions cause a deadlock due to a lock upgrade for a hot spot, N (N-1) / 2 transaction suspension processes are required, and a lock upgrade is performed with a conventional lock controller. There is a problem in the efficiency of releasing the deadlock caused by the above.

[0014]

SUMMARY OF THE INVENTION A lock controller according to the present invention is a lock controller for performing a lock control when a resource locked in a shared mode in the same transaction is locked in an exclusive mode again. A lock wait queue for queuing a lock request from the transaction program, and taking out the lock request from the lock wait queue, executing the lock if the lock request is executable, and executing the lock in a deadlock state with respect to a resource. If the lock request is made in the exclusive mode and the resource is already locked in the shared mode, the lock request is deleted from the lock waiting queue and a deadlock notification is output. And the transaction monitor receiving the deadlock notification. A mode converter that converts the lock request in the shared mode from the transaction processing program instructed to the row into the lock request in the exclusive mode and registers the lock request in the lock wait queue. A lock request in the exclusive mode is performed in response to a lock request in the shared mode due to execution, so that a lock request after re-execution is successful and deadlock release efficiency is improved.

[0015]

Next, the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram of a lock controller according to an embodiment of the present invention, which is an example of application to transaction processing. The lock controller 1 identifies a lock request source transaction by a transaction identifier, identifies a resource to be locked by a resource identifier, and has a lock mode of a shared mode and an exclusive mode.

When the transaction monitor 10 receives the transaction processing request, it allocates a new transaction identifier and activates the transaction processing program 2 14. Further, when the transaction processing program 2 ends 16, the resource commit processing is performed, and after issuing the lock release request 11 and the reset request 12 to the lock controller 1, the transaction processing is ended.

The started transaction processing program 2 designates the transaction identifier given by the transaction monitor 10 and the resource identifier corresponding to the resource to be locked according to the processing of the resource to be accessed, and the lock request 8 in the exclusive mode and the shared mode. Is issued to the lock controller 1.

The shared mode lock request 9 is transmitted to the mode converter 3
To the deadlock memory 4 by the mode converter 3.
A check is made to see if a deadlock has been registered.
If registered, the lock mode is changed to the exclusive mode, and the lock request is registered in the lock waiting queue 5,
If not registered, it is registered in the lock waiting queue 5 as a lock request in the shared mode. On the other hand, the exclusive mode lock request 8 is registered in the direct lock waiting queue 5 as an exclusive mode lock request.

The deadlock storage 4 is a database in which a set of a transaction identifier and a resource identifier is set as one entry, and a set of a transaction identifier and a resource identifier specified as a parameter of a lock request by the mode converter 3 is registered. Is inspected. Each entry of the deadlock storage 4 indicates that a deadlock has occurred in the exclusive mode lock request 8 for the transaction identified by the transaction identifier to upgrade the lock on the resource identified by the resource identifier. I have.

The lock request registered in the lock wait queue 5 is determined when the lock request is registered in the lock wait queue 5 and when the lock processor 7 is activated when the lock release request 11 is requested. And the lock process is performed.

The lock processor 7 manages the lock state of the resource corresponding to the resource identifier by using a database having a set of the resource identifier, the transaction identifier, and the lock mode as one entry, and performs a lock process according to FIG.

In other words, the exclusive mode lock searches for an entry having the resource identifier to be locked and can be locked when the lock is not performed by another transaction, so that lock processing is performed, and the shared mode lock specifies the resource identifier to be locked. The search is performed for the entry having the lock, and when the lock in the exclusive mode by another transaction is not performed, the lock is possible, so that the lock processing is performed.

In the lock processing, a set of a resource identifier, a transaction identifier, and a lock mode is registered in a buffer (not shown) in the lock processor, and in the case of lock in the shared mode, the transaction identifier is stored in the shared transaction storage 6. And a resource identifier. After completion of the lock processing, the completion of the lock is notified to the transaction processing program 2.

The transaction storage 6 is a database for registering that the transaction processing program 2 has locked the resource corresponding to the resource identifier in the shared mode, and intends to upgrade the lock when a deadlock is detected. It is referred to from the lock processor 7 in order to determine whether or not it has occurred.

The lock processor 7 periodically checks the lock waiting queue 5 and, if there is a lock request that has been waiting for a predetermined time or more, a deadlock occurs in the resource for which the lock request is waiting. The lock requests that have been waiting for a certain period of time or more are taken out one by one from the lock wait queue 5, and the lock requests are canceled except for the last lock request, and the transaction identifier of the lock request source is used as a parameter. A deadlock notification 13 is sent to the transaction monitor. Since the last lock request can be locked, the lock is executed. The lock waiting queue 5 is inspected again, and if there is a lock request that has been waiting for a predetermined time or more, it is determined whether or not lock is possible. If the lock is not possible, cancellation of the lock request due to the deadlock described above is repeated.

For example, in the case of FIG.
One exclusive mode lock request is canceled, and then the exclusive mode lock request of transaction 42 is canceled. At this point, the exclusive mode lock request of the transaction 43 can be processed, and the deadlock is released.

When the lock request canceled by the deadlock is in exclusive mode and the transaction identifier and the resource identifier are registered in the shared transaction storage 6 (when the same resource is already locked in shared mode) Registers the transaction identifier and the resource identifier in the deadlock storage 4.

When the transaction monitor 10 receives the deadlock notification 13, after performing the rollback of the resource, it issues the lock release request 11, deletes the lock request, and executes the transaction processing program 2 again.

The lock release request 11 deletes the lock request requested by the transaction from the lock waiting queue 5 and the database of the lock processor 7 using the transaction identifier as a key.

On the other hand, the transaction processing program 2
Is completed 16 after the commit processing performed by the transaction monitor 10, the reset request 12 shares the database entry corresponding to the lock request requested by the transaction with the deadlock storage 4 using the transaction identifier as a key. Delete from transaction storage 6.

In the transaction processing program 2 based on the restart 15 after the notification 13 of the deadlock is made to the transaction monitor 10, the lock request 9 in the shared mode for the resource that caused the deadlock last time is as follows:
The request is changed to the exclusive mode request by the mode converter 3 referring to the deadlock storage 4 and is queued in the lock waiting queue 5.

When the exclusive mode request is successful, the shared lock request from the other transaction processing program waits, so that the subsequent exclusive mode lock request 8 also succeeds and the deadlock event is released.

In a normal lock in which a deadlock is not registered in the deadlock storage 4, the lock in the shared mode performs the lock processing in the shared mode, so that the operation is the same as that of the normal lock processor.

In transaction processing to which the lock controller of the present invention is applied, when N transactions read a hot spot and lock in a shared mode at close time, and issue a lock request in an exclusive mode to write a record. The number of times the transaction is suspended and re-executed is estimated as follows.

In order for the lock in the exclusive mode to succeed, the transaction must be locked by a transaction other than one transaction that locks in the exclusive mode. -One transaction must be interrupted.

The interrupted N-1 transactions are re-executed and the hot spot is read and locked in the shared mode in the same manner as before the interruption, but the lock processor processes the lock request in the exclusive mode in the same manner as before the interruption. Deadlock does not occur for lock requests in update mode.

Therefore, when N transactions cause a deadlock due to a lock upgrade to a hot spot, the number of transaction interruptions is:
(N-1) times.

[0039]

As described above, according to the present invention, when a deadlock occurs in a lock of a resource whose lock is being upgraded, the transaction is interrupted and the exclusive mode is changed in spite of the shared mode. Therefore, the lock in the shared mode or the lock in the exclusive mode from another transaction is waited in the lock waiting queue, so that the lock after re-execution is successful and the deadlock is released efficiently (the number of re-executions is N ( N-1) / 2 times to N-1 times).

[Brief description of the drawings]

FIG. 1 is a block diagram showing an embodiment of a lock controller according to the present invention.

FIG. 2 is a diagram showing an exclusive control rule according to the present invention.

FIG. 3 is an explanatory diagram of occurrence of deadlock.

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 Lock controller 2 Transaction processing program 3 Mode converter 4 Deadlock storage 5 Lock wait queue 6 Shared transaction storage 7 Lock processor 10 Transaction monitor

Continuation of the front page (56) References JP-A-4-241034 (JP, A) JP-A-4-369056 (JP, A) JP-A-5-46415 (JP, A) JP-A-5-204678 (JP) JP-A-5-216728 (JP, A) JP-A-5-334160 (JP, A) JP-A-6-103142 (JP, A) JP-A-6-208497 (JP, A) 7-78093 (JP, A) JP-A-7-84851 (JP, A) (58) Fields investigated (Int. Cl. ⁶ , DB name) G06F 12/00 535

Claims (1)

(57) [Claims] 1. A lock controller for performing lock control when a resource locked in a shared mode in the same transaction is locked again in an exclusive mode.
A lock wait queue for queuing a lock request from the transaction program; and taking out the lock request from the lock wait queue, executing the lock if the lock request is executable, and executing the lock in a deadlock state with respect to a resource. If the lock request has been made in the exclusive mode and the resource has already been locked in the shared mode, the request is deleted from the lock waiting queue and a deadlock notification is output. The lock request in the shared mode from the transaction processing program instructed to be re-executed by the control of the transaction monitor receiving the deadlock notification is converted into the lock request in the exclusive mode and registered in the lock waiting queue. With a mode converter,
By performing lock in the exclusive mode in response to the lock request in the shared mode due to re-execution of the transaction in which the deadlock has occurred, the lock request after the re-execution is successful, and the efficiency of deadlock release is improved. A lock controller.