JPH08235043A - Cooperative distributed system - Google Patents

Abstract

PURPOSE: To provide a cooperative distributed system which can correctly and smoothly process the transactions and can always assure the consistency of the data bases. CONSTITUTION: Plural processors 1a, 1b, 1c... are connected together via a communication network 2 and receive the transactions through terminals 3 to process them in a distributive way. If the processor 1a receives a transaction, the tentative updating instructions are given to other processors 1b, 1c... having the data bases 16 that should be updated by the reception of transaction of the processor 1a. These updating instructions are received by the processors 1b, 1c... as the journals 18, and the committing instructions are sent to these follower processors 1b, 1c... respectively. Each of these follower processors updates its data base 16 based on the contents of the tentative updating instruction. If one of follower processors has a fault like a system down, etc., this faulty processor acquires the tentative updating instruction of transaction from the journal of the processor 1a and performs the correct updating of its data base 16 after the fault is eliminated.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates generally to online database processing such as processing for depositing or transferring money to a bank account online, and processing for booking or issuing ticket for an airline ticket. Improvement of technology for completing transaction processing accurately and smoothly in a collaborative distributed system in which a plurality of processing devices connected by buses, channels, etc. divide the database and jointly handle distributed transactions It is about.

[0002]

2. Description of the Related Art For example, the process of depositing or transferring money to a bank account online is actually sending a request message from the terminal to the host, accessing the database on the host to process the database, and then sending from the host to the terminal. It consists of a series of processes such as returning a response message. These processes are collectively online
It constitutes a logical unit of database processing, and this logical unit is called a "transaction".

A transaction changes the contents of the database, but the contents of the database after the change must be consistent with meaning having a correct meaning for the user. So the transaction is
It must not remain in a half-finished state, either completed or not processed at all.

As one mode of the online database processing system, there has been proposed a cooperative distributed system in which a plurality of processing devices connected by a communication line divides a database and is responsible for the distributed processing of transactions in a coordinated manner. This collaborative distributed system offers cost reduction, accident risk distribution, and system expansion / contraction flexibility compared to the most common system in which one large mainframe centrally processes databases. Excellent in terms.

However, in this type of distributed system, since a transaction includes database processing in a plurality of processing devices, the database processing in the transaction processing is consistent across a plurality of processing devices, that is, one It is necessary to avoid the situation where one device has updated its database but another device has not. As a transaction processing method therefor, N. J. G
The two-phase commit method devised by Ray is known.

In this two-phase commit method, a transaction is divided into two phases, a temporary update and an actual update. When a terminal issues a transaction request, one processing device accepts this. First, in the temporary update phase, the processing device that accepts the transaction (hereinafter referred to as the main device) inquires of the processing device (hereinafter, referred to as the slave device) that is in charge of the database to be updated whether or not the update is possible. Then, the slave device returns a reply to the master device as to whether the update is possible. As a result, only when all the slaves have returned an updatable response, the actual update phase is entered, and the master sends a commit (that is, transaction completion) instruction to the slaves, and The respective databases are actually updated on the slave device that received the commit instruction, and then the update completion message is returned from the slave device to the master device.

By the processing consisting of the above two phases, the commit instruction is issued and the actual updating of the database is performed only when all the processing devices for distributed processing of the transactions can update the database.

[0008]

However, the conventional two-phase commit method has some problems as follows.

First, since it is necessary to communicate at least four times between the main device and the slave device as described above, a communication overhead of a length that cannot be ignored occurs. for that reason,
The processing speed of the entire system becomes low.

Also, since the transaction processing proceeds while following the procedure of sending a message from the master device to the slave device and returning a response to the message from the slave device to the master device as described above, during the transaction process. There is also a problem that when a failure such as blocking occurs in any of the processing devices, the processing of all the processing devices is stopped at that point. One method of solving this is to cancel the processing and move to the next processing when the processing is stopped for a certain period of time or more, but in any case, the processing speed of the entire system decreases.

Further, after entering the actual update phase and issuing a commit instruction, even if one of the processing devices fails in the actual update, it is no longer possible to stop the actual update or set back recovery for another processing device. Since it is not possible to give an instruction, there is also a problem that the actual update is executed in another processing device, and as a result, the consistency of the database cannot be guaranteed.

As described above, the two-phase commit method is
It is not completely satisfactory for accurate and smooth transaction processing.

Further, the conventionally known cooperative distributed system has the following problems in addition to the problem of the two-phase commit method.

First, in the conventional system, the main device and the slave device are fixedly determined. Therefore, the plurality of processing devices cannot freely operate as the main device or the slave device according to circumstances.

Therefore, a first object of the present invention is to ensure that transaction processing can be performed correctly and smoothly in a cooperative distributed system, and the consistency of a database is always guaranteed.

A second object of the present invention is to provide a flexible collaborative distributed system in which a plurality of distributed processing devices can freely function as a master device and a slave device.

[0017]

The present invention provides a novel improvement in a collaborative distributed system in which a plurality of processing units capable of communicating with each other divide resources and receive them, and collaboratively process transactions in a distributed manner. To do. In the system of the present invention, at least one processing device of the plurality of processing devices is
Can be the main device for accepting transactions,
Other processing devices can be slave devices for distributed processing of accepted transactions.

