JPH11212917A - Transaction recovery system and its program recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the system reliability by checking the presence or absence of the record which is recovered by another host to prevent the double execution of a transaction and to secure an opportunity for starting a suspended transaction even when the end notification of the transaction is lost. SOLUTION: This transaction recovery system is connected to a host 1 or 2 from a terminal 4 via a communication processor 3 and acquires in sequence the executing transaction processing requests from the terminal 4. If the host has a down during the transactions are successively executed, a TR(transaction) message information confirmation part 15 confirms the transaction execution states which are stored in an execution TR management file 7 and a log file 5 and decides to or not to execute a suspended transaction to suspend and complete the execution processing. Then the suspended transaction is started as necessary.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a transaction recovery system and a program recording medium thereof, and more particularly to a transaction recovery system and a program recording medium in an information processing system in which a plurality of hosts are loosely coupled.

[0002]

2. Description of the Related Art According to a conventional recovery method, for example, according to Japanese Patent Laid-Open Publication No. Hei 3-12773, when a certain processor module becomes abnormal, a recovery processing unit using a shared memory performs recovery. The state is corrected so that the processing can be continued. That is, when the host is down in a case where the transaction processing is completed but the processing completion of the transaction is not notified, only the transaction state is corrected.

[0003] Further, in the conventional interruption recovery method for sequentially executed transactions, when an interruption event of a sequentially executed conversational transaction occurs and a host that is processing a transaction that needs to start an interrupted transaction goes down, processing is interrupted. There is a problem in that when only the state recovery processing of a given transaction is performed and the transaction processing is completed but the completion of the transaction processing is not notified, the processing of starting the suspended transaction is not performed.

In online transaction processing in which a terminal device requests data processing from a terminal device to a host computer via a network, a transaction to be started next is designated by a message at the time of completion of transaction execution, and a series of processing is performed. A transaction performed sequentially by a plurality of transactions is called a conversation transaction.

[0005] While the conversation transaction is running, a failure may occur at the transaction requesting terminal, or an interruption event such as a transaction execution processing stop request due to the intervention of the terminal operator or the center operator may occur. In such a case, a transaction for suspending and completing the process (this is called a suspended transaction) is started. The interrupted transaction is a transaction specified at the time of completion of the previous transaction, and is started by adding a “suspended” message.

In order to manage the state of the conversation transaction execution processing, a log file (hereinafter simply referred to as a log file) for managing the state of a transaction message that can be referred to from each host is used. In this log file, several logs indicating the processing status (reception log: log recorded when a transaction request is made; execution end log: log recorded when a transaction completion notification is received) are prepared. I have.

When an interruption event as described above occurs,
Refer to the log status, immediately start the suspended transaction in the case of "execution end log", record "suspend pending" in the log file in the case of "acceptance log", and confirm the completion of transaction execution. After waiting, start the suspended transaction.

In a loosely coupled system comprising a plurality of hosts and performing recovery on another host when a certain host goes down due to a failure or the like, when a transaction execution request is issued to the transaction processing system, processing is performed for each host. The transaction information is written in a record in a file storing the transaction information (hereinafter, referred to as an execution transaction management file), and the transaction processing system deletes the record in the execution transaction management file when the transaction execution processing is completed. In this way, duplicate execution of transactions during host down recovery is prevented.

In the above-described conversation transaction recovery, a method of controlling the execution transaction management file to prevent the transaction from being double-executed and performing a suspended transaction control by referring to the log file in common between the hosts. is there.

However, when an interrupt event occurs and it is necessary to start the interrupted transaction, the host executing the conversation transaction completes the transaction processing and deletes it from the execution transaction management file. If the system goes down at a time when the completion is not notified, there is a problem that the suspended transaction cannot be started.

[0011]

As described above, in a loosely coupled system, when a host goes down at the timing when transaction processing is completed but not notified, a suspended transaction is started. There is a disadvantage that you can not.

SUMMARY OF THE INVENTION An object of the present invention is to avoid the above-mentioned drawbacks and to check the presence / absence of a record recovered by another host to prevent double execution of a transaction even if the transaction completion notification is lost. It is an object of the present invention to provide a transaction recovery method and a program recording medium for improving the reliability of a system by obtaining a trigger of an interrupted transaction.

[0013]

A transaction recovery system according to the present invention is a transaction recovery system for controlling execution of transaction processing in an information processing system having terminals connected to a plurality of loosely coupled hosts via a communication processing device. A schedule control device, a transaction processing system device that executes transaction processing, a down detection control device that monitors the host and detects a down state, and stores transaction information requested by the transaction schedule control device to the transaction processing system device. A log file to be executed, an execution transaction management file for storing transaction information being processed by the transaction processing system device, and Line transaction management; and a message queue file that stores the message file structured to own another host when the host is down to recover the reference aborted transaction processing the message queue file.

Further, in the transaction recovery method according to the present invention, the transaction schedule control device includes a transaction execution status log control unit that updates the log file in accordance with sequentially executed transaction processing, and the down detection control device is a host. A recovery control unit that writes back the message of the execution transaction management file to the message queue file when detecting the down of the transaction, and a transaction message information confirmation unit that refers to the message queue file and determines whether to start the suspended transaction. It comprises.

