JPH06223007A - Two-phase commit control method - Google Patents

Abstract

(57) [Summary] (Modified) [Configuration] As the first step in the distributed transaction processing system, each of the participants 11 and 12 receiving the commit preparation request from the coordinator 10 requests the commit preparation journal of its own. , The commit preparation request is sent to the next round destination, and the last participant merges its commit preparation journal with the commit preparation journal and then sends the commit preparation request to the journal recorder 21. After recording the commit preparation journals of all the participants, the journal recorder 21 reports the fact to the coordinator 10. As the second stage, the coordinator 10 sends a commit request to the journal recorder 21 with the visit destination information including all the participant names, and after the commit journals of all the participants are recorded, It is sent to the patrol destination and reports to the coordinator that the last participant received a commit request. [Effect] It is possible to reduce the number of times of communication to the journal server and the number of times of input / output to / from the journal file.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to two-phase commit processing in distributed transaction processing, and more particularly to a two-phase commit control method for reducing the number of message transmissions and the number of journal recordings.

[0002]

[Prior art]

(1) Commit control method A transaction is a sequence of various operations including file and database operations. A transaction is a processing unit of recovery or concurrent execution, which is started by a transaction start command or at the first operation on a file or database which is a resource to which the transaction is applied, and is ended by a commit or rollback transaction control command. It is called commit to actually confirm the update process to the database,
Rolling back (or aborting) cancels the update process so that the update is not performed. A transaction does not allow all changes made by that transaction to be accessed by other transactions until it ends with a commit or rollback instruction. When a transaction is committed, all changes made by that transaction are accessible to other transactions. Also, when a transaction is rolled back, all changes made by that transaction are invalidated. You cannot undo committed changes. Such processing is called transaction processing. Resources to which the concept of transactions apply are files and databases.

In the following description, the applicable resource is described as a database, but it may be a file.
Further, the database and the file may be mixed.

When performing transaction processing in a distributed processing system connected by a communication network,
A logical transaction is divided into partial processes, that is, sub-transactions and processed by any computer in the network. Transaction processing in such a distributed processing system is called distributed transaction processing.

As a method for committing a transaction in distributed transaction processing, a transaction control method called two-phase commit has been proposed. In other words, this commit processing includes a first processing phase (commit preparation step) in which information before and after updating is held on each computer having a database and the database is temporarily updated, and an update in all computers. It comprises a second processing phase in which the database is actually updated based on the information before and after the update in response to the approval (or the temporary update state is canceled when even one is not approved).

The details of such a transaction control method are described in M. Tamer Ozsu, Patrick V
Alduriez co-authored "PRINCIPLE OF
DISTRIBUTED DATABASE SYSTEM
EMS "Plentice-Hall Intern
National Publishers, 1991, pp. 322-364.

In general, the distributed transaction processing is applied to a system called online transaction processing which requires reliability. Online transaction processing refers to the processing of a bank's online system that processes deposit / withdrawal, balance introduction, etc., and the reservation system of the travel industry. These take a system form in which many computers and terminals are connected. These online systems access a very small part of the database and perform commit processing. A typical example of this is TPC (Transaction Processing per), which is known as a database benchmark.
formance Council) There is a benchmark, and a typical one is a benchmark called TPC-B. In this benchmark, the number of transactions that can be processed in one second is measured. TPC-B
Then, a search and an update are performed on three types of databases. In these processes, the database access amount in one transaction is generally small. However, when the server that accesses the database is divided into a plurality of nodes, the transaction two-phase commit processing is required. In the case of TPC-B, if the database is distributed, 30 transactions per transaction
% To nearly half of the processing is spent on two-phase commit communication and journal recording.

FIG. 2 shows an outline of the configuration of the distributed transaction processing system. In FIG. 2, a front-end server (hereinafter abbreviated as FES) and a back-end server (hereinafter B)
ES (abbreviated as ES) 11, 12, and 13 are connected by a communication network 160, and individual servers can communicate with other servers via the communication network. Here, the server is a functional unit that performs a certain specific process, and is allowed to operate on any computer.

The FES 10 receives a database processing request from an application program 130 (hereinafter abbreviated as AP) and sends the processing request to the BESs 11, 12 and 13. The individual BESs are stored in the databases 141, 142, 1
When the database processing request is received, the database processing is performed and the processing result is transferred to the AP via the FES. FES and BES record journals before and after database update and journals related to transaction control in journal files 201, 202, and 203, which are nonvolatile recording media of each server, during database operations.

An outline of the two-phase commit control method in FIG. 2 will be described with reference to FIG. The coordinator FES10 sends a database operation request generated in a transaction to a participant backend server (hereinafter abbreviated as BES) that performs database processing in the transaction, and requests the processing. The participants BES 11, 12, and 13 perform database operations based on the request. When the database operation is completed, follow the procedure below to confirm the transaction. Application program is comm
Executes a command called it. The commit command is passed to the FES 10 and the commit process is started.

First, in the first stage, that is, the commit preparation stage,
The coordinator FES10 includes the participants BES11, 12, 13
Request commit preparation (prepare in the figure). Each BES has a commit preparation journal (BES11PJ, BES12PJ, B in the figure) for the journal files 201, 202, 203 existing in the BES.
Record ES13PJ). The commit preparation journal must be recorded in the journal file at the recording request time in each BES in order to recover the state of each transaction when a failure occurs. By recording the commit preparation journal, it becomes possible for each participant to put the transaction into any state according to the following instruction, that is, the request (commit or rollback) in the second stage. When this preparation is completed in each BES, each BES returns a commit preparation completion response (ack in the commit preparation stage in FIG. 3) to the FES 10. Upon receiving the commit preparation completion from all the participants BES, the FES 10 records its own commit preparation journal (FES10PJ in the figure) in the journal file 200. When the BES cannot perform the above processing due to a failure or the like, it returns a failure response. The above processing completes the first stage of the two-phase commit control method.

Next, as the second step, the following processing is performed. After recording the commit journal (FES10CJ in the figure) indicating that the FES has committed the transaction in the journal file 200, all participants BE
Instruct S to commit. Each BES records a commit journal in each journal file according to the instruction of the FES, performs a commit process, and then issues a commit completion report (ack) to the FES. FE
S receives the completion report of all BESs and terminates the transaction. If there is a participant who does not respond or returns a failure response within a certain time, which is the stage of commit preparation,
The FES makes a rollback decision, records an abort journal indicating that the transaction is rollback confirmed in the journal file 200, and then makes a rollback request to all participants.

(2) Independent journal server In small-to-medium-scale distributed transaction processing typified by a local area network, load distribution can be performed by connecting and using a specific adjacent computer group as a file server or database server. It is common to build a system that allows centralized operation to live together.

The problem in the above environment is the operation of the journal file. In the conventional distributed transaction processing, the journal is acquired in each server. However, in the case of centralized distributed transaction processing in which each server is independent but its distribution is centralized (installed at the same site), when each server acquires a journal,
Each server must be equipped with a journal file or journal recording device (magnetic disk or magnetic tape) and its maintenance must be performed. In order to provide users with a simple journal operation, the system side needs to centrally operate journal files. A general method for this request is to use a journal server in which journal processing is performed by an independent computer. In the distributed transaction processing, journal processing can be made independent from FES and BES to realize centralized journal operation. Independence of the journal server will be described later in Japanese Patent Application No. Hei 2-333160.
No. 5 "Distributed transaction file control method for distributed processing system".