The main device has update information issuing means for issuing update information indicating update contents of the resource to be updated in the transaction to the slave device which is in charge of the resource to be updated. In addition, either the main device or the slave device
It has a journal in which all the update contents of the update information issued by the main device are recorded together with the transaction identifier. Further, each of the slave devices specifies, based on the update information, the actual update means for updating the resource respectively managed by the slave device and the past transaction for which the update by the actual update means has failed, and the update information corresponding to the specified transaction is specified. And a recovery means for updating the resource based on the updated information ordered from the journal.

[0019]

In the system of the present invention, the main device that receives a transaction first issues update information indicating the update contents of the resource to the slave device that performs distributed processing of the transaction. Here, all the update contents indicated by the update information issued from the main device are acquired as a journal together with the transaction identifier, and held in any place in the system.

Each slave device updates its resource based on the update information issued by the master device. In that case, each slave device identifies the transaction later when resource update fails in any transaction process,
The updated contents related to the transaction are ordered from the above journal. Then, the resource is correctly updated based on the acquired update information.

Therefore, in the master device, even if the slave device does not know whether or not the slave device has correctly updated, in each slave device, the resources are recovered so as to have the correct updated contents. Resource consistency is ensured across all devices. Moreover, since the master device does not need to be aware of the success / failure of updating the slave device, the number of communications between the master device and the slave device is reduced, the communication overhead is shortened, and the dependency of each device is reduced. A situation in which a failure such as blocking that occurs in one device causes the other device to stop is reduced.

In the preferred embodiment, each of the plurality of distribution devices has an update information issuing means, a journal, an actual updating means, and a recovery means so that each of the plurality of distribution devices can be either a master device or a slave device. are doing.

Further, in a preferred embodiment, each device has a journal recording update information issued by each device as a main device. Therefore, the accuracy of the journal is guaranteed.

Further, in a preferred embodiment, each device records exclusive control means for locking each resource to be updated before updating and unlocking after updating, and lock and unlock history of each resource. It has a lock / unlock log. Then, the exclusive control means can lock and unlock for each minimum accessible information unit (for example, record) of the resource. Therefore, when a part of a certain resource is locked by a certain transaction, that part is the minimum unit of access, so access restrictions for other transaction processes are minimized, and as a result, the parallel processing performance of transactions is improved. To do.

Further, in the preferred embodiment, each device identifies the transaction related to the update failure by referring to the lock / unlock log of each resource. Therefore, each device can independently execute the recovery process independently of the other devices.

[0026]

1 is a block diagram showing the overall configuration of an embodiment of a cooperative distributed system according to the present invention. As shown in FIG. 1, a plurality of distributed processing devices (hereinafter, referred to as servers) 1a, 1b, 1 for cooperatively processing distributed transactions.
are connected via a communication network (for example, LAN) 2. Further, the communication network 2 includes a large number of terminal devices 3
a, 3b, 3c ... Are connected. Terminal devices 3a, 3
b, 3c ... Are those using, for example, a workstation or a personal computer, and exchange messages relating to transactions with the servers 1a, 1b, 1c ... Through the communication network 2. Typically, the terminal device 3
A, 3b, 3c ... Send a transaction request from the user to any of the servers 1a, 1b, 1c.

The servers 1a, 1b, 1c ... Include the same components, and execute transaction processing in cooperation with each other. Which server 1a, 1b, 1c ...
Can also be a master device that accepts a transaction requested from a terminal, and can also be a slave device that performs distributed processing of a transaction accepted by another server.

FIG. 1 mainly shows the configuration of the first server 1a. As shown, which server 1a, 1
b, 1c ... Also, the communication manager 11, the business processing program 12, the distributed resource synchronization processing unit 13, the database management unit 14, the resource management unit 15, the storage unit (database) 16,
A memory table / file unit 17 and a journal unit 18 are provided.

The communication manager 11 is for communicating with the terminals 3a, 3b, 3c ... And other servers through the communication network 2.

The business processing program 12 processes the business of this system, that is, executes a specific transaction processing.

The distributed resource synchronization processing unit 13 cooperates with the business processing program 12 to perform local processing of transactions in the server concerned, processing for global distributed processing by other servers, and transaction failures. The processing for recovery is performed.

The database management unit 14 manages the regional database 16 which the server handles. The database 16 stores a set of records that the server should directly manage.

The resource management unit 15 manages a local memory table / file 17 that the server handles.

In this specification, the database 16 and the memory table / file 17 are collectively referred to as "resource".

The journal 18 chronologically records all the changes to be made (regardless of whether they are actually added) to the resources of the server and other servers in all the transaction processes accepted by the server. It was recorded as a record. In other words, the journal 18
All changes to all resources in the system that should occur upon completion of all transactions accepted by the server are recorded in time series. Therefore, in distributed processing of a certain transaction, even if a database fails in a certain server and the update fails, the database is correctly updated again by referring to the journal 18 of the server that accepted the transaction later. It becomes possible.

The operation in this configuration is performed by the first server 1
An example will be described in which a is the master device and the other servers 1b, 1c ... Are slave devices.

