In a computer system, a transaction is defined to be a series of process procedures consisting of a plurality of processes. As one form of a transaction, there is a distributed transaction. In the distributed transaction, a transaction is carried out on each node of a distributed computer system. For example, the update of a plurality of pieces of database is one form of the distributed transaction. In this case, each piece of database exists in each node of the distributed computer system (for example, a database server provided with a database management system, etc.) and in a transaction process, database managed by each node is updated.
In the distributed transaction too, atomicity must be ensured as in a transaction carried out in a single computer system. Atomicity is a nature that a transaction must be completely carried out or must not be carried out at all. The normal completion of a transaction is called commit and its failure is called abort.
In the distributed transaction, since each computer system fails independently, it is far more difficult to ensure atomicity compared with a transaction carried out in a single computer system. In order to solve this difficulty, in the distributed transaction, a two-phase commit protocol is used for the commit of a transaction.
In the distributed transaction, a computer system participating in a transaction must store the update of a transaction in a non-volatile storage medium permanently before a transaction is committed somewhere. By performing such a process in advance, even when a system downs before a transaction is committed, a transaction can be committed after the restoration of failure.
In the two-phase commit protocol, each computer system participating in a distributed transaction ensures atomicity by storing information and data about the update in a non-volatile storage medium before a transaction is committed thus.
Here, the two-phase commit protocol is described. In the following description, the two-phase commit protocol is sometimes called simply two-phase commit.
In the two-phase commit protocol, a plurality of components (for example, database management devices) is divided into one coordinator and the other participants. The two-phase commit protocol is carried out as follows.
[The First Phase]
    1) The coordinator transmits “prepare request” to a participant.    2) The coordinator waits for its response from all the participants to which the prepare request is transmitted.    3) The participant that has received the prepare request from the coordinator writes “preparation completion log” in a storage device. Then, the participant returns to “preparation completion” or “refusal” to the coordinator. This response is generally called “voting”.[The Second Phase]    1) The coordinator determines “commit” or “abort” on the basis of the voting results from all the participants and writes “commit log” in the storage device. In this case, the coordinator determines “commit” only when receiving the voting of “preparation completion” from all the participants.    2) The coordinator transmits the determination result (commit or abort) to all the participants.    3) Upon receipt of the determination result, a participant returns “completion “to the coordinator and writes “transaction completion log” in the storage device.