An outline of a distributed transaction processing system in which journal processing is independent in the system of FIG. 2 is shown in FIG. In the figure, FES10 and BES11,1
2, 13 and journal server (hereinafter abbreviated as JS) 2
1 and 22 are connected by a communication network 160, and individual servers can communicate with each other via the communication network. The FES 10 is an application program 130 (hereinafter abbreviated as AP)
Received a database processing request from BES11,1
The processing request is transmitted to Nos. 2 and 13. Each BES has databases 141, 142, 143. When a database processing request is received, database processing is performed and the processing result is transferred to the AP via FES. FES, BES
Sends a journal before and after database update and a journal relating to transaction control to JSs 21 and 22 during database operation. The JSs 21 and 22 have journal files 151 and 152, which are non-volatile recording media, and process journal recording requests from FES and BES.

FIG. 4 shows a control outline of the two-phase commit control in the above distributed database environment when the commit is successful. The basic processing flow is 2 in FIG.
Same as the phase commit control method. However, JS
The journal recording request is sent to the JS side via the communication network, processed by the JS side, and the result is sent to the request source. In the example of FIG. 4, the servers sharing the JS are grouped into FES10, BES11, B.
ES12 records the journal in JS21 and BES13 records the journal in JS22. Of course, an example using two JSs is shown, but one may be used.

At the commit preparation stage of the first stage, FES1
0 is JS for commit preparation journal (FES10PJ)
21 is recorded, and a commit preparation request (prepare in the figure) is sent to all BESs. Commit preparation journal of each BES (BES11PJ, BES12PJ, BES
13PJ) is transmitted to the JS side and recorded in the journal file. As a result, after the journal recording completion report (ack from JS to BES at the commit preparation stage in FIG. 4) is transmitted to each BES, the commit preparation completion report (ack) is transmitted from each BES to the FES 10.

In the second stage, a commit journal (FES1) recording that the FES10 has transitioned to the commit stage.
0CJ) is recorded in JS21 and its normal end (ack)
Receive. At this stage, the transaction status becomes commit decision. Next, the FES 10 sends a commit processing request (commit in the figure) to each BES. Each BES receives a commit processing request and receives a commit journal (BES1
1CJ, BES12CJ, BES13CJ) is requested to be recorded to each JS. Each JS executes a commit journal recording request and sends a completion report to each BES. Each BES receives the normal end of the journal and reports the commit completion to the FES 10. The FES 10 ends the transaction by receiving the normal completion report of all BESs.

(3) Cyclic Two-Phase Commit Control Method As a modification of the above two-phase commit control method, Japanese Patent Laid-Open No. 59-11564 “Cyclic Two-Phase Commitment Control Method” has been proposed. In this technique, in the distributed processing system with a built-in journal processing, the commit preparation completion is confirmed by circulating a telegram that combines a commit preparation request and a commit preparation completion. The purpose is to reduce the number of communications in the two-phase commit control method between the coordinator FES and each participant BES. Since communication requires a processing cost, it is desirable to reduce the number of times as much as possible. Generally, the number of logical communication messages in the commit preparation is required to be the number of participants × 2 times. In this publicly known technique, the number of communications is reduced by making the number of communications +1 the number of communications by causing each participant to circulate a telegram that combines a commit preparation request and a commit preparation completion.

(4) Distributed Transaction File Control Method In the above-mentioned distributed database processing when JS is independent, Japanese Patent Application No. 2-331605 "Distributed transaction file control method for distributed processing system" has been proposed. In this method, the commit preparation journals or commit journals that are requested to be recorded independently from the BESs that are journal-recorded in the same JS in a certain transaction are put together by waiting, and each is recorded in a journal file at once, and all the requesting BESs are recorded. It is characterized by transmitting the record completion report of the commit preparation journal or the commit journal. The purpose of this method is to suppress unnecessary journal recording and reduce the number of journal recordings.

[0021]

When the JS is made independent, the following problems occur with respect to the conventional two-phase commit control method with a built-in journal processing.

(1) Increase in the number of communications In commit preparation journal processing and commit journal processing in transaction processing, the following processing can be performed only after recording each journal in a journal file which is a non-volatile recording medium. Therefore, since the JS becomes independent, the communication for recording the journal file from the FES and each BES increases to the JS. That is, communication via the communication network is always required when recording the commit preparation journal and the commit journal from the FES and BES. The number of communications during commit processing is 2 independent of JS.
Compared with the phase commit control method, ((FES number (=
1) + number of BES) × 4 times (transmission / reception of commit preparation + transmission / reception of commit).

The "cyclic two-phase commitment control method" of Japanese Patent Laid-Open No. 59-11564 relates to distributed transaction processing with a built-in journal processing, and communication of journal recording generated by JS becoming independent. It cannot cope with the increase in the number of times.

(2) Increase in number of recordings (number of input / output requests) As described above, since journal recording requests are generated independently from the FES and BES, journal recording must be performed in response to each journal request. I have to. That is, in the conventional technique, a commit preparation journal, a commit journal, which is used for controlling two-phase commit,
The rollback journal (also referred to as an abort journal) needs to be recorded in a journal file which is a non-volatile recording medium after the arrival of a journal recording request in order to reliably record the transaction state. Therefore JS
Must process (FES number (= 1) + BES number) × 2 recording requests at the time of committing a certain transaction. This Japanese Patent Application No. 2-331605 "Distributed transaction file control method for distributed processing system" proposes to reduce the number of recordings. By using this technology, in a certain JS that is in a transaction,
The journal recording process is realized by the number of journal servers × 2 times of recording. However, this method requires complicated processing to wait for journal recording in the journal server. Moreover, as described above, the number of communications is not taken into consideration.

An object of the present invention is to provide a two-phase commit control method capable of efficiently performing two-phase commit processing in a distributed transaction processing system with independent journal servers.

[0026]

A two-phase commit control method according to the present invention is a method for controlling two transactions in a transaction.
A computer that is the coordinator of phase commit, a computer that processes subtransactions and that is a participant, and a computer that is a journal recorder that records a transaction journal as transaction status history information on a non-volatile recording medium In the two-phase commit control method in the distributed transaction processing system connected to, the coordinator causes the journal recorder to record a commit preparation journal as a first step of the two-phase commit, and all the participation. Each participant who receives the commit preparation request by adding the visit destination information including the name of the person and the journal recorder, and adds the commit preparation journal of its own to the commit preparation request, Prepare request next The final participant, after merging its own commit preparation journal with the commit preparation journal, sends the commit preparation request to the journal recorder, and the journal recorder In response to the commit preparation request to which the commit preparation journal is added, after recording the commit preparation journals of all the participants, the fact is reported to the coordinator, and as the second stage of the two-phase commit, the coordinator , A commit request to which the visit destination information including all the participant names is added is transmitted to the journal recorder, and the journal recorder receives the commit request and records the commit journals of all the participants. The commit request is transmitted to the next round destination, and each participant who receives the commit request sequentially sends the commit request to the next round destination. And, last of the participants, characterized in that it reports the fact that has received the commit request to the coordinator.

In the first stage, each of the participants is
Instead of adding the commit preparation journal to the commit preparation request, the journal recorder can generate and record the commit preparation journal of each participant.

In the second stage, the commit journal recorded by the journal recorder can be generated by the journal recorder, but may be generated by the coordinator and transmitted to the journal recorder. .

[0029]

The operation of the present invention will be described below as a typical configuration of the present invention in the case where there are two journal recorders (JS), the main and sub journal recorders.

In a certain transaction, after recording the commit preparation journal of the coordinator (FES), after cyclically merging (combining) the commit preparation journals of the participants (BES) of the same group who record the journal in the same JS, the circulation is performed. Record the merged journal in the JS. Each JS returns the commit ready report of each BES to the FES. The FES receives a completion report from each JS and sends a commit request to the JS of the FES.

The FES JS (main JS) records a commit journal and sends a commit request to another JS. Each JS collectively records the commit journal of each BES group, and then sends a commit request to each BES group. Each BES completes its sub-transaction by performing a commit process in response to a commit request.

In the above description, where the BES should originally perform the commit preparation journal recording, the commit preparation request is circulated, and the same JS is executed when the commit preparation request is processed.
All commit preparation journals are collectively recorded for each JES recorded for each JES. Similarly, at the time of commit, the journal, the control request, and the completion report are collectively transmitted to the JS and collectively recorded.

Even when the JSs are made independent as described above, the number of communications is reduced by the cyclic telegram, and the journals are collectively recorded by merging the journals during the patrol, and compared to the case where the journals are individually recorded, the journal file is recorded. The number of recordings (number of I / Os) can be reduced.
Further, a process such as journal waiting in JS is unnecessary.

[0034]

EXAMPLES Examples of the present invention will be described in detail below.

First, the outline of the two-phase commit control of the present invention will be described with reference to FIG. FIG. 5 is a transaction control command for commit processing and a commit preparation journal, a commit journal, when the present invention is applied to the system having the journal server (JS) shown in FIG.
It shows an outline of the electronic message transmission of the journal processing completion report. In FIG. 5, FES10 and BES11, 12 are J
The journal is recorded in S21, and the BES 13 records the journal in JS22.

When the commit command is issued from the AP 130 of FIG. 1, the FES 10 starts the commit process.

The case where the commit succeeds will be described below with reference to FIG.

At the first stage, the commit preparation stage, FES10
JS21 to commit preparation journal (FES10P
J: (including participant information indicating in which BES the transaction processing was performed) is sent to JS21. The JS 21 records this in the journal file 151. Processing report from JS21 (a on the right side output from JS21 in FIG. 5)
After receiving ck), the FES 10 requests the commit preparation (pre
pare) to BES11. Information (BES12, JS21) regarding all BESs and JSs to be visited next is added to the commit preparation request. BES
Reference numeral 11 denotes a message (prepar) that merges its own (BES11) commit preparation journal (BES11PJ in the figure) with respect to the commit preparation request sent from the FES10.
e (JS21), BES11PJ) is transmitted to BES12 which is the next destination. At this time, the next round-trip destination BES 12 in the commit preparation request is no longer necessary and is deleted. When the BES 12 receives the circulated message, it transmits a message (prepare, BES11PJ, BES12PJ in the figure) that merges the commit preparation journal BES12PJ of its own (BES12) in response to this commit preparation request. In this message, J, the next destination
S21 has been deleted. JS21 selects the commit preparation request (prepar) from the message edited by BES12.
Journals excluding e) (BES11PJ, BES12)
PJ) is recorded in the journal file 151 as it is. After recording the journal, JS21 has BES11 and 12
Of the commit preparation completion message (ac on the left side output from the JS 21 in FIG. 5) is transmitted to the FES 10.