In the server 1a, the communication manager 11
Receives a message of a transaction issued by the terminal 3a from the communication network 2 and guides it to the business processing program 12. The business processing program 12 is the terminal 3
The processing of the transaction is started based on the message issued by a.

In this transaction processing, the business program 12 roughly performs the following three operations. First, the distributed resource synchronization processing unit 13 instructs the database management unit 14 and the resource management unit 15 to update the local database 16 and the memory table / file 17 which the server 1a handles. Secondly, through the distributed resource synchronization processing unit 13, the other servers 1b, 1
The update instruction for the local resources of c ... Is transmitted to the communication network 12. Thirdly, the server 1a and the other servers 1b, 1c ... Which should be performed in the transaction processing.
The contents of all the updates for the resources are written in the journal 18 through the distributed resource synchronization processing unit 13.

In the other servers 1b, 1c, ... Which are slave devices, the communication manager 11 receives the commit instruction from the server 1a, which is the main device, from the communication network 2 and passes it to the distributed resource synchronization processing unit 13. Each distributed processing synchronization processing unit 13 performs an update process on each database 16 and memory table / file 17 based on the update instruction.

In the above operation, the server 1 which is the main device
a does not care whether or not the other servers 1b, 1c ... As slaves have correctly executed the update as instructed, and considers that the update has been executed, and when the above three operations are completed, the terminal 3
Send a message to the effect that transaction is completed.

Here, if any of the slaves,
If a resource fails and cannot be updated correctly, only the resources of the slave device will remain in the state before the update, and the resources of other devices will be updated, resulting in inconsistent resource contents. It will be. But in this case,
After the failure is recovered, the slave device retrieves the update history relating to the transaction from the journal 18 of the master device, and refers to this to forcibly perform correct update again. This will ensure consistency of resource content.

FIG. 2 is a block diagram showing the above-mentioned operation and the function of each section in more detail.

As shown in the block of the server 1a, which is the main device, the business processing program 12 includes a main part (hereinafter, AP main part) 20 and an access part (hereinafter, AP).
21). AP main part 20,
The core part of the transaction processing shown in the flowchart is performed, and the AP access unit 21
In this transaction processing, access processing to the database 16 and the memory table / file unit 17 is handled.

The distributed resource synchronization processing unit 13 includes a global transaction management unit (hereinafter referred to as GTM) 22 and a local transaction management unit (hereinafter referred to as LTM) 23. The GTM 22 manages processing for global resources including the server concerned and other servers in transaction processing, and the LTM 23
Manages the processing of local resources of the server.

The distributed resource synchronization processing unit 13 also includes two logs for performing exclusive control regarding the resources of the server, that is, a lock log 24 and an unlock log 25.

The database 16 is the database 1
The update image log 26 for recording the update contents added to 6 in time series is provided. Further, the memory table / file unit 17 includes an update image log 27 for recording the update contents added to the memory table / file unit 17 in time series. Each of these update image logs 26 and 27 records a local update history, whereas the journal 18 includes a global update history including all updates to the resources of not only the server concerned but also other servers. This is a record of the update history.

In the above configuration, when the AP main part 20 of the business processing program 12 of the server 1a receives a message issued from a certain terminal, it starts the transaction processing requested by the message (step S201), A transaction start instruction is sent to the GTM 22 of the distributed resource synchronization processing unit 13. GTM 22 generates a transaction identifier for that transaction.

Next, the AP main section 20 issues to the GTM 22 a lock instruction for exclusive control (instruction of prohibiting access by other transaction processing) for all resources to be accessed in the system. (Step S202). On the other hand, the GTM 22 is the server 1a.
A lock command for a resource in the LTM of the server 1a
23, and the other servers 1b, 1c ...
The lock command for the resources in the server is sent to the LTMs 23 of the other servers 1b, 1c ... Through the communication network 2. Upon receiving the lock command, the LTM 23 of each server acquires lock information for the resource to be locked in the lock log 24 together with the transaction identifier. As a result, in the lock log 24 of each server, which record (or memory table or file) in the resource of each server is locked (access prohibited) for which transaction process is recorded.

Next, the AP main section 20 issues to the GTM 22 a temporary update instruction for all resources (database 16 and memory table / file section 17) to be updated (steps S203, S204). The provisional update instruction includes information on the update content regarding all resources to be updated. This update content information may be a set of a plurality of accesses from the AP access unit 21 to the database, in which case the AP main unit 20 can call the set collectively. In this case, the temporary update command held in the memory and acquired in the journal 18 is a batch call command for the access set. The GTM 22 temporarily holds this temporary update instruction in the memory, and then issues a temporary update command to the resource of the server 1a to the AP access unit 21.
Through the communication network 2 to the database management unit 14 and the resource management unit 15 and the temporary update command for the resources of the other servers 1b, 1c.
It is sent to the database and resource management units 14 and 15 of each server 1b, 1c ... Through the access unit 21. The database and resource management units 14 and 15 of each server have a database 16 and a memory table / file unit 17 respectively.
A temporary update command is issued to.

If any failure occurs in the process up to the temporary update, the transaction is rolled back (backward recovery), and the state of each part is returned to the state before the transaction.