Further, in the transaction recovery system according to the present invention, the transaction processing system device includes a processing end storage unit for updating the execution transaction management file when the transaction processing ends.

Further, according to the transaction recovery method of the present invention, a processing end storing means for updating the execution transaction management file at the end of the transaction processing, and a transaction for referring to the message queue file to determine whether or not to start an interrupted transaction Message information confirmation means.

Further, the program recording medium of the transaction recovery system of the present invention is a program recording medium for controlling execution of transaction processing in an information processing system having terminals connected to a plurality of loosely coupled hosts via a communication processing device. One step, a second step of executing a transaction process, a third step of monitoring the host and detecting its down, and storing transaction information required by the first step to the second step. A log file to be executed, an execution transaction management file storing transaction information being processed by the second step, and a message queue storing a message of the execution transaction management file when the third step detects that the host is down. File and own host There recover the transaction process another host is interrupted by referring to the message queue file when down.

The program recording medium may further comprise a fourth step of updating the execution transaction management file at the end of the transaction processing, and a fifth step of referring to the message queue file to determine whether to start a suspended transaction. Steps.

That is, according to the transaction recovery method of the present invention, the sequentially executed transaction processing state is managed by the log file. When a message is input from the terminal, a log corresponding to the transaction execution state is recorded in a log file by the transaction execution state log control unit. The logs to be recorded are a "reception log" indicating that a transaction request is made and an "execution end log" indicating that the transaction execution processing has been completed. The initial value of the log is “execution end log”.

When a failure occurs in the terminal that has issued the transaction request, or when an interruption event such as a request to stop the transaction execution processing due to the intervention of the terminal operator or the center operator occurs, the interrupted transaction is executed to interrupt and complete the processing. Is started. The suspended transaction refers to the information in the log file, immediately starts the suspended transaction in the case of "execution end log", and records "suspend pending" in the log file in the case of "acceptance log", After waiting for the completion of the execution of the transaction, the suspended transaction is started.

In the transaction processing system device, transaction execution processing is performed, and when the execution processing is completed, the processing end storage unit records “T
"E record".

The down detection controller detects the down of the host. When the down of the host is detected, the recovery control of the recovery host returns the message stored in the execution transaction management file of the down host to the message queue file.

If the message read from the message queue file contains a "TE record", the log status in the log file is checked. If it is "acceptance log", the transaction completion notification is lost. Judgment has been made, and the log state is corrected to "execution end log". If “suspend pending” is recorded, the suspend transaction is immediately started and a suspend event is requested. In this way, it is possible to activate a suspended transaction whose completion notification is lost.

[0024]

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below with reference to the drawings.

FIG. 1 is a block diagram showing an embodiment of the present invention. In the figure, the transaction recovery method according to the present invention is described as follows (hereinafter, transaction is referred to as TR
May be abbreviated. ) Loosely coupled multiple hosts 1
Schedule control device 11 for controlling the execution of the TR process, a TR processing system device 12 for executing the TR process, and the host And a log file 5 storing the TR information requested by the TR schedule control device to the TR processing system device, and the TR information being processed by the TR processing system device. And a message queue file 6 for storing a message of the execution TR management file when the down detection control device detects a host down.
When the own host goes down, the other host refers to the message queue file and recovers the interrupted TR process.

The TR schedule control unit 11 updates the log file in accordance with the sequentially executed transaction processing. The TR execution state log control unit 14 is configured to execute the above processing when the down detection control unit detects that the host is down. The system includes a recovery control unit 16 for writing back the message of the execution TR management file to the message queue file, and a TR message information confirmation unit 15 for referring to the message queue file to determine whether to start an interrupted transaction.

The TR execution state log control unit 14 manages the processing state of the sequentially executed transaction by recording the processing state of the sequentially executed transaction in the log information in the log file 5. The log information includes an “acceptance log” that is recorded when a transaction request is made, an “execution end log” that is recorded when a transaction completion notification is received, and an interrupted transaction started after waiting for completion of transaction execution. I need to "
"Suspend pending".

When a downed host is detected, the recovery control section 16 returns the message stored in the execution TR management file to the message queue file.

The TR message information confirming unit 15 detects a lost completion notification based on the information of the message queue file and the log file, and starts a suspended transaction.

Further, the TR processing system device 12 has a processing end storage unit 17, and when the processing is completed, the processing end storage unit 17 records the processing completion information in the record information of the execution TR management file.

The host 2 has the same functions and functions as the host 1.
It has a configuration.

FIG. 2 is an explanatory diagram showing the record format of the execution TR management file 7 and the message queue file 6.
FIG. 3 is an explanatory diagram showing the record format of the log file 5. Hereinafter, the operation of the transaction recovery method will be described with reference to FIGS.

When a message is input from the terminal 4, the message is notified to the TR schedule control device 11 via the communication processing device 3.