As for the BES13, the JS
22 and the journal file 152.

The FES 10 receives the commit preparation completion reports from the JSs 21 and 22, and sends a commit request (commit (BES12, BES1 at the commit stage in FIG. 5).
1, JS22, BES13)), which is the journal recording destination of FES10 (this is called the master JS).
Send to. Upon receiving this transmission, JS21 receives FES1.
0 Commit Journal (FES10CJ) and JS21
To internally generate commit journals BES11CJ and BES12CJ of BES11, 12 to be recorded in
The generated journal is recorded in the journal file 151.

After recording the journal, the JS21 records each journal in the JS21 by this transaction.
The commit request to (BS12, BS11) is circulated. If there is another JS in the commit request, the master J
In order to perform the same processing as S, the same information is sent to that JS. In FIG. 5, a commit request is sent to the JS 22 to make a round.

In the present invention, important points for keeping the protocol of two-phase commit and reducing the number of communication and journal recording are the transmission of the cyclic message from the FES to the JS and the journal recording. When the FES commit journal is recorded, the commit of this transaction is decided. In other words, each BES is in the stage of transferring the commit preparation journal (PJ) and waiting for the completion of the recording thereof, but at this stage, the coordinator FES makes a commit decision. That is, the commit is confirmed as a transaction. The BES waits for the commit preparation journal recording in the first stage.

Although the journals are merged in each BES at the time of circulating the message of the commit preparation journal, as shown in FIG. 31, the number of circulating BESs increases and the journal amount increases. Communication volume increases. In order to improve this, the destination BES and JS information transmitted from the FES itself is used without merging the journals. That is, individual FES, BES
Do not delete the next tour information. As a result, the destination B
The message arrived at JS with the ES information remaining, and JS
By internally generating each commit preparation journal at the time of recording in J.S., it is possible to reduce the communication amount of the cyclic message. A specific example of this will be described later.

Next, the state transition of a transaction in the two-phase commit control method of the present invention will be described.

FIG. 8 shows the FES transaction state transition,
FIG. 9 shows the transaction state transition of BES and the transaction state transition of JS. In these state transition diagrams, circles indicate transaction states, and arrows indicate events that cause state transitions. The JS recorded by the FES as a journal as described above is called a master JS, and the JS recorded by the BES as a journal is called a sub JS. The JS shared by FES and BES is the master JS. A state in which a server cannot process a processing request from a different server due to a CPU fault, an OS fault, a communication fault, or the like is called a down state or down.

The state transition of the FES shown in FIG. 8 will be described.

The initial state of a transaction is free 80
It is 1. When the transaction is started, that is, the transaction start command is issued, the process transits to 802.

During processing 802, a database operation command is issued from the AP, and operations such as search change addition / deletion to the database are performed. When the AP issues a commit command, the state transitions to 803 during commit preparation processing, and when a rollback command is issued, rollba
The ck temporary decision 808 is entered.

During commit preparation processing 803, a commit preparation journal of the FES is recorded, a circuit message for each BES is assembled, and a journal is recorded in a certain JS.
In this state, the patrol message is transmitted to, and after the message is patrolled, an ack response from JS or a nak from BES is waited for. Receives a response from JS or BES, and returns normal completion (ack)
If so, the transition to the temporary commit decision 804 is made. If any response is nak, or if there is no response from the electronic message for a certain period of time due to reasons such as BES or JS failure, the rollback provisional decision 808 is entered.

The temporary commit decision 804 is a state in which the FES has decided to commit, but the commit journal is in an unrecorded state. Here, the information for performing the commit request and the commit round is transmitted to the master JS. After the transmission, the state transits to the commit hold 805. If a message cannot be transmitted to JS due to a communication failure during transmission, JS down, etc., that state is held. The information required for the commit request is the master JS participating in this transaction, the sub JS and the master, and the identifier of the BES group journal-outputted to each sub JS, specifically, each server name.

The commit hold 805 is a state in which a commit completion command, which is patrolled from JS and returned via BES, is waited for the number of traversing destinations, that is, JSs, in the state where the commit is tentatively decided. In this state, the processing results from all the patrol destinations are completed normally (a
ck), it is assumed that the transaction has been committed, and the transaction is completed, that is, free 801.
It becomes the state of. When there is no response from any of the patrol destinations in the state 805 for a certain period of time, the master JS determination 806 is performed. In this case, the transaction is recovered when the commit request to the master JS is not normally made due to JS down. If there is no response from some JS, master JS
Since the commit journal has been normally completed, the commit is retransmitted to each BES that has not responded yet (80
7).

The master JS judgment 806 is a process for deciding whether to commit or roll back the transaction when the master JS goes down due to a failure or a failure in all circuits. In this master JS determination, it is determined whether or not the commit journal of the FES of this transaction is on the master JS. If there is a commit journal, com for each BES
mit retransmission 807 is performed.

The commit retransmission 807 is c for all BESs.
If the omit is retransmitted and ack is received from all BESs, the transaction status becomes free 801. If BES is down, wait for its recovery. If there is no commit journal in the state 806, a transition is made to the master JS AJ (abort journal) record 811. If the master JS is down, wait for its recovery.