On the other hand, if the temporary update process is successful, then the AP main part 20 of the server 1a issues an actual update (commit) instruction to all resources to be updated to the GTM 22 (step S205). Then GTM22
First, based on the temporary update instruction stored in the memory in the previous temporary update process, the update content regarding all resources to be updated is recorded in the journal 18. Next, GTM22
The LTM 23 of the server 1a and other related server 1
The commit command is transmitted to the LTM 23 of b, 1c, .... Then, the LTM 23 of each server sends the commit command to
Each database management unit 14 and resource management unit 15
Through the database 16 and the memory table / file unit 17. As a result, the actual update is performed in each of the database 16 and the memory table / file unit 17, and when the actual update is successful, the update content is updated in each update image log 26,
Recorded at 27.

When the actual update of each resource is successful, each LTM 23 obtains information (unlock information) indicating that the updated resource is unlocked in the unlock log 25. The unlock log 25 is associated with the lock log 24 so as to form a pair.

When the commit process is completed, the server 1
The AP main unit 20 of a returns a message indicating that the transaction has been completed to the terminal, whereby one transaction process ends.

By the way, in the above commit process, when a failure occurs in a certain resource and the actual update fails, the unlock log 25 is not acquired for that resource, and therefore, the lock log 24 remains even after the transaction process ends.
Exists by itself, that is, remains locked. Therefore, for locked resources,
Access is prohibited in the subsequent transaction processing, and the state before the failure occurred is retained.

However, with respect to the resource in which the failure has occurred, after the failure is removed, the recovery processing can be performed to forcibly correct it as follows. That is, first, the lock / unlock logs 24 and 25 are searched to identify the transaction at the time of failure occurrence. Next, the server that has become the main device in the transaction processing when the failure occurs is requested to send the information regarding the transaction in the journal 18. As described above, since the correct update content in each transaction process is recorded in this journal 18, based on the correct update content,
Correctly update the resource again. If other transactions that require access to the resource have occurred after the failure occurred, those other transactions are rolled back at the lock stage, so the recovery process does not There is no need to consider, and it is sufficient to re-update only the transaction at the time of failure.

As described above, even if a failure occurs in any of the resources and the update cannot be performed temporarily, the forced recovery processing after the failure is eliminated causes all the resources to be substantially updated. There will always be a consistent state.

Moreover, in each transaction processing, the master device, after sending the commit instruction to the slave device, regards it as a transaction completion regardless of the actual success or failure of the commit in the slave device. Can be quickly moved to. In addition, since the master device does not care about the success or failure of the commit in the slave device, the number of communications between the master device and the receiver device can be the same as in the conventional two-phase.
Less than the commit method. As a result, the communication overhead is reduced, and even if blocking occurs in a certain slave device, the operation of the entire system does not stop, so that the operation of the entire system becomes fast and smooth.

As already described, when a resource fails, the failed part is kept in the locked state until the recovery process is performed, so that access in the subsequent transaction process is prohibited. Therefore, if the granularity of exclusive control (lock / unlock) is large, the subsequent transaction processing is greatly affected, which is not preferable. Therefore, it is desirable that the granularity of exclusive control is set to a record unit, which is the minimum unit of access.

