JPH08235039A - History information analysis method for transaction processing - Google Patents

Abstract

PURPOSE: To quickly recover the transactions in a decentralized transaction processing system by collating two or more history information produced during the processing of the same transaction with each other. CONSTITUTION: All AP(application program) 10 gives an instruction to a TM (transaction manager) 11 via a TX interface 13 for the end of a transaction. Thus the TM 11 performs the 2-phase commitment processing to an RM(resource manager) 12 and writes this processing result in the history record related to the corresponding transaction included in a TM history file 17. At the same time, every RM 12 writes the result of the 2-phase commitment in the history record related to the corresponding transaction included in an RM history file 19. Then the TM 11 retrieves the file 19 with the XID (transaction ID) included in the file 17 used as a key and then collates the coincident transactions with each other to check the coincidence between both information showing the decision of transactions.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a distributed transaction processing system, and more particularly to a method for analyzing history information created during transaction processing.

[0002]

2. Description of the Related Art As an interface specification of a distributed transaction processing system, a DTP (Distributed Transa) defined by a standardization organization X / Open.
There is known an XA interface specification between a transaction manager (TM) and a resource manager (RM) based on the action processing model. The XA interface specifications do not depend on hardware or other software specifications, so T
By connecting M and RM to each other, one distributed transaction processing system can be constructed. The XA interface is described, for example, in Nikkei Computer 1991.10.7, page 93.

However, since the specifications of the history information output by TM and RM are not specified, there is a problem that it is not easy to perform transaction recovery processing based on these individually created history information.

[0004]

According to the prior art, T
Since the data formats of the M history information and the RM history information are different, it is not easy to determine whether the transaction settlements at the time of ending the transaction processing are consistent by referring to the history information of both. there were.

An object of the present invention is to overcome the difference in data format and collate the history information of TM with the history information of RM corresponding to the same transaction.

[0006]

[Means for Solving the Problems] The global transaction ID in the XID (transaction ID) allocated by the TM for each transaction is a unique,
Moreover, since the information is common to the TM and the RM, the present invention searches the RM history information by using the global transaction ID included in the TM history information as a key, and the information indicating the settlement of the transaction for the matching transaction is provided. It is characterized by a history information analysis method for checking whether or not they match.

[0007]

When a transaction processing decision is different between the TM history information and the RM history information due to a hardware failure, a software failure, a communication failure or the like that occurs during transaction processing, the transaction requiring recovery processing Can be extracted as

[0008]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings.

FIG. 1 is a block diagram of a distributed transaction processing system according to the DTP model defined by X / Open. TM (Transaction Manager) 11
From the AP (application program) 10 to TX
In response to a transaction instruction issued via the interface 13, the transaction start and end processes are performed, and the TM history file 17 is retained, and the recovery process is performed when there is a failure. The RM (Resource Manager) 12 is a database management system that manages access to the database 18 in response to an instruction regarding the database 18 made from the AP 10 via the SQL interface 16, and stores the RM history file 19 in the database. Possess. Although only one RM 12 is shown in the figure, two or more independent RMs 12 each managing a different database 18 may be provided. XA interface 1
Reference numeral 4 is an interface when the TM 11 calls the RM 12. AX interface 15 is RM12
This is the interface when calling TM11 from. Note that FIG. 1 shows a functional configuration of the system, and each component does not necessarily correspond to one hardware device. For example, this system can be realized by one information processing device, and AP
The 10, TM 11 and each RM 12 may be distributed to different information processing devices connected to each other through a communication line.

AP 10 initiates a transaction,
When the TM 11 is instructed to start a transaction via the TX interface 13, the TM 11 allocates an XID (transaction ID) for this transaction and creates a history record regarding this transaction in the TM history file 17. Then TM11
When the RM 12 is instructed to start a transaction via the XA interface 14, the RM 12 creates a history record regarding this transaction in the RM history file 19. The AP 10 then instructs the RM 12 via the SQL interface 16 to access the database 18. When the AP 10 instructs the TM 11 via the TX interface 13 to end the transaction, T
The M11 performs the two-phase commit process via the XA interface 14 and the AX interface 15, and writes the result in the history record regarding the transaction in the TM history file 17. Also each RM12 is 2
The result of the phase commit is written in the history record of the transaction on the RM history file 19.

FIG. 2 is a diagram showing an example of the data format of the history record in the TM history file 17. XID30
Is information including a global transaction ID that TM11 allocates at the start of a transaction. C / R
Reference numeral 31 is an area for storing information indicating the settlement of a transaction, and stores a value indicating whether it is a commit settlement, a rollback settlement, or another. The date 32 is an area that is made up of two entries and stores the start time and end time of a transaction. The pid 33 is an area for storing the process ID of the process assigned when the transaction is executed. rmi
d34 is an area for storing an ID for identifying the RM 12. The rmid 34 is an ID indicating which RM is accessed for each process, and each R in which TM11 is used
Allocate to M12 and notify the RM12. After that, the TM 11 designates the RM 12 by the rmid, and the RM 12 saves it as an ID indicating itself until the process ends. In addition to the above, the history record stores information in the TM 11 during the transaction processing as a history.