The rollback provisional decision 808 is a state in which the abort journal AJ has been decided to be invalidated but the abort journal AJ is in an unrecorded state. Master JS
A rollback request is made to and a transition is made to rollback suspension 809.

The rollback suspension 809 is a state in which the rollback completion ack is returned from the JS by way of the BES while the rollback is tentatively decided, and waits for the number of patrol destinations, that is, the number of JS. In this state, if all the patrol destinations are completed normally, the transaction is completed, that is, free 80
The state changes to 1. With rollback pending 809, down at any JS of the patrol destination, or JS, B
When the server is detected to be down due to a timeout due to the ES going down during the patrol process, the transaction status transits to rollback retransmission 812.

The master JS AJ judgment 810 is the first start state of a transaction in the middle of recovery when recovering a transaction that has not been completed at the time of down in the recovery process from FES down based on the journal of the master JS. Become. First, it is determined whether or not the transaction has been aborted. If the master JS has the abort journal of the FES of this transaction, the transaction has already been decided to be rolled back,
The transaction becomes free state 801. When the commit preparation journal exists and the abort journal does not exist, the transition is made to the master JSAJ record 811. If the commit preparation journal PJ is not recorded, the transaction status is free 801 because the same transaction is invalid. If the master JS does not respond due to down or the like, it waits for its recovery.

The master JS AJ record 811 is for rolling back this transaction state which is halfway due to a failure or the like. When the master JS outputs the abort journal and completes normally, the transaction becomes rollback retransmission 812. If the master JS is down, wait for its recovery.

In the rollback retransmission 812, each BE is
The rollback is retransmitted to S. If there is ack from all BESs, the transaction becomes free 801. If BES is down, wait for its recovery.

Next, the state transition of BES will be described.

The BES transaction is a sub-transaction.

The initial state of a sub-transaction is free 901. The BES sub-transaction transits to in-process 902 when a sub-transaction start command or the first database processing request. Free 901
When a commit request or rollback request is received at, the normal end is returned and the free 901 remains.

Processing 902 is a state in which the database is being operated. When there is a commit preparation request and a preparation completion request from the FES or the BES immediately before the circulating BES, the commit process is performed and the commit pending state 903 is set. If the commit process fails on its own, rollback pending 90
It becomes 5. When there is a rollback request from FES, the sub-transaction becomes invalid and free state 901
Becomes

The commit-pending state 903 is a state in which the BES waits for a commit or rollback request after requesting the JS to prepare for committing a subtransaction. When a commit request or rollback request is issued from this state, the subtransaction is committed or rolled back, and the subtransaction transits to the free state 901. BES, JS, FE on the circuit
When S goes down and there is no response, the process transits to FES determination 906.

From the rollback pending state 905, a transition to the free state 901 is made by a rollback request.

The sub-JS judgment 904 is after the BES is down.
This is the start state at the time of transaction recovery. In the sub-JS determination 904, the transaction transits to the free 901 state when there is the commit journal CJ and the abort journal AJ of the transaction and when there is no commit preparation journal PJ. When there is no commit preparation journal PJ or when there is no commit journal CJ, the process transits to FES determination 906. If the sub-JS is down, the sub-JS is on standby for recovery.

The FES judgment 906 is a step of inquiring the transaction status of the FES to determine the transaction status. FES is down or FES
Is waiting for the master JS to determine the transaction status. When a commit or rollback request is retransmitted from the FES or the FES transaction is already free, the sub JS journal record 907 is entered.

In the sub-JS journal recording 907, when the journal is not recorded in the sub-JS, the journal is recorded in the sub-JS. If the sub-JS does not respond due to down or the like, wait for the sub-JS to recover.

Next, the state transition of JS will be described.

The initial state of a transaction in JS is free 910. When a commit preparation request is made, the state transits to the commit pending state 911, and when a rollback request is made, the state remains free 910.

The commit pending state 911 changes its state in response to a request from the FES or the master JS. When a commit request or a rollback request is made, the state transitions to free 910.

In the case of JS down, the journal file is read in order to recover the transaction state, and the contents are reported to the inquiry of FES or BES. Also, when JS is down, if there is a preparation journal, and there is no commit journal or abort journal, it starts from the commit pending 911, and the others are free 910.
Start with.

Next, more specific examples of the present invention will be shown.

FIG. 6 shows the system configuration of this specific example.
The details of each server configuration will be described. The FES 10 causes each BES to process the database operation request of the user's application program AP130. BES11,1
2 and 13 access the database. JS21, 2
2 performs journal processing. In the figure, for convenience, BE
S11, 12, 13 are shown as the same server, and JS2
1 and 22 are shown as the same server.

Transaction processing unit 602 on FES side
Operates the transaction status of the AP 130 by operating the status information of the transaction and sub-transaction managed in the transaction management table 603 (FIG. 7). From AP130 commit and rollba
When the ck command is issued, commit, rollba
ck processing is performed. Furthermore, the database operation request is AP
The BE that analyzes the operation request when issued from 130 and holds the operation target database via the communication processing unit 604.
The operation request is transmitted to S. Further, the journal recording request generated in the transaction processing unit 602 is transmitted to JS.

BES side transaction processing unit 606
Manipulates the transaction (sub-transaction status information) managed in the transaction management table 609 to manipulate the transaction status of the AP 130.
Commit from FES10 via communication processing unit 605
When receiving the command or rollback command, commit,
Performs rollback processing. It also mediates the patrol of the same command. When the database operation request is issued from the FES 10, the database is operated and the processing result is transmitted to the FES.

The JS has a journal processing unit 608, a transaction management table 610 and a communication processing unit 607.

The communication processing units 604, 605, 607 control transmission / reception of electronic messages performed via a communication network. The transaction processing units 602 and 606 and the journal processing unit 608 in each server specify an identifier for identifying the partner server and transmit a message to each server by the communication processing units 604 and 60.
Request 5,607. In the present embodiment, transmission / reception is performed using an identifier called a server name. For reception, the communication processing unit receives a message from the transmission source and transmits it to the communication processing unit on the partner server side. The partner server-side communication processing unit holds the transmission message until the reception destination server can receive the message. When the server makes a request to receive a message and it becomes possible to receive it, the retained message is passed.

The message has the following format.

(1) Destination server identifier (server name) (2) Source server identifier (server name) (3) Transaction identifier (4) Subtransaction identifier (when transmitting between FES and BES) (5) Processing request ( (6) Parameters accompanying the processing request (tour destination list, etc.) (7) Other data and processing results (database operation statement, database operation data, etc.) In addition, from (1) to (4) ) Is called a message header.
In the following description, it is assumed that each message has a message header.

The journal processing unit 608 processes journal recording requests from each server. It also acts as an intermediary for the electronic message circulation related to transaction processing.

The format of the journal is shown in FIG.

The journal header 3101 includes a journal serial number 3104, a transaction identifier 3105, a subtransaction identifier 3106, a coordinator name 3107,
Others 3108. This information is FE
This information is necessary for recovery using the journal when S or BES ends abnormally or when the AP rolls back. The journal serial number 3104 is a serial number uniquely assigned to the journal. The transaction identifier 3105 is an identifier uniquely assigned to a transaction generated in FES, specifically, a serial number.
The sub-transaction identifier 3106 is an identifier given to a sub-transaction generated in another node within the transaction.