FIG. 3 shows one typical system configuration example adopted in the system of the present invention. As illustrated, a plurality of servers 300a, 300b ... Are connected in parallel by a communication network. Each of the servers 300a, 300b ... Can be a main device. For example, if applied to a bank transaction processing system, the servers 300a, 30
0b ... is placed in each store of the bank, and the transactions (deposit, refund,
It can be the main device for payment (eg transfer). Also,
In this system configuration, there is no vertical relationship between the servers 300a, 300b ... Therefore, for example, expansion of the system in which servers are added according to the increase in traffic.
Can be easily reduced.

FIG. 4 shows another system configuration example that can be adopted in the present invention. This is a connection of a plurality of servers 400a, 400b, 400c ... With a hierarchical structure. For example, when applied to a bank system, the server 400a at the top layer is the device of the head office, other servers 400b, 4
00c ... is a branch device, and transaction processing closed at each branch is individually performed by the branch server, and processing related to the head office can be distributed processing in cooperation with the branch and head office servers. Such a system configuration is suitable for building a large-scale system. In this case, there is an advantage that the system can be scaled up / down independently of the other layers.

By the way, in the above-mentioned embodiment, each server holds all journals related to transactions processed by each server as a main unit, but it is not always necessary to do so. For example, one or more specific servers in the system may hold all journals on behalf of them, or a dedicated server for journal management may be provided. In this case, since it is necessary to send the information that is the source of the journal, such as a temporary update instruction, from the server that does not hold the journal to the server that holds the journal, the accuracy of the journal cannot be guaranteed if there is a communication failure or the like. . However, on the other hand, since the journals are collectively managed, it is convenient to use the journals during recovery processing. In consideration of these merits and demerits, how to manage journals should be selected for each system. Further, by using the collective management described above and the distributed management as in the embodiment together, it is possible to utilize the advantages of both.

FIG. 5 shows the configuration of the above embodiment,
The case where the server 1a is the main device is taken as an example, and in particular, the parts relating to the acquisition of the journal and the recovery processing after the occurrence of a failure are shown in detail.

In FIG. 5, the commit management unit 501 and the recovery management unit 502 of the server 1a as the main device are both
This is a processing unit included in the GTM 22 of the server 1a shown in FIG. Further, the lock management unit 503 and the recovery management unit 504 of each of the slave servers 1b, 1c, ...
Is a processing unit included in the LTM 23 of each of the servers 1b, 1c. In FIG. 5, the database 16 and the memory table / file unit 17 of each server are collectively shown as a resource, and the management units 14 and 15 and the update image logs 26 and 27 are also collectively shown as one block. is there.

The commit management unit 501 of the main device 1a
The following processing is performed according to an instruction from the P main part 20.

A transaction identifier is generated according to the transaction start instruction. Here, the transaction identifier is an identification code unique to each transaction. This transaction identifier also includes a server identification code indicating which server is the main device of the transaction processing.

According to the lock instruction, a lock command is issued to the lock management unit 503 of each server.

According to the temporary update instruction, the transaction identifier, the lock identifier, and the temporary update command are held in the memory, and the temporary update command is stored in the access management unit 2 of each server.
Issue to 1.

According to the commit instruction, the transaction identifier, the lock identifier, and the temporary update command held in the memory are recorded as the journal 18, and the unlock command is issued to the lock management unit 503 of each server.

According to the rollback instruction, all information regarding the transaction is discarded, and a rollback command is issued to the lock management unit 503 of each server.

The recovery management unit 502 of the main device 1a is requested according to a request from the recovery management unit 502 of the slave devices 1b, 1c, ... In the recovery processing after a failure such as a system down in the slave devices 1b, 1c. The temporary update command of the transaction
The slave devices 1b, 1c ...
To the recovery management unit 502.

In the journal 18 of the main device 1a, as already described, the transaction identifiers, lock identifiers, and temporary update commands relating to all transactions accepted and committed by the main device 1a are recorded in time series.

The lock management unit 50 of each of the slaves 1b, 1c, ...
3 performs the following processing.

In response to a lock command from the commit management unit 501 of the main unit 1a, lock acquisition processing, transaction start command issuance to the database / resource management units 14 and 15, generation of lock identifier, and lock / unlock The lock information for the logs 24 and 25 is acquired. Here, the lock identifier is an identification code unique to each lock information.

In response to the unlock command from the commit management unit 501, the database / resource management units 14 and 15
Issue a commit command to the lock / unlock log 24, 25 to obtain unlock information.

In response to the rollback command from the commit management unit 501, the database / resource management units 14, 1
Issue a rollback command to 5 and obtain unlock information in the lock / unlock log 24, 25.

AP access unit 2 of each slave device 1b, 1c ...
1 receives a temporary update command from the commit management unit 501 of the main device 1a and issues a temporary update command to the database / resource management units 14 and 15.

The recovery management section 5 of each slave device 1b, 1c ...
04 performs the following processes.

In the recovery processing, the lock / unlock log 24, 25 is searched for lock information without unlock information, and the recovery management unit 502 of the main unit 1a is requested to perform recovery processing based on this information.

Upon receiving a temporary update command from the recovery management unit 502 of the main unit 1a, the recovery is executed.

The database / resource management units 14 and 15 of the slaves 1b, 1c, ... Have a recovery function based on the local update image logs 26 and 27, respectively.

The lock / unlock logs 24 and 25 of the slaves 1b, 1c, ... Are time-series records of lock information and unlock information regarding the resources 16 and 17, respectively. The lock information includes a transaction identifier, a lock mark, a lock identifier and a record name.
The unlock information includes a transaction identifier and an unlock mark. The lock information and the unlock information are associated with each other by the transaction identifier included in the lock information and the unlock information. If there is lock information that is not associated with unlock information, it means that a failure has occurred in that transaction, and the transaction identifier in the lock information indicates the transaction and main device at the time of failure. And can be identified. In the recovery process, the transaction at the time of failure and the main device are thus identified.

The procedure of transaction processing and the procedure of recovery processing will be described in detail below.

First of all. The transaction processing procedure is shown in FIG.
This will be described with reference to FIG.

FIG. 6 shows the processing procedure of the AP main part 20 and the commit management part 501 of the main device 1a in transaction processing. FIG. 7 shows a lock processing procedure of the lock management unit 503 of each of the slave devices 1b, 1c, .... FIG. 8 shows a temporary update command processing procedure of the AP access unit 21 of each slave device 1b, 1c .... FIG. 9 shows an unlock command processing procedure of the lock management unit 503 of each of the slave devices 1b, 1c, .... Figure 10
Shows a rollback command processing procedure of the lock management unit 503 of each slave device 1b, 1c ....

As shown in FIG. 6, first, in the main device 1a, the AP main part 20 issues a transaction start instruction (step S301), and in response to this, the commit management part 51 generates a transaction identifier for the transaction. (Step S302). Next, AP
The main part 20 issues a lock instruction (step S303).
0) and in response thereto, the commit management unit 501 issues a lock command to the lock management units 503 of the slave devices 1b, 1c ... (Step S304).