The TR schedule control device 11 uses the TR execution status log control unit 14 to transmit the notified transaction information to the log information of the log file 5 (see FIG. 3).
As “acceptance log”. Further, it requests the TR processing system device 12 to execute a transaction.

When the TR processing system apparatus 12 completes the transaction execution processing, the processing result storage section 17 reads the processing result (see FIG. 2) in the execution TR management file 7 into “
TE record ", and notifies the TR schedule control device 11 of the completion of the process.

The TR schedule control device 11, which has received the completion notification from the TR processing system device 12, sets the log information of the log file 5 to "execution end log" by the TR execution state log control unit 14.

When an interruption event occurs, the TR schedule control unit 11 is instructed to schedule an interruption transaction. In response to this instruction, the TR schedule control device 11 refers to the log information of the log file 5 by the TR execution status log control unit 14, and immediately starts the interrupted transaction if it is the "execution end log", In the case of “acceptance log”, “suspension pending” is recorded in the log information of the log file 5.

Here, when the TR processing system apparatus 12 notifies the transaction in the "suspend pending" state of the completion of the processing, the TR schedule control unit 11 starts the suspended transaction.

When the host 1 in the loosely coupled system goes down, the down detection of the host 2 detects that the host 1 is down. When the down is detected, the message stored in the execution TR management file 7 of the host 1 is returned to the message queue file 6 by the recovery control unit of the host 2.

Subsequently, the TR message information confirmation section of the host 2 reads the message from the message queue file 6 and determines whether or not a "TE record" is recorded in the record.

If the "TE record" is not recorded, it is determined that the transaction has not been executed, and the T
It instructs the R schedule control device to reschedule the transaction.

When the "TE record" is described, the TR message information confirmation section of the host 2 refers to the log information in the log file 5, and when the log information is "accepted log", the transaction information It is determined that the completion notification has been lost, and the log state is corrected to “execution end log”.

If it is recorded as "suspend pending", the suspension transaction is immediately started.

The above-described transaction recovery method operates by executing a program stored in a main memory (not shown) of the host. This program is stored in a recording medium such as a hard disk or a floppy disk, and can be configured to be loaded into the main memory of the host when the transaction system is started and executed when necessary.

[0045]

As described above in detail, according to the present invention, a host executing a sequentially executed transaction can
Transaction schedule control because information on the completion of transaction processing is stored in the execution transaction management file, and whether a transaction completion notification has been lost during host down recovery can be checked to determine whether a transaction has been completed. The reliability of the device can be improved.

[Brief description of the drawings]

FIG. 1 is a block diagram showing one embodiment of an embodiment of the present invention.

FIG. 2 is an explanatory diagram showing a record format of an execution transaction management file.

FIG. 3 is an explanatory diagram showing a record format of a log file.

[Explanation of symbols]

 1, 2 Host 3 Communication processing device 4 Terminal 5 Log file 6 Message queue file 7 Execution TR management file 11 TR schedule control device 12 TR processing system device 13 Down detection control device 14 TR execution status log control unit 15 TR message information confirmation unit 16 Recovery control unit 17 Processing end storage unit

Claims (6)

[Claims] In an information processing system having terminals connected to a plurality of loosely coupled hosts via a communication processing device, a transaction schedule control device for controlling execution of transaction processing, and a transaction process for executing transaction processing A system unit;
A down detection controller for monitoring the host and detecting its down, a log file for storing transaction information requested by the transaction schedule controller to the transaction processing system, and transaction information being processed by the transaction processing system. And a message queue file for storing a message of the execution transaction management file when the down detection control device detects a host down, and when the own host goes down, the other host A transaction recovery method that refers to a message queue file and recovers interrupted transaction processing. 2. The transaction recovery method according to claim 1, wherein the transaction schedule control device updates the log file in accordance with sequentially executed transaction processing, and the down detection control device. A recovery control unit that writes back the message of the execution transaction management file to the message queue file when the host detects that the host is down, and a transaction message information check unit that refers to the message queue file and determines whether to start a suspended transaction. And a transaction recovery method. 3. The transaction recovery method according to claim 1, wherein the transaction processing system device includes a processing end storage unit that updates the execution transaction management file when the transaction processing ends. 4. The transaction recovery method according to claim 1, wherein a processing end storage unit for updating said execution transaction management file at the end of transaction processing, and referring to said message queue file to determine whether to start an interrupted transaction. And a transaction message information confirming means. 5. An information processing system having a terminal connected to a plurality of loosely coupled hosts via a communication processing device, a first step of controlling execution of transaction processing, and a second step of executing transaction processing. And a third step of monitoring the host and detecting its down state; a log file storing the transaction information requested by the first step to the second step; An execution transaction management file for storing transaction information in the server; and a message queue file for storing a message of the execution transaction management file when the third step detects that the host is down, and when the host is down. Another host is referring to the message queue file A program recording medium of a transaction recovery method for recovering a lost transaction process. 6. The transaction recording program recording medium according to claim 5, wherein a fourth step of updating the execution transaction management file at the end of the transaction processing, and referring to the message queue file to start an interrupted transaction. And a fifth step of determining whether or not the program recording medium is a transaction-recovery-type program recording medium.