The journal type 3102 is the type of the recorded journal. Indicates the type of journal such as commit preparation, commit, rollback, transaction start, transaction end, and before / after database update journal. It is the commit preparation, commit, and rollback journals that must be immediately recorded in the journal file when a journal recording request is made.
Other journals are stored in the journal buffer (in the JS journal processing unit 608) with guaranteed order even when sent to JS, and are collectively recorded when the journal buffer is full, commit preparation, commit, and rollback journal are recorded. Then, it may be recorded in the journal file.
The transaction start journal and the transaction end journal are accumulated in the JS journal buffer when the transaction is started and the transaction is free, which will be described later. The journals before and after the database update are transmitted to the JS each time the database is updated and accumulated in the journal buffer.

The journal data 3103 stores data corresponding to the journal type.

FIG. 30B shows the contents of journal data corresponding to each journal type. In the commit preparation journal output by the coordinator, which is the commit preparation journal, the BES to be visited, which is necessary for recovery from a failure,
List information of names and JS names becomes data. For other commit preparation journals, the BES name in which the sub-transaction occurred is the data. The pre- and post-change database journal records the data before and after the change when the resource such as the database is changed (data is added, deleted, or updated). For journal types other than the above, there is no corresponding journal data.

Next, the transaction management table shown in FIG. 7 will be described. FIG. 7 is a transaction management table in FES.

The transaction management table 603 includes the following items. The transaction identifier 702 is an identifier uniquely given in the system to a transaction generated in FES. The transaction status information 703 holds the current status of the transaction identified by the transaction identifier 702. The transaction state is the transaction state of the transaction state transition shown in FIGS. 8 and 9.

The AP process number 704 indicates to which process, ie, AP, this transaction is assigned. Pointer to subtransaction information 70
Reference numeral 5 is a pointer to subtransaction information in the subtransaction management table 706.

The JS number 710 is the number of JSs for which journal recording is performed within this transaction. The pointer 711 to the JS management table is a pointer to the JS management table 712.

The sub-transaction management table 706 consists of the following items. The sub-transaction identifier 707 is a unique identifier in a sub-transaction generated in the system. The BES name 715 is the name of the BES to which the sub transaction is assigned. The recording destination JS name 709 has the name of the JS in which each BES records a journal.

The JS management table 712 consists of the following items.
The JS name 713 has the name of the JS to which a transaction is related in the transaction. The cyclic message status information 714 records whether the cyclic message processing is ack received, retransmission is required, or any other status.

BES transaction management table 609
Does not have the sub-transaction management table 706 and the journal server management table 712 in the transaction management table 603 in FES. A sub-transaction identifier is recorded in the transaction identifier.

The JS transaction management table 610 is also B
Similar to the ES transaction management table, it does not have a sub-transaction management table and a JS management table. The transaction management table of each server is created when each server is started.

Next, the processing outline of the AP will be described below with reference to FIG.

When the AP 130 starts processing, a database operation statement execution request 1001 is made. The result is processed by the application program processing 1002. The above processing is performed arbitrarily for each application program. After the processing using the database operation statement is completed, the application determines whether or not the transaction can be committed (1003).

COMMIT request 10 if committable
Issue 04. When it is determined that the commit is impossible, the rollback request 1005 is requested and the contents of the database operated by the transaction are invalidated.

FIG. 11 shows a database operation statement execution request 1
The processing content of 001 is shown.

A request for executing a database operation statement is processed by the transaction processing unit by extending AP. When a database operation request from the AP is requested, a BES determining process (1101) for processing the database operation request is performed to determine a BES for database operation. BES
The name is determined at this stage. Generally, the correspondence between BES and distributed databases is determined at the time of database definition. The subtransaction registration (1102) is processed before sending a processing request to the BES.

After registration of subtransaction, decision BES
The database operation statement, transaction identifier, and sub-transaction identifier are transmitted to (1103). The database operation request is processed by the transaction processing unit of BES. When the database operation is completed, the processing result is transmitted from BES. At this time, if the processing result is the first database operation request to the BES in the transaction (1104), the BE
Since the electronic message is transmitted in a format in which the JS name recorded by S in the journal is merged, the JS name and the processing result are received (110
6) Do.

It is judged whether the transmitted JS name is registered in the JS management table (1108), and if not registered, the JS name is registered in the JS management table (1109). At this time, 1 is added to the JS number of the transaction management table. Next, the transmitted recording destination JS name is set (1111) in the JS name item corresponding to the sub-transaction identifier assigned to the BES.

By the above means, the name of the JS recorded by the BES related to this transaction is acquired. If the processing result from the BES is not the first database operation request, only the processing result is received (1105). After receiving the database processing results, transfer each result to the AP (11
By doing 12), the AP operates on the database processing result.

The means for obtaining the JS identifier of each BES in relation to the occurrence of a sub-transaction has been shown above. J
The S name can be acquired not only by the dynamic acquisition means described above but also by specifying it in the configuration definition parameter of each FES. The configuration definition parameter is a parameter that defines the system configuration in the distributed transaction, and a list of all FESs, BESs, and JSs that participate in the distributed transaction processing must be defined.

FIG. 12 shows subtransaction registration processing. When a transaction is processed on BES, it is activated as a subtransaction. FIG. 12 shows a process of managing transaction generation and subtransaction registration on the FES side.

When the sub-transaction registration is requested, it is judged (1201) whether it is the first database operation request from the corresponding application. Specifically, the first registration of the AP is judged by judging whether the process number in the transaction management table, that is, the number uniquely assigned to the AP by the operating system has already been registered in the process number in the transaction management table. To do. If it is the first registration, a transaction identifier is generated and the transaction is registered in the transaction management table (12
02) The status information of the generated transaction is set to “in process” (1203), and a sub-transaction management table for managing the transaction is allocated (1204),
The number of JS in the transaction management table is set to 1 (for the master JS targeted by FES), and the JS management table is allocated (1
205).

In step 1201, if the transaction (sub-transaction) is already registered, the above process is not performed.

After the presence or absence of a sub-transaction for the BES processing the database operation statement is determined from the BES name processing the database operation statement and the BES name in the sub-transaction management table (1206), a sub-transaction is generated if not registered. That is, a unique sub-transaction identifier is generated in the transaction and registered in the sub-transaction management table (1207). After the registration is completed or if the sub-transaction already exists, the sub-transaction registration processing is completed.

Next, the commit process (1004) will be described. The commit process is shown in FIGS. 14 to 18.

When a commit request is issued from AP, FES
After sending the commit preparation journal to the master JS (FES journal record JS), the completion report is received.
The recording destination JS transmits a telegram in which the commit preparation instruction for instructing the commit preparation for the same BES group and the traveling destination BES name list are merged. In this patrol, the recording destination JS patrols all the same BES. Finally, after going through the recording destination JS,
The processing result is transmitted to FES. After receiving the completion reports from all the JSs, the commit journal instruction and the commit instruction are circulated. Send the list of JS and BES to the master JS. When the processing result from each round is completed normally, the commit processing is completed and the transaction is completed. The details are shown below.

First, in FIG. 14, the transaction status is set to commit preparation processing (1400), and the commit preparation journal of FES is transmitted to the master JS. The commit preparation journal includes a to-be-listed list that summarizes the to-be-visited BES names and JS names thereafter. This information may be a copy of the sub-transaction management table for this transaction. This information is used when committing or rolling back a sub-transaction when a failure occurs. The processing result from the master JS is received (1402), and it is judged whether the recording is normal (1403). If it is down, try to resend. If normal, assemble a commit preparation request. The number of patrol destinations (the number of JS) is initialized (1404), and J
The following processing is performed for each JS in the S management table. First, the visit destination BE for each BES recorded in the JS journal
The S destination (excluding the first visit destination BES name) and the JS name are edited in the visit destination list (1405). The contents of the transmitted message are as follows.

(1) Message header + commit preparation request (tour destination list) The above-mentioned message is transmitted to the first destination BES (1406).