FIG. 3 is a diagram showing an example of the data format of the history record in the RM history file 19. FIG. 3 particularly illustrates items common to the history records on the TM history file 17. In addition to these items in the history record, the RM 12 that is processing the transaction
The information in is stored as a history. For example, the RM 12 includes a transaction ID locally set for the transaction. The items common to the TM history file 17 may have the same contents but different item names from the TM history file 17. Further, it is possible that the arrangement order of the items and the item names are different between the RMs 12.

FIG. 4 is a diagram further expanding the data format of the XID defined by X / Open, and each element is represented by the structure of the programming language C.
formatID indicates the type of format and is 0. gtrid_length is gtrid
(Global transaction ID) size, bq
ual_length is the size of bqual (transaction branch ID), and data is data including gtrid and bqual.

FIG. 5 is a diagram showing a data format when a history record common to the TM history file 17 and all RM history files 19 is assumed. This common history information extracts data items common to the TM history file 17 and the RM history file 19 and used for failure recovery. If the items have the same content but different item names or data formats, the content is once converted into the item name and data format of the common history information and then used in the failure recovery process. The XID 30 is used as a primary key when searching the history file. Other item names are used as subkeys.

FIG. 6 is a flowchart showing the processing flow of the failure recovery program using the TM history file 17 and the RM history file 19. First, the variables i and j are initialized to 0 (step 50), and then TM11
The TM history file 17 is read and the number of stored history records, that is, the number of transactions is counted (step 51). This transaction number is n
And Next, the RM history file 19 of the RM 12 is read (step 52). Next, i is compared with n, and if i <n (step 53T), the gtrid (global transaction ID) of XID30 of the history record read from the TM history file 17 is read as a key from the RM history file 19. Search history records,
When there is a matching history record, the contents of the C / R 31 are compared with each other to check whether they match (step 54). At this time, if the data formats of the item names or contents of the XID 30 and the C / R 31 are different, they are once converted into the data format of the common history information and then the two are collated. When a failure occurs during transaction processing, inconsistency occurs in the C / R 31 for that transaction. If the contents of the corresponding C / R 31 match (step 54T), i is incremented to i + 1 (step 55) and the process returns to step 53. Gt that matches the gtrid of the history record read from the TM history file 17
If the history record of the RM history file 19 having the rid is not found, or if the contents of the C / R31 of the corresponding history record do not match (step 54F), the mismatched gtrid is registered and j is set to j + 1. Increment (step 56) and go to step 55. When collation of all history records read from the TM history file 17 is completed in this way (step 53F),
Go to step 57.

When j exceeds 0 (step 57)
T), transaction recovery processing is performed based on the registered gtrid, and j is decremented to j-1 (step 58). That is, since it is sufficient to recover the process from the transaction in which the inconsistency has occurred, the process returns to the checkpoint corresponding to the process of the transaction, and the recovery process is performed by referring to the checkpoint information. When the recovery processing of all transactions is completed (step 57F), the processing is completed. When there are two or more RM history files 19 of the RM 12, it is checked whether the C / R 31 of all the corresponding history records match based on the gtrid of the history record of the TM history file 17. Further, the history record of the same transaction can be searched using date32, pid33, or rmid34 as a subkey to analyze the failure information. Also in this case, if the data format of the item name or the content differs depending on the history file, it is used after being once converted to the data format of the common history information. The failure recovery program is a program attached to TM11, and the processing is executed by an appropriate information processing device.

FIG. 7 shows a corresponding history record 61 in the RM history file 19 using gtrid in the XID included in the history record 60 in the TM history file 17 as a key.
It is a figure explaining a mode that searches for.

[0018]

According to the present invention, the history information is retrieved using the global transaction ID as a key.
The corresponding transaction settlement information can be compared with the RM history information, and a quick transaction recovery process can be performed.

[Brief description of drawings]

FIG. 1 is a configuration diagram of a distributed transaction processing system based on a DTP model.

FIG. 2 is a diagram showing a data format of a TM history record.

FIG. 3 is a diagram showing a data format of an RM history record.

FIG. 4 is a diagram showing a data format of XID.

FIG. 5 is a diagram showing a data format of a common history record.

FIG. 6 is a flowchart showing a processing flow of a failure recovery program.

FIG. 7 is a diagram illustrating a manner in which a history record is searched using gtrid as a key.

[Explanation of symbols]

11 ... TM (Transaction Manager), 12
... RM (Resource Manager), 17 ... TM history file, 19 ... RM history file, 30 ...
XID (Transaction ID), 31 ... C / R
(Transaction settlement result)

Claims (1)

[Claims] 1. A method for analyzing TM history information output by a transaction manager (TM) and RM history information output by a resource manager (RM), the global transaction ID included in the TM history information. A history information analysis method in transaction processing, wherein the RM history information is searched by using as a key, and whether or not the information indicating the settlement of the transactions for the matching transactions is matched is verified.