In this case, the span between the first and second phases is a period of “in-doubt state” or “uncertain state”. Although a participant can abort anytime before voting, it can neither commit nor abort until it receiving a determination result from the coordinator after transmitting “preparation completion”. This is because if this is not observed, there is a possibility that atomicity may fail. Therefore, the period of the in-doubt state is the period each participant is uncertain which it should commit or abort. If the coordinator downs while each participant is in the in-doubt state, each participant is blocked. Specifically, each participant is put in the state where it can commit nor abort. In this way, the two-phase commit protocol has a problem that there is a possibility that each participant may be blocked in the in-doubt state.
However, this applicant has filed the application of the invention of a device comprising a log storage device for storing the log information of data for each data storage device for storing the data before (see Japan Laid-open Patent Publication No. 06-337810). In this specification, a group obtained by packaging the data storage device and the log storage device is called “log group”.
The process before/after an in-doubt state period in the two-phase commit protocol in the case where a distributed transaction is carried out in such a distributed computer system provided with a plurality of database management devices is described. When receiving message of prepare request from the coordinator, each participant writes “preparation completion log” in the log storage device, and then transmits message of “preparation completion” to the coordinator. When receiving message of preparation completion from all the participants, the coordinator determines commit or abort and writes a “transaction completion log” in the log storage device. Then, the coordinator transmits the determination result to all the participants.
The transaction completion log and the preparation completion log store the following information (1) and (2), respectively, in order to solve the in-doubt state.    (1) Notification destination of the final result of a transaction (transaction completion log)    (2) Inquiry destination of the final result of a transaction (preparation completion log)
When a participant has restored from the failure after having downed during an in-doubt state period, the preparation completion log is written in the log storage device but the transaction completion log (log of commit or abort) is not written in the log storage device. Therefore, the participant is blocked. Therefore, the participant carries out “termination protocol” in order to solve the blocked transaction.
The termination protocol is the process which is carried out by a participant in order to solve the blocked transaction when the participant restores from a failure.
One example of the termination protocol, the participant transmits voting to the coordinator again. In order to transmit voting to the coordinator, the participant obtains the “notification destination of the final result of a transaction” from the preparation completion log. This is because the inquiry destination of the final result of a transaction is the communication address (for example, IP address) of the coordinator.
Upon receipt of the voting from the participant, when already receiving voting from the participant, the coordinator determines that the participant has not received the voting result yet and transmits the voting result to the participant. In this case, in order to transmit this voting result to the participant obtains the “notification destination of the final result of a transaction” from the transaction completion log. This is because this notification destination of the final result of a transaction is the communication addresses of the participants.
In this way, conventionally, the notification destination of the final result of a transaction and the inquiry destination of the final result of a transaction are the communication address(es) of participants and the coordinator, respectively.
However, in a database management system not provided with a two-phase commit function, as a technology related to a distributed transaction, an invention for realizing pseudo two-phase commit at an application program level is known (for example, Japan Laid-open Patent Publication No. 63-008845).
There are two types of shared nothing and shared disk in the distributed database having a cluster configuration. The shared nothing type distributed database is a system in which a database management device (database server) does not share resources. The shared disk type distributed database is a system in which a database management device (database server) shares resources.
As the database that supports a distributed transaction in the shared nothing type cluster system there are the HiRDB of Hitachi Corporation, the SQL server of Microsoft Corporation and the like. Oracle Corporation in U.S.A. proposes the solution method in the case where a database management device downs during two-phase commit in the distributed transaction of a shared disk type distributed database (see Home page URL of Oracle Corporation (http://download.oracle.com/docs/cd/B19306—01/server.102/b14231/ds_concepts.htm).
A distributed computer system provided with a plurality of database management devices for managing the conventional log groups has a disadvantage that when executing a distributed transaction, the following problems occur.    (1) When a certain database management device downs, the management right of the log groups managed by the database management device moves to another database management device while such a distributed transaction as to update a plurality of log groups is carried out, the distributed transaction cannot be restored. In this case, the management right is the right by which the log groups can refer to/update the data of a storage device.
For example, the down database management device is the coordinator and also the down has occurred while a participant is in the in-doubt state, the “inquiry destination of the final result of a transaction” stored in the log storage device of the participant becomes invalid. Because since the inquiry destination of a final result transaction is the communication address of the coordinator that has downed, the participant cannot receive the final result of the transaction even when the participant inquires about the final result of the transaction using the communication address. Therefore, the participant cannot solve the in-doubt state and restore the distributed transaction.
It is assumed that the down database management device is a participant and the participant downs after notifying the database management device being the coordinator of message of preparation completion. In this case, the “notification destination of the final result of a transaction” stored a transaction completion log recorded on the log storage device is the communication address of the down participant. However, this communication address is invalid. Because the communication address of the database management device to which the management right of the log groups managed by the down participant is moved is not the communication address stored in the notification destination of the final result of the transaction. Therefore, the database management device that has taken over the management right of the log group cannot know the final result of the transaction and solve the in-doubt state.
As described above, conventionally, if a database management device participating in the distributed transaction downs during the in-doubt state period of two-phase commit when in a distributed database system comprising a plurality of database management devices for managing log groups, such a distributed transaction as to update a plurality of log groups is carried out, the distributed transaction cannot be restored.    (2) Even if the problem of the above (1) is solved, the following problem remains.
When the management right of a log group moves, a database management device without any log storage device is generated. For example, the database management device from which the management right of the log group managed by its own device moves to another database management device has no log storage device. When update application for carrying out a distributed transaction (application for updating data) is connected to such a database management device having no log group and the update application is committed, the database management device having no log group (coordinator) cannot record the final result of the distributed transaction (commit or abort) on the log storage device. Therefore, in case where the database management device participating in the distributed transaction downs during carrying out two-phase commit, the database management system can not restore the distributed transaction. For example, this is because when the coordinator downs, the inquiry destination about which a participant inquires, of the final result of the distributed transaction is lost. Therefore, the participant cannot solve the in-doubt state and restore the distributed transaction.
USPTO Backgrounds
USPTO Backgrounds