The above is repeated for the number of JSs registered in the JS management table in the transaction management table. (1408) After sending JS number of times, the commit preparation success flag for judging whether or not the commit preparation is successful as a transaction is turned on (provisionally successful) (1501), and each JS or BE
The processing result from S is received (1502), and the following processing is repeated for the number of JS (1506).

The processing results from JS are as follows.

(1) ack: Commit preparation succeeded in all round destinations (2) nak: Commit processing failed or timed out in at least one rounded destination (no response) When the processing result from JS or BES is received or timed out, etc. Upon detection, it is determined (1503) whether or not the preparations for committing the individual visiting BESs have succeeded. If commit preparation failed at any BES (nak response from BES) or if either BES or JS was down, the commit preparation success flag was turned off (failed) to roll back the transaction (failure) ( 1504).

After determining whether or not the commit preparation has succeeded (1507) based on the commit preparation success flag, if it has failed, rollback processing (1900 and later in FIG. 19)
I do.

If the transaction is successful, the transaction status information is set to the temporary commit decision (1508), and the FES sends a message to the master JS that adds the next cyclic list to the commit request.
(1509, 1510). The tour list is:

(1) List of BES names of JS tours of FES (2) For all other JSs, the JS name is set as the head and the JS
BES name list of the circuit of this transaction The transaction commit journal is transmitted to the JS by this transmission, the journal processing is performed on the transmitting JS side, and the commit request of each JS and the BES belonging to it is circulated to each JS. The commit of this transaction is decided when the commit journal of FES is recorded in the journal file of JS.

When recording of the commit journal is completed via BES and JS, the processing result is received from each JS. Initialization (1601) is performed to count the success flag of the commit and the number of JSs to be visited (set the success flag to success and set the number of JS to 1).

The sender, that is, the JS name of the JS that is the patrol terminal is acquired from the sender in the processing message (1602). In the processing result, the processing result for the commit preparation of each circulating BES is reported, so the processing result is determined (160
3) Do. When the result of all rounds is that the commit preparation processing is completed normally, the round trip message status information of the JS management table corresponding to the JS name is set as ack received (1605). If there is a commit failure in the cyclic results, the commit success flag is turned off (1604), and the cyclic message status information waits for retransmission.

One is added to the number of JS to be visited (1607), and it is determined whether reception is completed by the number of JS to be visited (1608).

In the above case, when the reception restriction time is exceeded due to the reception timer being over, etc., step 1602
An error is reported in the reception processing of No. 1, and the result of the cyclic processing in step 1603 fails.

The commit success flag is used to determine whether or not all the commit rounds have been successful (1609). If successful, transaction status information is free (161
0), the JS management table and the transaction management table used by the transaction are released (1611), and the transaction is completed.

If the commit patrol process partially or completely fails, a failure has occurred on the patrol path, so it is determined whether to commit or roll back the transaction.

It is judged (1701) whether or not there is a response from all the patrol destinations. Specifically, steps 1605 and 1
In 606, it is determined whether all the patrol message status information recorded in the JS management table is waiting for retransmission or only a part thereof (1701).

If there is no response from all the patrols, it is not known which of the master JS, sub JS and BES has a failure. When the master JS has a failure, the commit journal may not be recorded. Whether to commit or roll back a transaction depends on whether the commit journal or abort journal of this transaction is recorded in the journal file of the master JS. Therefore, the FES inquires of the master JS whether the journal of this transaction is recorded in order to determine whether or not this transaction is definitely committed (1702).
I do. When the processing result from JS is received (1703), but there is no response after a certain period of time,
It is considered that the JS is down, and the inquiry is repeated until the master JS recovers (1704).

As the processing result from the master JS, all the journal information related to this transaction recorded in the journal file is transmitted. The transaction processing unit of the FES will add a commit journal (C
After determining (1706) whether J) is recorded, if it is recorded, the commit resend process is performed for each BES. If it is not recorded, the abort journal output process of the master JS is performed to roll back this transaction.

If there is no response from some patrols in the judgment processing of step 1701, recording of the commit journal is completed for at least the master JS. In that case, a commit resend process is performed.

Next, the commit resend process will be described with reference to FIG.

The commit re-send instructs the BES, which is waiting for a commit, to commit. In commit re-transmission, a commit instruction is given to all BESs existing on the patrol destination for which re-transmission is required in the message status information of the journal management table. FIG. 18 shows the commit resend process.

In the commit resending stage, the JS count number (i), the resending JS round number (j) and the commit completion flag are initialized (1801) in order to give a resending instruction. It is determined from the patrol message status information whether or not it is necessary to retransmit to the corresponding patrol destination (180
2) Do. If the retransmission is required, the commit request is transmitted to all BESs to be retransmitted without circulating (1803). 1 is added to the retransmission circulation destination counter (1804), and the number of JS is counted (1805). The above processing is performed for the number of JS (180
6).

The processing result for the commit request is received (1808). When the partner BES is detected to be abnormal due to a reason such as a failure at the time of reception (1809), the commit completion flag is turned off (commit retransmission failure) (181
1). In the case of normal completion, the patrol message status information of the patrol is set as ack reception (1810). The commit completion flag is determined whether or not all the commit retransmissions for the BES on the patrol route in which an error has occurred at the time of commit have been completed (181
4) Do. Judgment result When all the BESs on the tour commit, this transaction shifts to free (16
a).

Next, the FES rollback process will be described with reference to FIG. The FES rollback process is called (1) in the case of a rollback request from the AP, or (2) in the case of failure of the cyclic process during preparation for commit.

Reference numeral 19 in the figure shows a case where the call is made from the above (2).

When the rollback process is started, the transaction state of this transaction is transited to rollback provisional decision (1900). The rollback provisional decision is
Although rollback is decided as a transaction, the abort journal (AJ) is actually unrecorded in the master JS. The FES sends a rollback request to the master JS to record the abort journal (190
1) Do. The above process is repeated until the abort journal is normally recorded by the rollback request (190
2). Next, for the JS and BES that are the patrol routes participating in this transaction, the rollback request and the BES name and JS name other than the first patrol destination BES among all BESs related to a certain JS in the journal server management table are electronically transmitted. Edit (1905). Edit the message to the first destination B
It is sent to the ES (1906).

The above transmission is repeated by the number of destinations, that is, the number of JSs (1907, 1908). As described above, the rollback instruction is issued to all BESs to be rolled back.