The lock management unit 5 of each slave device 1b, 1c, ...
As shown in FIG. 7, when receiving the lock command from the main device 1a (step S330), the 03 performs lock acquisition processing (step S331). In the lock acquisition process,
The received lock command is acquired in memory, and the record (or table or file) that is the lock target
Checks whether it has already been locked by another transaction. If it is not locked, it is determined that the lock is successful, and if it is already locked, it is determined that the lock is unsuccessful (step S332). If the lock is unsuccessful, the lock command acquired in the memory is discarded and the lock failure is notified to the main device 1a (step S333).

On the other hand, when the lock is successful, the lock management unit 503 next issues a transaction start command to the resources 16 and 17 (step S334), and generates a lock identifier corresponding to the lock (step S335). Then, the transaction identifier (included in the lock command), the lock mark, the lock identifier, and the record name of the lock target are acquired in the lock log 24 (step S33).
6) After that, the lock identifier is sent to the main device 1a (step S337).

Referring again to FIG. 6, the commit management unit 501 of the main device 1a issues a lock command in step S307, and then issues a lock identifier (notification of lock success) or lock failure from each of the slave devices 1b, 1c. When you receive the notification of
This is reported to the AP main section 20. AP main part 20,
It is checked whether all the slaves 1b, 1c ... Have succeeded in the lock (step S305), and if all the slaves have succeeded in the lock, issue a temporary update instruction to the resources of each slave (step S308). ). The commit management unit 501, which has received this temporary update instruction,
The lock identifier of each resource and the temporary update command are temporarily acquired in the memory (step S309), and the AP of each slave device is acquired.
A temporary update command for each resource is issued to the access unit 21 (step S310).

In each slave, as shown in FIG. 8, when the AP access unit 21 receives a temporary update command (step S340), it issues a temporary update command to each resource (step S341), and each A response is received from the resource as to whether or not the provisional update is successful (step 341), and a success or failure message is sent to the main device according to the response (step S3).
42, S343).

Referring again to FIG. 6, when the commit management unit 501 of the master device receives the reply of the success or failure of the temporary update from each slave device (step S310), the AP main unit 20.
Report to. The AP main unit 20 checks whether all the slave devices have succeeded in the temporary update (step S311), and if all succeed, issues a commit instruction next (step S3).
314). Commit management unit 5 that received this commit instruction
01 acquires the transaction identifier, the lock identifier of each resource, and the tentative update command acquired on the memory in step S309 into the journal 18 (step S315), and then issues an unlock command to the lock management unit 503 of each slave. It is issued (step S316). Here, the unlock instruction includes a commit flag indicating whether or not to commit, and the unlock instruction issued in step S316 has the commit flag = ON.

In each slave device, as shown in FIG. 9, when the lock management unit 503 receives the unlock command (step S351), it checks the commit flag (step S352), and if the commit flag is ON, A commit command is issued to each of the resources 16 and 17 (step S353). Each resource 16 and 1 that received a commit command
7 performs the actual update and acquires the update image logs 26 and 27 for its own recovery (step S3).
54). After that, the lock management unit 503 releases the lock acquired in the previous lock command process (step S35).
5) The transaction identifier and unlock mark are acquired in the unlock log 25 (step S356).

Referring again to FIG. 6, after issuing the commit command in step S316, the commit management unit 501 of the master device immediately does not care whether or not the commit is actually successful in each slave device, and immediately The AP main unit 20 is notified of the end of the transaction, the AP main unit 20 reports the completion of the transaction to the terminal, and ends the transaction processing.

When the AP main unit 20 of the main device recognizes that even one of the slave devices failed to lock in step S305, it issues a rollback instruction (step S306). In addition, if it is determined in step S311 that any one of the slave devices has failed in the temporary update, the rollback instruction is similarly issued (step S306). Upon receiving the rollback instruction, the commit management unit 501 discards the transaction information (transaction identifier, lock identifier, etc.) and issues a rollback command to the lock management unit 503 of each slave (steps S307 and 313).

In each slave device which has received the rollback command,
As shown in FIG. 10, the lock management unit 503 receives the rollback command (step S361) and issues the rollback command to the resources 16 and 17 (step S362). Each of the resources 16 and 17 performs its own rollback processing (step S363). Then, the lock management unit 503 releases the acquired lock (step S3
64), the transaction identifier and the unlock mark are acquired in the unlock log 25 (step S36).
5).

Transaction processing is performed as described above. In the process, if a failure occurs in the lock instruction processing or temporary update instruction processing, the transaction is rolled back, but if a failure occurs in any of the slaves in the commit instruction processing, the transaction is rolled back. Processed as if it had been committed. Therefore, in the slave device in which the failure has occurred, the resource is restored to the correctly committed state by performing the recovery process later.

The recovery process will be described below with reference to FIGS. 11 to 14.

FIG. 11 shows the entire processing procedure from the failure occurrence to the recovery processing. FIG. 12 shows a recovery request processing procedure of the recovery management unit 504 of each slave device. FIG.
The recovery processing procedure of the recovery management unit 502 of the main device is shown. FIG. 14 shows a recovery execution processing procedure of each slave device.