Receive the results from each patrol destination. Next in FIG.
The process proceeds to 0, sets the number of JS to be visited to 1, and sets the rollback success flag to the success side (2001). A processing result from a certain JS is received (2002). Detects rollback processing failure or time-out etc. in BES of patrol processing (2
003), and in the case of failure, the rollback success flag is set to off (failure side) (2004). Number of rounds (JS
The above process is repeated for a number of times (2006), and the success / failure of the rollback process is determined for all patrols.

It is judged whether all rollback processing of the transaction has succeeded (2007), and if all the patrols have been completed normally (the rollback success flag is ON (success)), the transaction state is free (200
8) and the transaction is completed. The JS management table and sub-transaction management table required for transaction processing are released (2010), and all processing related to the transaction is completed.

In the rollback success judgment (2007), if the rollback success flag is off (failure), rollback retransmission processing is performed. The rollback retransmission process gives an instruction to confirm rollback. Rollback resend is JS
A rollback instruction is issued to all the BESs existing on the patrol destination for which retransmission is required in the message status information of the management table.

FIG. 13 shows the rollback retransmission process.

At the rollback retransmission stage, the JS count number (i), the number of retransmission JS cycles (j), and the rollback completion flag are initialized to give a retransmission instruction (1301).
To do. Based on the patrol message status information, it is determined (1302) whether or not it is necessary to retransmit to the corresponding patrol destination. If retransmission is required, the rollback request is sent to all BESs to be retransmitted without patrol (13
03) Add 1 to the re-tour destination counter (130
4), the number of JS is counted (1805). The above processing is performed for the number of JS (1306).

The processing result for the rollback request is received (1308). When an abnormality is detected (1309) in the reception due to the other party BES being down or the like, the rollback completion flag is turned off (rollback retransmission failure) (1311). In the case of normal completion, the patrol message status information of the patrol is set as ack reception (1310).
The rollback completion flag is determined (1314) as to whether or not all rollback retransmissions have been completed for the BES on the patrol route in which an abnormality has occurred during rollback. As a result of the determination, when all circulating BESs roll back, this transaction shifts to free (20a).

As shown in the lower left of FIG. 20, in order to recover the transaction state when the BES is down, the transaction recorded from the sub JS is recovered (201
2) Then, the transaction status information is transited to the master JS abort journal judgment stage (2009).

Next, proceeding to FIG. 21, an inquiry transmission request for all journal information relating to the transaction is transmitted to the FES journal recording server, that is, the master JS (2102). The FES receives (2103) the journal information transmission from the master JS. When the receiving master JS fails in journal transmission due to a failure or communication failure (no in 2105), the journal information transmission request is transmitted again. This process is a state in which the request from the FES cannot be processed because the master JS is down and the master JS is recovered or the journal file is full, and basically, it is sufficient to wait until the master JS is recovered. When the journal transmission from the master JS is performed, it is determined whether or not there is an abort journal in the transmission journal (210).
4) Do. If no abort journal exists,
Indicates that the master JS failed during or before recording the abort journal for processing the rollback request, and could not record the abort journal completely and went down.
In this case, the abort journal must be recorded on the master JS in order to surely bring the transaction state into the abort state.
Abort journal recording (2201 in FIG. 22) is performed. The above process is repeated until the normal completion of the abort journal recording is received from the master JS (2202). When the above process ends, the process transitions to the process in FIG. 13 and the rollback retransmission process is performed.

Abort journal presence / absence judgment (2
If an abort journal exists in the inquiry result in (104), the transaction-free processing (20
Transition to a).

The transaction processing in FES has been described above.

Next, transaction processing in BES will be described with reference to FIGS. 23 to 27.

First, in FIG. 23, the BES transaction processing section 2301 waits for the arrival of the first database operation statement by message reception (2302). No transaction has occurred at this stage. A message reception result database operation statement processing request determination (2303) is performed. Although details are omitted in this flow, at the stage where no transaction has occurred, when the processing request is a commit / rollback request processing other than the database processing request, a normal termination message is transmitted (2302). Only when a transaction has occurred, the processes of steps 2304 and 2305 and subsequent steps are performed.

When the processing request for message reception (2302) is the database operation statement processing, the BES database operation statement processing (2304) is called.

The BES database operation statement processing will be described with reference to FIG.

The backend server database operation statement process (2304) determines whether the transaction identifier in the first received message is registered in the transaction management table (2401). If the corresponding transaction is not registered in the transaction management table, the transaction is registered in the transaction management table (2402). At this stage, the transaction starts, and in the transaction, that is, BES, the subtransaction state becomes in process.

A database operation is processed (2403) based on the received database operation statement. After the processing is finished, it is judged whether or not this processing is the first processing request of the transaction (2404).
S merges the JS name recording the journal into the processing result (2
405). By this processing, the FES JS name is received (11
06) is possible.

The processing result is sent to the FES (2406),
The database processing of BES is completed.

Next, the processing when a commit or rollback request is received in the electronic message reception (2302) after processing the database operation statement will be described.

When the received processing request is a commit preparation request (2305), commit preparation processing is performed. This process is a reception process corresponding to the commit cyclic message transmission (1406) in the FES commit process.

The commit suspension process will be described with reference to FIG.

First, the state of this transaction (sub-transaction) is changed to commit pending (2501). A commit preparation process (2502) is performed. As a result of the commit preparation processing, if the commit preparation is completed normally, the commit preparation is transmitted to the next patrol destination (2504). If it fails, the transaction status is set to rollback pending (2601),
The FES is unsuccessfully transmitted (2505) and the process proceeds to step 2508.

At the time of normal completion, the commit preparation journal is then merged (2506) into a circuit message. At this time, the message is (1) before merging (a) message header + commit preparation request (tour destination list)
Or (b) message header + commit preparation request (tour destination list) + commit preparation journal of BES that has traveled before this BES (2) after merge (a) message header + commit preparation request (tour destination list)
+ Commit preparation journal of this BES or (b) message header + commit preparation request (tour destination list) + this BE
BES commit preparation journal that went around before S + book B
It becomes the commit preparation journal of ES.

[0157] In the received message, edit circuit message 1405
The to-be-listed list assembled in is added. The data is transmitted (2507) to the next tour destination in the tour list. The next destination is the BES or sub JS (or master JS). Next, the BES waits for an instruction from the FES by receiving the cyclic telegram from the FES (2508). At this time, the FES determines the commit / rollback after determining the processing result of each round,
The instruction request is cyclically instructed in the order of master JS, sub JS, and BES. As a result, the BES waits for the commit / rollback request message to arrive. After receiving the message, it is determined whether the request is a commit request or a rollback request (2509). In the case of a commit request, commit processing is performed (251
0).

If a message other than the commit request is awaited in the message reception wait (2508), it is determined whether the request is a rollback request (25
13) Do. If it is a rollback request, rollback processing (2314) is performed.

After the above processing, the own BES name is removed from the tour list and the data is sent to the next tour destination (2511). When completed normally, the state transits to 23a and the transaction (sub-transaction) state becomes free (2309). If the transmission is not completed normally, the process proceeds to the transaction partial recovery process (27).

When a message other than the rollback request is awaited in the message reception waiting (2508), there is a possibility that a failure has occurred in any of the routes. In this case, the transaction status transits to the FES judgment (2701), and the FES
A state determination request is transmitted to (2702). In this processing, the BES knows whether the FES decides the state of this transaction, that is, commit / rollback. FE
S looks up the transaction table for this request, checks whether the transaction is commit / rollback / free, and then sends decision information to BES. The BES receives the FES commit / rollback resend request or free notification (2703). If the FES is down (2704), the retransmission request is transmitted again.

According to the resend result, the BES performs the commit process at the time of commit resend, and the rollback process at the time of rollback resend or free notification (2710). Next, the transaction status is changed to sub-JS record (2712). Since the commit / abort journal may not be recorded in the sub JS in some cases, a sub JS journal recording request is sent according to the commit / rollback decision contents (27
05) Yes. On the JS side, the journal recording state is checked according to the request, and if it is not recorded, journal recording is performed. When the sub JS is down, the recording request is transmitted again (2706).

When the journal is recorded, the transaction (sub-transaction) state becomes free (23a).

27 if recovered from BES down
The process is restarted from b (FIG. 27). The transaction status after the restart is the sub-JS judgment (2713). Then, the sub-JS is requested to transfer the journal of the transaction being processed before the down (2707).

When there is a commit preparation journal and a commit journal in the sub-JS journal for a certain transaction (2709), the corresponding transaction becomes free. In the case of only the commit preparation journal (2711), recovery processing from 27 to BES, FES, and JS down is performed. If there is no commit preparation journal, this transaction is in free state (23a)
become.

At 2303, when a rollback is sent as a processing request during transaction generation (2307), rollback processing (2514) is performed.

The transaction processing unit of BES has been described above.

Next, the JS processing will be described with reference to FIGS. 28 and 29.

It is judged whether the transaction in the received electronic message (2802) is in the transaction management table (28
03), and if not, the transaction is registered in the transaction management table (2804).

When the electronic message is received (2805) and the commit preparation instruction is received (2806yes), the commit preparation journal of the BES cyclically merged is recorded in the journal file (2807). The transaction state is transited to commit pending (2808).

Proceeding to FIG. 29, the next tour destination, that is, the master JS
Or send journal recording completion to FES (2900)
To do. Upon receiving (2901) the next message, the FES side determines whether the transaction finally transitions to commit / rollback, and the instruction is received. In the case of a commit request (2902no), master J
If it is S, the commit journal of FES is recorded, then the commit journal of each BES of its own JS is recorded in the journal file (2903), and if the rollback instruction is given, the abort journal is recorded (2904). If there is a patrol route next, the own JS name is removed from the patrol list, and the data is transmitted to the next patrol destination according to the next patrol instruction (2905). Next, the transaction status is released (2908).

When the rollback is instructed by receiving the message (2805) in FIG. 28 (2811 yes), the master JS records the abort journal (AJ) of FES, and then the own JS.
The abort journal of each BES is recorded in the journal file (2809). The transaction status is changed to free (29b).

Finally, a modification of the present invention in which a journal is generated in JS based on the circulating BES and JS information without merging commit preparation journals in the above specific example will be described.

The commit processing on the FES side in FIG. 14 is the same as above. Editing BES and JS telegrams at the destination (140
Using the information of 5), the following JS journal generation is performed. In this case, one piece of BES information of the circulating BES information is the BES name and the sub-transaction identifier, and the circulating destination BES name group includes all the BES names recorded in the journal in the JS.

In the BES transaction processing of FIG. 23, the processing request is the commit preparation, and the commit preparation (2502) is normally completed, and the next round processing request setting (2
504), the message is not merged (2506) of the commit preparation journal and is directly transmitted to the next traveling partner (2).
507) At this time, the destination BES and JS information is F
It is sent as it is sent by the ES.

By such processing, the merging of journals becomes unnecessary. In the above embodiment, the message sent to the JS is as many as the journals (3
204-3206) have been merged. However, in the case of this modification, as shown in FIG.
JS in message format with ES and JS added as parameters
To receive.

[0176] The commit preparation journal record (2807) of the BES that has been cyclically merged by the JS processing is the destination BE that has been received as a parameter when journal merge is not performed.
Each BES based on the information about BES of S and JS information
The commit preparation journal of is generated on the JS side and is recorded in the journal file. This makes it possible to reduce the amount of data transfer by merging journals in the commit preparation.

[0177]

As described above, according to the present invention, it is possible to efficiently perform the two-phase commit process in the distributed transaction process in which the journal server is independent. In particular, it is possible to reduce the number of communications to the journal server and the number of input / output to / from the journal file.

[Brief description of drawings]

FIG. 1 is a block diagram of a distributed transaction processing configuration to which the present invention is applied.

FIG. 2 is a block diagram of a conventional distributed transaction processing configuration.

FIG. 3 is an explanatory diagram of a conventional two-phase commit control method.

FIG. 4 is an explanatory diagram of a two-phase commit control method when using a journal server.

FIG. 5 is an explanatory diagram of a two-phase commit control method according to the present invention.

FIG. 6 is an explanatory diagram of a system configuration of a two-phase commit control method.

FIG. 7 is an explanatory diagram of a transaction management table.

FIG. 8: State transition diagram of front-end server transaction

FIG. 9: State transition diagram of backend server and journal server

FIG. 10 is a flowchart of processing of an application program.

FIG. 11 is a flowchart of processing of a database operation statement execution request.

FIG. 12 is a flowchart of a subtransaction registration process.

FIG. 13 is a diagram of rollback processing 5

FIG. 14 Diagram of commit process 1

FIG. 15: Diagram of commit processing # 2

FIG. 16 is a diagram of commit processing No. 3.

FIG. 17 Diagram of commit processing # 4

FIG. 18 is a diagram of commit processing 5

FIG. 19 is a flowchart of rollback processing 1

FIG. 20 is a flowchart of rollback process 2

FIG. 21 is a flowchart of rollback process 3

FIG. 22 is a flowchart of a rollback process 4

FIG. 23 is a flowchart of back-end server transaction processing No. 1.

FIG. 24 is a flowchart of backend server database operation statement processing.

FIG. 25 is a flowchart of back-end server transaction processing No. 2.

FIG. 26 is a flowchart of back-end server transaction processing No. 3.

FIG. 27 is a flowchart of backend server transaction processing No. 4.

FIG. 28 is a flowchart of journal server processing No. 1.

FIG. 29 is a flowchart of the journal server process No. 2.

FIG. 30 is an explanatory diagram of the format and contents of a journal

FIG. 31 is an explanatory diagram of a modified example of the present invention.

FIG. 32 is an explanatory diagram of a modified example of the present invention.

[Explanation of symbols]

 130 ... Application program 10 ... Front-end server 11, 12, 13 ... Back-end server 21, 22 ... Journal server

Claims (6)

[Claims] 1. A computer that is a coordinator of two-phase commit in a transaction, a computer that processes subtransactions and is a participant, and a journal recorder that records a transaction journal as transaction status history information on a non-volatile recording medium. A two-phase commit control method in a distributed transaction processing system in which a computer that becomes the above is interconnected via a communication network, wherein the coordinator prepares a commit preparation journal for the journal recorder as a first step of the two-phase commit. Is recorded, and a commit preparation request is added to which the visit destination information including all the participant names and the journal recorders is added, and each participant who receives the commit preparation request commits its own commit preparation journal to the commit Preparation Then, the commit preparation request is transmitted to the next round destination, and the last participant merges his or her own commit preparation journal with the commit preparation journal and then sends the commit preparation request to the journal recorder. The journal recorder, after receiving the commit preparation request to which the commit preparation journal of each participant is added, records the commit preparation journals of all the participants, and then reports the fact to the coordinator. As a second stage of the two-phase commit, the coordinator sends a commit request to which the visitor information including all participant names is added to the journal recorder, and the journal recorder receives the commit request. After recording the commit journals of all participants, the commit request is sent to the next destination, and each participant who received the commit request The two-phase commit control method, wherein the participant sequentially transmits the commit request to the next round destination, and the last participant reports to the coordinator that the commit request has been received. 2. In the first stage, when the participant transmits the commit preparation request to the next round destination, the participant name of the participant is deleted from the round destination information and is transmitted. The two-phase commit control method according to claim 1. 3. In the second stage of the two-phase commit, the participant deletes its own participant name and sends it when sending the commit request to the next round destination. The two-phase commit control method according to claim 1. 4. As the second stage of the two-phase commit, the coordinator sends a rollback request to the journal recording person, to which the circulation destination information including all participant names is added, and the journal recording person After receiving the rollback request, recording the rollback journals of all participants, and then transmitting the rollback request to the next round destination, and each participant receiving the rollback request sequentially rolls back the rollback request. 2. The two-phase commit control method according to claim 1, wherein the request is transmitted to the next round destination, and the last participant reports to the coordinator that the rollback request has been received. 5. As the first stage of the two-phase commit, each participant receiving the commit preparation request sends the commit preparation request to the next order without adding its own commit preparation journal to the commit preparation request. The journal recorder receives the commit preparation request, generates and records commit preparation journals for all participants, and then reports the fact to the coordinator. The two-phase commit control method according to claim 1. 6. The journal recording person comprises a coordinator and a main journal recording person who records a journal of a first participant group, and a sub-journal recording person who records a journal of a second participant group. In the first step, a commit preparation request is patrolled between the main journal recorder and the first participant group, and the sub-journal recorder and second journal
Another commit preparation request is patrolled between the participant groups of, and in the second stage, the coordinator sends the commit request to the first participant group and the main journal recorder, 2. The two-phase commit control method according to claim 1, wherein the main journal recorder receiving the commit request transmits the commit request to the second participant group via the sub-journal recorder.