As shown in FIG. 11, when a failure such as a system down occurs in any of the slaves, the work of removing the cause of the failure is first performed in that slave, and then the system is restarted (step S401). ), The recovery process is started immediately after this restart (step S40).
2). In the recovery process, first, the individual resources 16 and 17 are
Does its own recovery process, its own update image log 2
6 and 27 (step S403). That is, according to the update image regarding the committed transaction recorded in the update image logs 26 and 27, the content of itself is updated, and the uncommitted transaction is rolled back. This recovery process restores the consistency within the individual resources 16 and 17.

After the recovery processing with the individual resources, the recovery processing by the recovery management units 502 and 504 of the main device and the slave device is performed (step S404). This recovery processing restores the consistency of resources throughout the entire system, and is performed in the following three stages: from the recovery management unit 504 of the slave device to the recovery management unit 502 of the main device.
Recovery request (FIG. 12), a recovery process in the recovery management unit 502 of the main device (FIG. 13), and a recovery execution process in the recovery management unit 504 of the slave device (FIG. 14).

First, in the request processing from the recovery management unit 504 of the slave device to the recovery management unit 502 of the main device, FIG.
As shown in FIG. 2, first, the lock / unlock log 24,
The transaction identifier for which the unlock mark corresponding to the lock mark has not been acquired is retrieved from 25 (step S510). For example, in the illustrated example, the transaction identifier “A” is not a search target because it has an unlock mark corresponding to the lock mark. Because,
This is because the transaction had already been completed when the failure occurred. On the other hand, the transaction identifier “B” is
Since there is no unlock mark, it will be searched. This is because the transaction was not completed due to the failure.

In this way, when an uncompleted transaction identifier is found, then the transaction identifier and lock identifier are sent to the recovery management unit 502 of the main unit to request recovery (step S5).
11, 512).

Upon receiving the recovery request, the recovery management unit 502 of the main device first accepts the recovery request (step S520) as shown in FIG.
The temporary update instruction corresponding to the transaction identifier and the lock identifier is retrieved from 8 (step S521).
When the temporary update command to be searched is found (step S522), the temporary update command is issued to the recovery management unit 504 of the slave device which is the request source (step S52).
3). On the other hand, if the provisional update instruction to be searched cannot be found, a message “no provisional update instruction” is issued to the recovery management unit 504 of the slave device which is the request source (step S52).
4).

As shown in FIG. 14, the recovery management unit 504 of the slave device of the recovery request source receives the temporary update command (or “no temporary update command” message) requested from the recovery management unit 502 of the main device (step). S530), when the temporary update command is received (step S531), the transaction start command is issued to each of the resources 16 and 17 (step S532), and the temporary update command is issued (step S533). As a result, the temporary update instruction is re-executed in each of the resources 16 and 17 (step S534). Next, the recovery management unit 504 issues an unlock command with the commit flag = ON to the lock management unit 503 (step S535). As a result, the lock management unit 503 executes the unlock command processing shown in FIG. 9, and as a result, the actual update of the resources 16 and 17 is executed.

On the other hand, if it is determined in step S531 that the message is "no temporary update command", the recovery management unit 5
04 indicates to the lock management unit 503 that the commit flag =
Issue the unlock command that was turned off (step S
536). As a result, the lock management unit 503 performs the unlock command processing shown in FIG.
The unlock log is acquired without updating 6 and 17.

By the recovery processing as described above, the resources of the failed server are forcibly returned to the state in which all the transactions are correctly committed.
Resource consistency is ensured throughout the system. Further, since the business processing program does not need to re-execute the transaction processing for recovery, the load on the business processing program can be reduced.

15 and 16 show a modification of the recovery process. In this modification, not all the temporary update commands are sequentially sent from the main device to the slave device as in the recovery process described above, but all the temporary update commands necessary for recovery are sent from the main device to the slave device at once. It was done.

As shown in FIG. 15, the recovery management unit 504 of the slave device which has started the recovery process first performs lock / lock.
From the unlock logs 24 and 25, all the transaction identifiers for which the unlock mark corresponding to the lock mark has not been acquired are searched, and those transaction identifier and lock identifier are stored in the memory (step S
600). As a result, if there is at least one transaction identifier without an unlock mark (step S60).
1) Next, all transaction identifiers and lock identifiers stored in the memory are sent to the main device, and a search for a corresponding temporary update command is requested (step S602).

Upon receipt of this request, the recovery management unit 502 of the main unit accepts the search request (step S610) as shown in FIG. 16, and issues a temporary update command corresponding to all the requested transaction identifiers and lock identifiers. From the journal 18 (step S611), and returns all the retrieved temporary update commands to the recovery management unit 504 of the slave device which is the request source (step S61).
2).

Referring again to FIG. 15, when the recovery management unit 504 of the slave device receives all the requested temporary update commands from the main device (step S602), it then receives the received temporary update commands as resources 16 , 17 in order (step S603). Subsequently, the recovery management unit 504 instructs the lock management unit 503 to unlock all transaction identifiers stored in the memory.
An unlock command with the commit flag = ON is issued (step S604). An unlock command with the commit flag = OFF is issued for a transaction that has not received a temporary update command from the main device. As a result, the update for all uncommitted transactions is executed, and the resources 16 and 17 are returned to the correct state.

[0110]

According to the cooperative distributed system of the present invention,
Transaction processing will be executed correctly and smoothly, and the consistency of the database will always be guaranteed.

[Brief description of drawings]

FIG. 1 is a block diagram showing the overall configuration of an embodiment of a cooperative distributed system of the present invention.

FIG. 2 is a block diagram showing the operation of the embodiment of FIG. 1 and the function of each unit in more detail.

FIG. 3 is a block diagram showing one typical system configuration example adopted in the system of the present invention.

FIG. 4 is a block diagram showing another system configuration example that can be adopted in the present invention.

FIG. 5 is a block diagram showing in detail, in the embodiment of FIG. 1, a case where a server 1a is a main device as an example, and in particular, a portion related to journal acquisition and recovery processing after a failure occurs.

FIG. 6A of main device 1a in transaction processing
6 is a flowchart showing a processing procedure of a P main part 20 and a commit management part 501.

FIG. 7 is a flowchart showing a lock processing procedure of a lock management unit 503 of each of the slave devices 1b, 1c.

FIG. 8 is a flowchart showing a temporary update command processing procedure of the AP access unit 21 of each slave device 1b, 1c.

9 is a flowchart showing an unlock command processing procedure of the lock management unit 503 of each of the slave devices 1b, 1c, ....

FIG. 10 is a lock management unit 503 of each slave device 1b, 1c.
6 is a flowchart showing a rollback instruction processing procedure.

FIG. 11 is a flowchart showing the overall processing procedure of a recovery process from the occurrence of a failure.

FIG. 12 is a flowchart showing a recovery request processing procedure of the recovery management unit 504 of each slave device.

FIG. 13 is a flowchart showing a recovery processing procedure of the recovery management unit 502 of the main device.

FIG. 14 is a flowchart showing a recovery execution processing procedure of each slave device.

FIG. 15 is a diagram showing a recovery management unit 5 in another recovery process.
The flowchart which shows the processing procedure of 04.

FIG. 16 is a diagram showing a recovery management unit 5 in another recovery process.
The flowchart which shows the processing procedure of 02.

[Explanation of symbols]

 1 distributed processing device (server) 2 communication network 3 terminal 11 communication manager 12 business processing program 13 distributed resource synchronization processing unit 14 database management unit 15 resource management unit 16 database 17 memory table / file unit 18 journal 20 AP main unit 21 AP access Part 22 Global transaction management part (GTM) 23 Local transaction management part (LTM) 24 Lock log 25 Unlock log 26, 27 Update image log 501 Commit management part 502, 504 Recovery management part 503 Lock management part

 ─────────────────────────────────────────────────── ─── Continued Front Page (72) Inventor Toshiyuki Inoue 3-3-3 Toyosu, Koto-ku, Tokyo NTT Data Communications Corporation

Claims (6)

[Claims] 1. A collaborative distributed system in which a plurality of processing devices capable of communicating with each other divide resources to receive the resources and cooperatively perform distributed processing of transactions, wherein at least one processing device of the plurality of processing devices is provided. Is a main device for accepting a transaction, another processing device is a slave device for distributed processing of the accepted transaction, and the main device is an update content of the resource to be updated in the transaction. Update information issuing means for issuing to the slave device that is in charge of the resources to be updated, one of the master device and the slave device updates the update information issued by the master device. Each of the slaves has a journal in which all contents are recorded together with a transaction identifier. The actual update means for updating the resources each of which manages, and the past transaction for which the update by the actual update means has failed are specified, update information corresponding to the specified transaction is ordered from the journal, and based on the acquired update information, A collaborative distributed system, comprising: a recovery means for updating resources. 2. The system according to claim 1, wherein each of the plurality of distribution devices can be either the main device or the slave device, the update information issuing means, the journal, and A collaborative distributed system comprising an actual updating means and the recovery means. 3. The system according to claim 1, wherein the main unit has the journal. 4. The system according to claim 1, wherein each of the slave devices locks the resource to be updated before updating and unlocks after updating, and a history of locking and unlocking of the resource. And a lock / unlock log recording therein, wherein the exclusive control means can perform locking and unlocking for each accessible minimum information unit of the resource. 5. The system according to claim 1, wherein each of the slaves locks the resource to be updated before updating and unlocks after updating, and a lock and unlock history of the resource. A lock / unlock log that records the transaction identifier together with the transaction identifier,
The collaborative distributed system, further comprising: wherein the recovery unit identifies the transaction in which the update has failed by referring to the lock / unlock log. 6. A cooperative distributed processing method in which a plurality of processing devices communicable with each other divide resources and receive the resources and cooperatively perform distributed processing of transactions, wherein one processing device among the plurality of processing devices is A step of accepting a transaction as a main device, a step of issuing update information indicating update contents of the resource to be updated in the transaction, to the other device which is in charge of the resource to be updated, , A process in which one of the main device and the other device acquires all the update contents of the update information issued by the main device into a journal together with a transaction identifier, and each of the other devices stores the update information in the journal. Based on the process of updating each resource, the main device and each of the other devices fail to be updated by the actual updating means. Identified past transactions, Toyo update information corresponding to the identified transaction from the journal, on the basis of Toyo update information,
And a step of updating the resource, the cooperative distributed processing method.