Distributed transaction management device and distributed transaction management method

Abstract

To provide a distributed transaction management device and a distributed transaction management method that can prevent an increase in a storage area of a transaction log while ensuring consistency of a distributed transaction.SOLUTION: A distributed transaction management device records a transaction settlement result log that indicates a settlement result of a transaction in a distributed transaction system. The distributed transaction management device deletes, when receiving a rollback processing completion notification from any one of a plurality of resource management units participating in the transaction, the rollback transaction conclusion result log.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a distributed transaction management device and a distributed transaction management method. [Background technology]

[0002] The adoption of microservices architecture is beginning. Microservices architecture is an architectural style that builds software systems as a collection of small, independent services. Each service is responsible for a specific business function or set of functions, and each runs as its own process. Enterprise systems are also coming into the scope of microservices architecture, and data consistency under distributed transactions that guarantee the consistency of data update processing across multiple services is becoming necessary. For this reason, distributed transaction control functions for microservices are being developed.

[0003] XA is one of the representative specifications for distributed transactions. In XA, it is possible to maintain data consistency between services by using an agreement protocol called two-phase commit. In this two-phase commit, if the transaction conclusion is determined to be a commit, the log is persisted (the log is saved in persistent storage), but if the transaction conclusion is determined to be a rollback, the log is not persisted. If a recovery request is made in a state where there is no log, it is determined to be a rollback. Patent Documents 1 and 2 disclose systems that execute transaction processing using two-phase commit. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2010-157202 A [Patent Document 2] Japanese Patent Application Publication No. 8-235039 Summary of the Invention [Problem to be solved by the invention]

[0005] In the case of the two-phase commit of the conventional technology, in a cloud or container environment, delays can cause the order of processing (for example, the order of the prepare vote and the recovery request) to be reversed. In this case, the rollback decision of the recovery request and the prepare vote for committing are inconsistent. To maintain transaction consistency, the log must be persisted even if a rollback decision is made.

[0006] On the other hand, the capacity of the storage used to persist the log is limited, and after the transaction processing is completed, the log must be deleted from the storage to free up the storage space. In the conventional two-phase commit, in the case of a rollback, this log deletion process was not necessary, but in the case of persistence, this process is newly required.

[0007] Therefore, a distributed transaction system that deletes transaction settlement result logs can be considered as follows.

[0008] This distributed transaction system includes a distributed transaction manager and multiple databases. In a first phase, if prepare is successful in all databases, the distributed transaction manager records a commit in the transaction settlement result log, and if prepare is not successful in all databases, records a rollback in the transaction settlement result log. In a second phase, the distributed transaction manager instructs the databases of the settlement result (commit or rollback), and the databases commit or roll back. When commit or rollback is complete in all databases, the distributed transaction manager deletes the transaction settlement result log and frees up the storage area.

[0009] To delete the transaction settlement result log, it is necessary to confirm that "all databases have completed commit or rollback." For this reason, the distributed transaction manager needs to know which databases are participating in the transaction.

[0010] In the case of a commit, it is a prerequisite that all databases report a successful prepare to the distributed transaction manager, so the distributed transaction manager keeps track of all databases participating in the transaction.

[0011] On the other hand, in the case of a rollback, the success or failure of the prepare may not reach the distributed transaction manager due to a timeout or the like, so the distributed transaction manager does not necessarily have knowledge of all databases participating in the transaction.

[0012] This means that it is not possible to confirm that rollback has been completed in all databases participating in the transaction, making it difficult to determine the timing for deleting the transaction settlement result log, which results in an increase in the storage area for the transaction log.

[0013] There is a method, such as the conventional technology (Patent Document 1), that does not record rollback information. In the conventional technology, if a rollback is determined as the transaction settlement, the log is not persisted. In the conventional technology, if a recovery request is made in a state where there is no log, it is determined to be a rollback. This method does not cause a problem with consistency if there is no contention between the commit process and the recovery process. However, in a cloud or container environment with large delays, it may conflict with the commit process and affect consistency, so it is not suitable.

[0014] SUMMARY OF THE PRESENT EMBODIMENT It is therefore an object of the present invention to provide a distributed transaction management device and a distributed transaction management method that can prevent an increase in the storage area of ​​a transaction log while guaranteeing the consistency of a distributed transaction. [Means for solving the problem]

[0015] In order to solve the above problems, the distributed transaction management device of the present invention is applied to a distributed transaction system in a specific environment, and is equipped with a storage device that records a transaction settlement result log indicating the settlement result of a transaction in the distributed transaction system, and includes an information processing device that manages the transaction settlement result log.In the distributed transaction management device, the information processing device is configured to delete the transaction settlement result log of the rollback when it receives a rollback processing completion notification from any one of a plurality of resource management units participating in the transaction.

[0016] The distributed transaction management device of the present invention is applied to a distributed transaction system in a specific environment, and is equipped with a storage device that records a transaction settlement result log indicating the settlement result of a transaction in the distributed transaction system, and in the distributed transaction management device including an information processing device that manages the transaction settlement result log, the information processing device is configured to delete the rollback transaction settlement result log a certain time after the rollback transaction settlement due to a recovery request from a plurality of resource management units participating in the transaction.

[0017] The distributed transaction management device of the present invention is applied to a distributed transaction system, and is equipped with a storage device that records a transaction settlement result log indicating the settlement results of transactions in the distributed transaction system, and in the distributed transaction management device including an information processing device that manages the transaction settlement result log, the information processing device is configured to use transaction identification numbers having a magnitude relationship as a transaction identifier for identifying the transaction, convert consecutive transaction identification numbers corresponding to settled transactions into range information indicating a range of the consecutive transaction identification numbers, and associate used information indicating that the transaction settlement result log has been used with the converted range information, thereby compressing the transaction settlement result log to create a compressed log, and record the compressed log in the storage device.

[0018] The distributed transaction management method of the present invention is applied to a distributed transaction system in a specific environment, and is equipped with a storage device that records a transaction settlement result log indicating the settlement result of a transaction in the distributed transaction system.In this distributed transaction management method using an information processing device that manages the transaction settlement result log, when the information processing device receives a rollback processing completion notification from any one of a plurality of resource management units participating in the transaction, it deletes the transaction settlement result log of the rollback.

[0019] The distributed transaction management method of the present invention is applied to a distributed transaction system in a specific environment, and is equipped with a storage device that records a transaction settlement result log indicating the settlement result of a transaction in the distributed transaction system.In this distributed transaction management method, which uses an information processing device that manages the transaction settlement result log, the information processing device deletes the transaction settlement result log of the rollback a certain time after the transaction settlement of the rollback due to a recovery request from a plurality of resource management units participating in the transaction.

[0020] The distributed transaction management method of the present invention is applied to a distributed transaction system, and includes a storage device that records a transaction settlement result log indicating the settlement results of transactions in the distributed transaction system. In this distributed transaction management method using an information processing device that manages the transaction settlement result log, the information processing device uses transaction identification numbers having a magnitude relationship as a transaction identifier for identifying the transaction, converts consecutive transaction identification numbers corresponding to settled transactions into range information indicating a range of the consecutive transaction identification numbers, and associates used information indicating that the transaction settlement result log has been used with the converted range information, thereby compressing the transaction settlement result log to create a compressed log, and records the compressed log in the storage device. Effect of the Invention

[0021] According to the present invention, it is possible to prevent an increase in the storage area for transaction logs while ensuring the consistency of distributed transactions. [Brief description of the drawings]

[0022] [Figure 1] FIG. 1 is a system configuration diagram showing an example of the configuration of a system including a distributed transaction management device according to a first embodiment of the present invention. [Diagram 2] FIG. 2 is a schematic diagram showing an example of the configuration of a transaction manager device. [Diagram 3] FIG. 3 is a diagram illustrating an example of the log. [Figure 4] FIG. 4 is a schematic diagram showing an example of the configuration of a computer. [Diagram 5] FIG. 5 is a sequence diagram for explaining a transaction manager, a resource manager, and processes executed by the resource manager of the reference example. [Figure 6]FIG. 6 is a sequence diagram for explaining the processes executed by the transaction manager, the resource manager (1), and the resource manager (2) according to the first embodiment of the present invention. [Figure 7] FIG. 7 is a flowchart showing the process flow executed by the transaction manager. [Figure 8] FIG. 8 is a flowchart showing a process flow executed by the resource management unit. [Figure 9] FIG. 9 is a diagram for explaining an example of the log. [Figure 10] FIG. 10 is a sequence diagram for explaining the processes executed by the transaction manager, the resource manager (1) and the resource manager (2) according to the second embodiment of the present invention. [Figure 11] FIG. 11 is a flowchart showing the process flow executed by the transaction manager. [Figure 12] FIG. 12 is a system configuration diagram showing an example of the configuration of a system including a distributed transaction management device according to the third embodiment of the present invention. [Figure 13] FIG. 13 is a diagram for explaining the compressed log. [Figure 14A] FIG. 14A is a diagram for explaining an overview of a distributed transaction management device according to the third embodiment. [Figure 14B] FIG. 14B is a diagram for explaining an overview of a distributed transaction management device according to the third embodiment. [Figure 15] FIG. 15 is a sequence diagram for explaining the operations of the transaction start processing unit, the transaction management unit, and the resource management unit. [Figure 16] FIG. 16 is a flowchart showing the process flow executed by the transaction manager. [Figure 17] FIG. 17 is a flowchart showing the flow of the log compression process executed by the transaction manager. [Figure 18] FIG. 18 is a system configuration diagram showing an example of the configuration of a system including a distributed transaction management device according to the fourth embodiment of the present invention. [Figure 19] FIG. 19 is a diagram for explaining the compressed log. [Figure 20A] FIG. 13 is a diagram for explaining an overview of a distributed transaction management device according to a fourth embodiment. [Figure 20B] FIG. 13 is a diagram for explaining an overview of a distributed transaction management device according to a fourth embodiment. [Figure 21] FIG. 21 is a sequence diagram for explaining the operations of the transaction start processing unit (1), the transaction start processing unit (2), and the transaction management unit. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] Hereinafter, each embodiment of the present invention will be described with reference to the drawings. In addition, in all the drawings of the embodiments, the same or corresponding parts may be given the same reference numerals. In the following description, various information may be described using expressions such as "table", "record", "column", and "row", but the various information may be expressed using data structures other than these. Furthermore, when describing identification information, expressions such as "identification number", "identifier", and "name" are used, but these are mutually interchangeable. Furthermore, in the following description, processing may be described using a functional block as the subject, but the subject of the processing may be a CPU or a device instead of a functional block.

[0024] <<First embodiment>> FIG. 1 is a system configuration diagram showing an example of the configuration of a system (distributed transaction system) including a distributed transaction management device 100 (hereinafter referred to as "transaction management device 100") according to a first embodiment of the present invention. As shown in FIG. 1, the system includes the transaction management device 100 and computers (1) 200-1 to (N) 200-N. The transaction management device 100 and the computers (1) 200-1 to (N) 200-N are connected to each other via a network NW1 so as to be able to communicate with each other. Hereinafter, the computers (1) 200-1 to (N) 200-N will be referred to as "computers 200" when there is no particular need to distinguish between them. The computers (1) 200-1 to (N) 200-N include resource management units (1) 211-1 to resource management units (N) 211-N. When there is no need to particularly distinguish between the resource management units (1) 211-1 to (N) 211-N, they are referred to as the "resource management unit 211." The system may be a system of a microservice architecture.

[0025] Fig. 2 is a schematic diagram showing a configuration example of the transaction manager device 100. As shown in Fig. 2, the transaction manager device 100 includes a non-volatile storage device 110 from which data can be read and written, a memory 120 (e.g., RAM), a CPU 130, an input / output interface 140, and a network interface 150. These are connected to each other via a bus 160 so as to be able to communicate with each other.

[0026] For convenience, the device including the CPU 130, the storage device 110, the memory 120, the input / output interface 140, the network interface 150, and the bus 160 is also referred to as an "information processing device." The information processing device may be a virtual information processing device constructed on a plurality of information processing devices or a cloud, or may be a virtual environment such as a container.

[0027] The storage device 110 holds (memorizes, stores) a program 111 and a log 112. The program 111 includes a transaction manager 111a and a transaction start processor 111b.

[0028] The transaction manager 111a executes transaction completion processing (commit or rollback). Commit confirms the success of the transaction and guarantees the data updated within the transaction. Rollback cancels changes made by the transaction and restores data updated within the transaction to the state before the update. The transaction start processor 111b assigns a transaction identifier to identify the transaction (for example, a number to identify the transaction (hereinafter sometimes referred to as a "TR identification number")) and starts the transaction. Note that there may be multiple transaction start processors 111b.

[0029] The transaction manager 111a records the TR identification number, which is a transaction identifier, in a log 112 to manage the transaction.

[0030] In FIG. 2, the transaction manager 111a and the transaction origin processing unit 111b are included in a single device, but the transaction manager 111a and the transaction origin processing unit 111b may each be included in a separate device, as in the third embodiment (FIG. 12) and the fourth embodiment (FIG. 18) described below.

[0031] The CPU 130 loads the program 111 stored in the storage device 110 into the memory 120. The CPU 130 executes the program 111 loaded into the memory 120 to realize various functions of a transaction manager 111a and a transaction start processing unit 111b.

[0032] The log 112 includes a log (information) related to a transaction. The details of the log 112 will be described later.

[0033] In the memory 120, the program 111 to be executed by the CPU 130 is loaded as described above, and data used when the CPU 130 executes the program 111 is temporarily stored.

[0034] The input / output interface 140 is an interface for connecting operation devices such as a keyboard and a mouse, a display, etc. The network interface 150 is an interface for connecting the transaction management device 100 to the network NW1.

[0035] 3 is a diagram illustrating an example of the log 112. The log 112 includes, as columns for storing information (values), a transaction identifier 112a, a settlement result 112b, and a list of resource management identifiers 112c.

[0036] In the log 112, information corresponding to each column regarding the settlement result of the transaction is stored as information (records) in row units in association with each other. Specifically, the transaction identifier 112a stores a TR identification number, which is a transaction identifier for identifying the transaction. The settlement result 112b stores a commit or rollback indicating the settlement result of the transaction. In the following, the commit or rollback stored in the settlement result 112b may be referred to as a "settlement result log" or a "transaction settlement result log" for convenience. In the list of resource manager identifiers 112c, when the corresponding settlement result is a commit, identification information of the resource manager 211 that committed the transaction is stored. When the corresponding settlement result is a rollback, identification information of the resource manager 211 that participated in the transaction may be stored if the resource manager 211 is known.

[0037] Fig. 4 is a schematic diagram showing an example of the configuration of a computer 200. As shown in Fig. 4, the computer 200 includes a non-volatile storage device 210 from / to which data can be read / written, a memory 220 (e.g., RAM), a CPU 230, an input / output interface 240, and a network interface 250. These are connected to each other via a bus 260 so as to be able to communicate with each other.

[0038] For convenience, the device including the CPU 230, the storage device 210, the memory 220, the input / output interface 240, the network interface 250, and the bus 260 is also referred to as an "information processing device." The information processing device may be a virtual information processing device constructed on a plurality of information processing devices or a cloud, or may be a virtual environment such as a container.

[0039] The storage device 210 holds (memorizes, stores) a resource manager 211. The resource manager 211 is composed of a database, a program for managing the database (e.g., a DBMS: Database Management System), a program for providing a message queue system, a program for providing a file system, etc. The resource manager 211 executes data processing requested by a transaction on the database, executes a message queue, searches for data files, updates data files, etc.

[0040] The CPU 230 loads the program stored in the storage device 210 into the memory 220. The CPU 230 executes the program loaded into the memory 220 to realize the function of the resource manager 211.

[0041] As described above, the programs executed by the CPU 230 are loaded into the memory 220, and data used when the CPU 230 executes the programs is temporarily stored therein.

[0042] The input / output interface 240 is an interface for connecting operation devices such as a keyboard and a mouse, a display, etc. The network interface 250 is an interface for connecting the computer 200 to the network NW1.

[0043] <Summary> First, in order to facilitate understanding of the present invention, the problem to be solved by the present invention will be described. Fig. 5 is a sequence diagram for explaining the processes executed by the transaction manager 111a, the resource manager (1) 211-1, and the resource manager (2) 211-2 of the reference example.

[0044] 5, in two-phase commit transaction processing, if the system is in a specific environment, processing delays, communication delays, etc. may cause processing order changes in one of the multiple resource management units 211 (resource management unit (1) 211-1 in this example). Processing order changes mean that rollback processing (S508) due to a recovery request (S506) occurs before the arrival of a transaction completion instruction (S511) based on the conclusion of the transaction by prepare success / failure voting.

[0045] Here, the specific environment is an environment in which a situation may arise in which a reordering of processing does not occur in resource management units 211 other than the resource management unit 211 in which a reordering of processing in which a rollback processing due to a recovery request occurs first occurs before the arrival of a transaction completion instruction based on the settlement of the transaction by the prepare success / failure vote. The specific environment is, for example, an environment in which (1) recovery processing invocation timeout period TR1 + minimum value of recovery request communication time < maximum value of prepare success / failure vote communication time TP, and (2) maximum value of prepare success / failure vote communication time TP < processing delay time TR2 for invoking recovery processing is satisfied.

[0046] The "recovery process invocation timeout time TR1" is a reference time for determining whether or not to invoke a recovery process. If there is no commit instruction from the transaction manager 111a before the recovery process invocation timeout time TR1 has elapsed after the prepare success / failure vote, the resource manager 211 invokes a recovery process after the recovery process invocation timeout time TR1 has elapsed. The timing at which a recovery process is invoked after the recovery process invocation timeout time TR1 has elapsed differs depending on the processing performance of each resource manager 211, etc.

[0047] The "minimum recovery request communication time" is the minimum communication time from when the resource manager 211 sends a recovery request (for example, S506) until the recovery request reaches the transaction manager 111a. Note that the "recovery request communication time" is not a fixed time by its nature but changes, so it is a time that has a range from a minimum value to a maximum value.

[0048] The "maximum value of prepare success / failure vote communication time TP" is the maximum communication time from when the resource manager 211 sends the prepare success / failure vote to the transaction manager 111a (for example, S504) until it arrives at the transaction manager 111a. Note that the "prepare success / failure vote communication time TP" is by its nature not a fixed time but changes, so it is a time that has a range from a minimum value to a maximum value.

[0049] The "processing delay time TR2 of recovery process invocation" refers to the delay time from the time when recovery process is first invoked among the multiple resource management units 211 to the time when recovery process is next invoked. In other words, when the first recovery process is invoked in any of the resource management units 211, it refers to the time (delay time) from the time when the recovery process is invoked to the time when recovery process is expected to be invoked in the other resource management units 211. In this example, since the resource management unit (1) 211-1 invokes recovery process first (S505), the time from the time when recovery process is invoked in the resource management unit (1) 211-1 (S505) to the time when recovery process is expected to be invoked in the resource management unit (2) 211-2 (not shown) is the "processing delay time TR2 of recovery process invocation."

[0050] If (1) holds, for example, it may happen that the arrival time of the first recovery request (S506) from any of the resource managers 211 (in this example, resource manager (1) 211-1) that first triggered the recovery process is earlier than the arrival time (S510) of the prepare success / failure vote of any of the resource managers 211 (in this example, resource manager (1) 211-1). Furthermore, if (1) holds, it may happen that after the transaction manager 111a estimates the transaction to be rolled back (S507), it then settles the transaction to commit by the transaction settlement based on the prepare success / failure vote (S510) (for example, when the communication time of the rollback instruction (S507) and the communication time of the commit instruction (S511) are minimum, etc.). Furthermore, when (2) is established, the arrival time of the commit instruction (S511) at the other resource manager 211 (in this example, the resource manager (2) 211-2) may be earlier than the expected time of initiation of recovery processing of the other resource manager (in this example, the resource manager (2) 211-2), or the arrival time of the commit instruction (S511) at the other resource manager 211 (in this example, the resource manager (2) 211-2) may be earlier than the arrival time of a rollback instruction at the resource manager (2) 211-2 when recovery processing is also initiated in the resource manager (2) 211-2 (that is, a state may occur in which recovery processing is initiated in the resource manager (2) 211-2, but the rollback instruction is delayed). In other words, when (2) is established, the order of processing is not changed in the other resource manager (2) 211-2.

[0051] In this way, when the system is in a specific environment, if a change in the processing order occurs only in the resource management unit (1) 211-1 which first initiated the recovery process, there may be an inconsistency between the rollback decision in response to the recovery request from the resource management unit (1) 211-1 (S506) and the prepare vote indicating committable (S510), which may result in a transaction inconsistency.

[0052] Specifically, when the system is in a specific environment, the transaction manager 111a, the resource manager (1) 211-1, and the resource manager (2) 211-2 execute the processes from S501 to S513 described below in order.

[0053] S501: The transaction manager 111a issues a prepare command to the resource manager (1) 211-1 and the resource manager (2) 211-2 participating in the transaction.

[0054] S502: In response to a prepare instruction from the transaction manager 111a, the resource manager (1) 211-1 executes a prepare process (that is, a process of putting a transaction into a prepared state in which it can be committed or rolled back).

[0055] S503: The resource manager (2) 211-2 executes the prepare process in response to the prepare instruction from the transaction manager 111a.

[0056] S504: The resource manager (1) 211-1 transmits a prepare success / failure vote indicating either the success of the prepare process (prepare successful) or the failure of the prepare process (prepare unsuccessful) to the transaction manager 111a.

[0057] S505: The resource manager (1) 211-1 initiates a recovery process. The recovery process is a process for recovering the system's consistency when a transaction is interrupted midway or a failure occurs. For example, the recovery process is initiated when there is no commit instruction from the transaction manager 111a until a predetermined time (recovery process invocation timeout time TR1) has elapsed after the prepare success / failure vote. In this example, a delay in transmitting the prepare success / failure vote to the transaction manager 111a has caused a delay in the arrival of the commit instruction (S511) from the transaction manager 111a to the resource manager (1) 211-1, so the recovery process is initiated.

[0058] S506: The resource manager (1) 211-1 sends a recovery request to the transaction manager 111a.

[0059] S507: The transaction manager 111a receives a recovery request from the resource manager (1) 211-1. Since the log (settlement result log) for this transaction does not exist in the log 112, the transaction manager 111a assumes a rollback and sends a rollback instruction to the resource manager (1) 211-1. Note that the transaction manager 111a does not record the log (settlement result log) in the log 112.

[0060] S508: Upon receiving the rollback instruction from the transaction manager 111a, the resource manager (1) 211-1 performs rollback processing.

[0061] S509: Due to a processing delay, after the prepare process is completed, the resource manager (2) 211-2 sends a prepare success / failure vote to the transaction manager 111a at a later timing than the resource manager (1) 211-1 sends the prepare success / failure vote.

[0062] S510: The transaction manager 111a receives prepare success / failure votes from the resource manager (1) 211-1 and the resource manager (2) 211-2. Since all of the received prepare success / failure votes indicate prepare success, the transaction manager 111a decides to commit and records the commit in the decision result 112b of the log 112.

[0063] S511: The transaction manager 111a sends a commit instruction to the resource manager (1) 211-1, and sends a commit instruction to the resource manager (2) 211-2.

[0064] S512: Even if the resource manager (1) 211-1 receives a commit instruction from the transaction manager 111a, the resource manager (1) 211-1 does nothing because the rollback process has already been completed.

[0065] S513: Upon receiving the commit instruction from the transaction manager 111a, the resource manager (2) 211-2 performs the commit process.

[0066] When the transaction manager 111a, the resource manager (1) 211-1, and the resource manager (2) 211-2 operate as described above to process a transaction, the resource manager (1) 211-1 performs a rollback and the resource manager (2) 211-2 performs a commit, resulting in transaction inconsistency.

[0067] Therefore, in the transaction management device 100 according to the first embodiment, in order to prevent transactions from becoming inconsistent, even if the transaction conclusion result is a rollback, a transaction conclusion result log of rollback is recorded in the log 112 (S607 in FIG. 6, which will be described later). This makes it possible to prevent transactions from becoming inconsistent.

[0068] On the other hand, when the rollback transaction settlement result log is recorded in log 112, in order to avoid an increase in the memory area for storing log 112, it becomes necessary to delete the rollback transaction settlement result log, which was not necessary in the conventional technology.

[0069] In order to delete the transaction settlement result log, it may become necessary to use the transaction settlement result log until the transaction processing is completed, so it is necessary to confirm that the transaction processing is completed (i.e., "all databases (resource management units 211) have completed commit or rollback"). For this reason, one approach is that the transaction management unit 111a needs to know which resource management units (1) 211-1 and (2) 211-2 are participating in the transaction.

[0070] Based on this concept, when a transaction is completed with a commit, the transaction manager 111a keeps track of all of the resource managers (1) 211-1 and resource managers (2) 211-2 participating in the transaction. Therefore, when the transaction manager 111a receives notification of the completion of commit processing from all resource managers 211, it deletes the transaction settlement result log of the commit.

[0071] On the other hand, in the case of a rollback, the prepare success / failure vote itself may not reach the transaction manager 111a due to a timeout or the like, so the transaction manager 111a does not necessarily have knowledge of all resource managers 211 participating in the transaction.

[0072] For this reason, it is not possible to confirm that rollback has been completed in all resource management units 211 participating in the transaction, and it becomes difficult to specify the timing for deleting the transaction settlement result log. Therefore, if the timing for deleting the transaction settlement result log of the rollback is not determined, the storage area for storing the log 112 will increase.

[0073] Therefore, the transaction management device 100 according to the first embodiment deletes the transaction settlement result log of rollback at the timing described below. That is, the transaction management unit 111a of the transaction management device 100 deletes the transaction settlement result log of rollback from the log 112 when it receives a notice of rollback processing completion from any one of the multiple resource management units 211 participating in the transaction. In a particular environment, after the point in time when it receives a notice of rollback processing completion from any one of the multiple resource management units 211 participating in the transaction, there is no longer a need for the transaction management unit 111a to use the transaction settlement result log, so it is deleted at this timing.

[0074] Here, a specific environment is an environment in which a situation may arise in which in a resource management unit 211 other than the resource management unit 211 in which a reordering of processes that results in a rollback process due to a recovery request first occurred before the arrival of a transaction completion instruction based on the settlement of the transaction by a prepare success / fail vote, a reordering of processes does not occur for more than a certain period of time from the settlement of the transaction due to the recovery request of the activated recovery process (the point at which the rollback settlement result is recorded in the log 900).

[0075] The specific environment is, for example, an environment in which the following holds: (1) recovery process invocation timeout period TR1 + minimum of recovery request communication time < maximum of prepare success / failure voting communication time TP, (2) maximum of prepare success / failure voting communication time TP < recovery process invocation processing delay time TR2, and (3) maximum of prepare success / failure voting communication time TP < recovery process required time TS2. Note that the recovery process required time TS2 is the minimum of the recovery process invocation timeout period TR1 + minimum of recovery request communication time + minimum of the commit or rollback instruction communication time + rollback processing time + minimum of the commit or rollback processing completion notification communication time, and is an arbitrary time determined according to the processing delay time, etc.

[0076] This enables the transaction management device 100 to guarantee the consistency of distributed transactions while preventing an increase in the storage area of ​​the log 112. Furthermore, in order to delete the rollback transaction settlement result log, the transaction management unit 111a only needs to determine the time point at which it receives a notification of rollback processing completion from one of the resource management units 211 participating in the transaction, so the transaction management device 100 can delete the rollback transaction settlement result log in a simple manner.

[0077] <Activation> Hereinafter, an operation of the transaction management device 100 according to the first embodiment of the present invention will be described. Fig. 6 is a sequence diagram for explaining the processes executed by the transaction management unit 111a, the resource management unit (1) 211-1, and the resource management unit (2) 211-2 according to the first embodiment of the present invention.

[0078] The transaction manager 111a, the resource manager (1) 211-1, and the resource manager (2) 211-2 execute the processes from S601 to S615 described below in order.

[0079] S601: The transaction manager 111a issues a prepare command to the resource manager (1) 211-1 and the resource manager (2) 211-2 which are participating in the transaction.

[0080] S602: The resource manager (1) 211-1 executes the prepare process in response to the prepare instruction from the transaction manager 111a.

[0081] S603: The resource manager (2) 211-2 executes the prepare process in response to the prepare instruction from the transaction manager 111a.

[0082] S604: The resource manager (1) 211-1 sends a prepare success / failure vote to the transaction manager 111a.

[0083] S605: When the recovery process invocation timeout period TR1 has elapsed from the time when the prepare success / failure vote was transmitted, the resource manager (1) 211-1 initiates the recovery process.

[0084] S606: The resource manager (1) 211-1 sends a recovery request to the transaction manager 111a.

[0085] S607: The transaction manager 111a checks whether or not a log (settlement result log) related to the transaction exists in the log 112. If a log (settlement result log) related to the transaction does not exist in the log 112, the transaction manager 111a presumes a rollback and records the rollback in the settlement result 112b of the log 112.

[0086] S608: The transaction manager 111a sends a rollback instruction to the resource manager (1) 211-1.

[0087] S609: Upon receiving the rollback instruction from the transaction manager 111a, the resource manager (1) 211-1 performs rollback processing.

[0088] S610: After the prepare process is completed, the resource manager (2) 211-2 sends a prepare success / failure vote to the transaction manager 111a at a later timing than the resource manager (1) 211-1 sends the prepare success / failure vote.

[0089] S611: The transaction manager 111a receives prepare success / failure votes from the resource manager (1) 211-1 and the resource manager (2) 211-2. The transaction manager 111a checks the log (settlement result log) related to the transaction, and if the log (settlement result log) exists in the log 112, instructs the transaction to be processed based on the settlement result log in the log 112, regardless of the result of the received prepare success / failure vote. In this case, since a rollback is recorded in the settlement result 112b in the log 112, the transaction manager 111a sends a rollback instruction to the resource manager (1) 211-1 and the resource manager (2) 211-2.

[0090] S612: Even if the resource manager (1) 211-1 receives a rollback instruction from the transaction manager 111a, the resource manager (1) 211-1 does nothing because the rollback process has already been completed.

[0091] S613: Upon receiving the rollback instruction from the transaction manager 111a, the resource manager (2) 211-2 performs rollback processing.

[0092] S614: The resource manager (1) 211-1 sends a rollback processing completion notification to the transaction manager 111a.

[0093] S615: When the transaction manager 111a receives a rollback processing completion notification from the resource manager (1) 211-1, it deletes from the log 112 the log (row (record)) that includes the settlement result log (rollback) for the transaction.

[0094] S616: The resource manager (2) 211-2 sends a rollback processing completion notification to the transaction manager 111a.

[0095] 7 is a flowchart showing the process flow executed by the transaction manager 111a. The transaction manager 111a starts the process from step 700, and after sequentially executing the processes of steps 705 and 710 described below, proceeds to step 715.

[0096] Step 705: The transaction manager 111a sends a prepare command to the resource managers 211 participating in the transaction.

[0097] Step 710: The transaction manager 111a receives a message from the resource manager 211.

[0098] When the transaction manager 111a proceeds to step 715, it determines whether or not the message is a recovery request. If the message is a recovery request, the transaction manager 111a determines "YES" in step 715 and proceeds to step 720 to determine whether or not a log (settlement result log) for the transaction that is the subject of the recovery request has been recorded in the log 112.

[0099] If the log (settlement result log) for the transaction that is the target of the recovery request has not been recorded in log 112, the transaction manager 111a determines "NO" in step 720 and proceeds to step 725. In step 725, since the log (settlement result log) for the transaction that is the target of the recovery request has not been recorded in log 112, the transaction manager 111a presumes that the settlement of the transaction will be rolled back, and records the rollback settlement result in settlement result 112b of log 112.

[0100] Thereafter, the transaction manager 111 a proceeds to step 730 , where it sends an instruction corresponding to the settlement result in the log 112 to the resource manager 211 , and returns to step 710 .

[0101] On the other hand, for example, after recovery processing is initiated in resource management unit (1) 211-1 and the rollback settlement result is recorded in log 112 (step 725), if recovery processing is initiated in resource management unit (2) 211-2 and a recovery request is made by resource management unit (2), the log (settlement result log) has already been recorded in log 112. In this way, if the log (settlement result log) for the transaction that is the subject of the recovery request has already been recorded in log 112 in step 720, the transaction management unit 111a determines "YES" in step 720 and proceeds directly to step 730, executes the processing of step 730 described above, and then returns to step 710.

[0102] If the message is not a recovery request in step 715, transaction manager 111a determines "NO" in step 715 and proceeds to step 735 to determine whether the message is a prepare success / failure vote.

[0103] If the message is a prepare success / fail vote, transaction manager 111a judges "YES" in step 735 and proceeds to step 740 to judge whether a log for the transaction (settling result log) has been recorded in log 112 or not.

[0104] If a log (settling result log) for the transaction has already been recorded in log 112, transaction manager 111a judges "YES" in step 740 and proceeds to step 730, where it executes the process of step 730 described above, and then returns to step 710.

[0105] On the other hand, if a log (settling result log) for the transaction has not been recorded in log 112, transaction manager 111a judges "NO" in step 740 and proceeds to step 745 to determine whether the prepare success / failure vote is prepare negative.

[0106] If the prepare success / failure vote is negative, the transaction manager 111a judges in step 745 to be "YES" and proceeds to step 750, where it records the rollback settlement result in the settlement result 112b of the log 112, then proceeds to step 730, executes the processing of step 730 described above, and then returns to step 710.

[0107] If the prepare success / failure vote indicates prepare success, the transaction manager 111a judges "NO" in step 745 and proceeds to step 755 to determine whether prepare success / failure votes have arrived from all resource managers 211 participating in the transaction and whether all of those prepare success / failure votes are successful (prepare successful).

[0108] If prepare success / failure votes have arrived from all of the resource managers 211 participating in the transaction and all of these prepare success / failure votes are successful, the transaction manager 111a determines "YES" in step 755 and proceeds to step 760. When the transaction manager 111a proceeds to step 760, all of the voting results from the resource managers 211 participating in the transaction are prepare success, so the transaction is settled as committed and the commit settlement result is recorded in settlement result 112b of log 112. The transaction manager 111a then proceeds to step 730, executes the process of step 730 described above, and returns to step 710.

[0109] On the other hand, if prepare success / failure votes have not arrived from all of the resource managers 211 participating in the transaction, the transaction manager 111 a determines “NO” in step 755 and returns to step 710 .

[0110] If, in step 735 described above, the message is not a prepare success / fail vote, the transaction manager 111a determines "NO" in step 735 and proceeds to step 765 to determine whether the message is a rollback processing completion notice.

[0111] If the message is a rollback processing completion notification, the transaction manager 111a determines "YES" in step 765 and proceeds to step 770, where it deletes the log for that transaction (the row (record) including the rollback settlement result log) from the log 112, and then returns to step 710. If the message is not a rollback processing completion notification, the transaction manager 111a determines "NO" in step 765 and proceeds to step 775, where it determines whether the message is the final commit processing completion notification from a resource manager 211 participating in the transaction, based on the list of resource manager identifiers 112c in the log 112 (list of resource managers 211 participating in the transaction).

[0112] If the message is the final commit processing completion notification, the transaction manager 111a determines "YES" in step 775 and proceeds to step 770, where it deletes the log for that transaction (the row (record) including the commit settlement result log) from the log 112 and then returns to step 710. If the message is not the final commit processing completion notification, the transaction manager 111a determines "NO" in step 775 and returns to step 710.

[0113] By executing the above processing flow, when a recovery request is made for a transaction and a settlement result log for the transaction does not exist in log 112, the transaction management unit 111a assumes a rollback and records (stores) the rollback in the settlement result 112b corresponding to the transaction identifier 112a of that transaction in log 112.

[0114] If at least one of the prepare success / failure votes is denied, the transaction manager 111a rolls back the settlement of the transaction, and records (stores) the rollback in the settlement result 112b corresponding to the transaction identifier 112a of that transaction in the log 112.

[0115] When the transaction manager 111a receives a notification of the completion of rollback processing from any one of the resource managers 211 participating in the transaction, it deletes the log of that transaction (the row (record) containing the transaction settlement result log (rollback) corresponding to the transaction identifier) ​​from the log 112.

[0116] If all of the prepare success / failure votes indicate a prepare success, the transaction manager 111a determines that the transaction has been settled as a commit, and records (stores) the commit in the settlement result 112b corresponding to the transaction identifier 112a of the transaction in the log 112.

[0117] When the transaction manager 111a receives a commit processing completion notification from all of the resource managers 211 participating in the transaction, it deletes the log of that transaction from the log 112 (the row (record) corresponding to the transaction identifier).

[0118] By recording and deleting the transaction settlement result log in this way, the transaction manager 111a can prevent an increase in the storage area for recording the log 112 while ensuring the consistency of the distributed transaction.

[0119] 8 is a flowchart showing the process flow executed by the resource manager 211. The resource manager 211 starts the process from step 800, and proceeds to step 825 after sequentially executing the processes from step 805 to step 820 described below.

[0120] Step 805: The resource manager 211 receives the prepare command from the transaction manager 111a.

[0121] Step 810: The resource manager 211 executes the prepare process.

[0122] Step 815: The resource manager 211 sends a prepare success / fail vote to the transaction manager 111a.

[0123] Step 820: The resource manager 211 receives a recovery process invocation timeout event or an instruction from the transaction manager 111a.

[0124] When the resource manager 211 proceeds to step 825, it judges whether the event is a recovery process invocation timeout. Note that a recovery process invocation timeout is a state in which a recovery process is invoking timeout TR1 has elapsed since the time when the prepare success / fail vote was sent, and recovery process is invoking.

[0125] If the event is a recovery process invocation timeout, the resource manager 211 judges “YES” in step 825 and proceeds to step 830 to send a recovery request to the transaction manager 111 a , and then returns to step 820 .

[0126] If the event is not a recovery process invocation timeout, the resource manager 211 determines "NO" in step 825 and proceeds to step 835 to determine whether or not a commit process or a rollback process has been completed.

[0127] If the commit process or rollback process has been completed, the resource manager 211 determines “YES” in step 835 and proceeds to step 840 to send a settlement process completion notification to the transaction manager 111 a , and then returns to step 820 .

[0128] If neither the commit process nor the rollback process has been completed (that is, if neither the commit process nor the rollback process has been completed), the resource management unit 211 determines “NO” in step 835 and proceeds to step 845 .

[0129] In step 845, the resource manager 211 determines whether the instruction from the transaction manager 111a is a commit instruction.

[0130] If the instruction from the transaction manager 111a is not a commit instruction, the resource manager 211 judges "NO" in step 845, executes the processes of steps 850 and 855 described below in order, and then returns to step 820.

[0131] Step 850: The resource manager 211 executes the rollback process.

[0132] Step 855: The resource manager 211 sends a rollback processing completion notification to the transaction manager 111a.

[0133] If the instruction from the transaction manager 111a is a commit, the resource manager 211 judges "YES" in step 845, executes the processes of steps 860 and 865 described below in order, and then returns to step 820.

[0134] Step 860: The resource manager 211 executes the commit process.

[0135] Step 865: The resource manager 211 sends a commit processing completion notification to the transaction manager 111a.

[0136] <Effects> As described above, the transaction management device 100 according to the first embodiment of the present invention can prevent an increase in the storage area of ​​the log 112 (transaction log) while ensuring the consistency of distributed transactions. Furthermore, the transaction management device 100 can delete the transaction settlement result log of rollback in a simple manner.

[0137] <<Second embodiment>> A transaction management device 100 according to a second embodiment of the present invention will be described. The transaction management device 100 according to the second embodiment holds (stores, holds) a log 900 shown in FIG. 9, instead of the log 112 shown in FIG. 3. As shown in FIG. 9, the log 900 includes a transaction identifier 112a, a settlement result 112b, a list of resource management identifiers 112c, and a recording time 112d as columns for storing information (values). The transaction identifier 112a, the settlement result 112b, and the list of resource management identifiers 112c are the same as those in the log 112 shown in FIG. 3. The recording time 112d stores the time when the log (settlement result log) was recorded.

[0138] <Activation> Hereinafter, an operation of the transaction manager device 100 according to the second embodiment of the present invention will be described. Fig. 10 is a sequence diagram for explaining the processing executed by the transaction manager 111a, the resource manager (1) 211-1, and the resource manager (2) 211-2 according to the second embodiment of the present invention.

[0139] In a particular environment, within a certain time from the rollback transaction settlement (S1008) due to a recovery request (S1007), the resource management unit (2) 211-2 may change the order of processing, but after a certain time has elapsed from the rollback transaction settlement (the point at which the rollback settlement result is recorded in the log 900) (S1008), the order of processing does not change.

[0140] Here, a specific environment is an environment in which a situation may arise in which in a resource management unit 211 other than the resource management unit 211 in which a reordering of processes that results in a rollback process due to a recovery request first occurred before the arrival of a transaction completion instruction based on the settlement of the transaction by a prepare success / fail vote, a reordering of processes does not occur for more than a certain period of time from the settlement of the transaction due to the recovery request of the activated recovery process (the point at which the rollback settlement result is recorded in the log 900).

[0141] The specific environment is, for example, an environment in which: (1) recovery process initiation timeout period TR1 + minimum value of recovery request communication time < maximum value of prepare success / failure voting communication time TP, (2) maximum value of prepare success / failure voting communication time TP < processing delay time TR2 for recovery process initiation, and (3) maximum value of prepare success / failure voting communication time TP < recovery process initiation timeout period TR1 + minimum value of recovery request communication time + log retention time TS3. Note that the log retention time TS3 is a time equivalent to the above-mentioned fixed time, and is an arbitrary time determined according to the processing delay time, etc. In such a specific environment, the transaction management unit 111a, the resource management unit (1) 211-1, and the resource management unit (2) 211-2 of the transaction management device 100 according to the second embodiment sequentially execute the processes of S1001 to S1013 described below.

[0142] S1001: The transaction manager 111a issues a prepare command to the resource manager (1) 211-1 and the resource manager (2) 211-2 which are participating in the transaction.

[0143] S1002: The resource manager (1) 211-1 executes the prepare process in response to the prepare instruction from the transaction manager 111a.

[0144] S1003: The resource manager (2) 211-2 executes the prepare process in response to the prepare instruction from the transaction manager 111a.

[0145] S1004: The resource manager (1) 211-1 sends a prepare success / failure vote to the transaction manager 111a.

[0146] S1005: The resource manager (2) 211-2 sends a prepare success / failure vote to the transaction manager 111a.

[0147] S1006: The resource manager (1) 211-1 initiates recovery processing because the recovery processing initiation timeout time TR1 has elapsed since the prepare success / failure vote was sent. The resource manager (2) 211-2 also times out because the recovery processing initiation timeout time TR1 has elapsed since the prepare success / failure vote was sent. However, the recovery processing is not initiated at the same time because the timing of the recovery processing initiation in the resource manager (2) 211-2 is shifted from the timing of the recovery processing in the resource manager (1) 211-1. Such a shift in the activation of recovery processing occurs because the activation of recovery processing after the timeout in the resource manager (2) 211-2 is delayed. Until the log retention time TS3 has elapsed from the transaction settlement of the rollback due to the recovery request, the recovery processing may also be initiated in the resource manager (2) 211-2, so it is necessary to retain the rollback settlement result log within this log retention time TS3.

[0148] S1007: The resource manager (1) 211-1 sends a recovery request to the transaction manager 111a.

[0149] S1008: The transaction manager 111a checks whether or not a settlement result log for the transaction exists in the log 900. If a log for the transaction (settlement result log) does not exist in the log 900, the transaction manager 111a presumes a rollback and records the rollback in the settlement result 112b of the log 900.

[0150] S1009: The transaction manager 111a sends a rollback instruction to the resource manager (1) 211-1.

[0151] S1010: Upon receiving the rollback instruction from the transaction manager 111a, the resource manager (1) 211-1 performs rollback processing.

[0152] S1011: The transaction manager 111a receives prepare success / failure votes from the resource manager (1) 211-1 and the resource manager (2) 211-2. The transaction manager 111a checks the log (settlement result log) related to the transaction, and if the log (settlement result log) exists in the log 900, instructs the transaction to be processed based on the settlement result log in the log 900, regardless of the result of the received prepare success / failure vote. In this case, since a rollback is recorded in the settlement result 112b in the log 900, the transaction manager 111a sends a rollback instruction to the resource manager (1) 211-1 and the resource manager (2) 211-2.

[0153] S1012: Even if the resource manager (1) 211-1 receives a rollback instruction from the transaction manager 111a, the resource manager (1) 211-1 does nothing because the rollback process has already been completed.

[0154] S1013: Upon receiving the rollback instruction from the transaction manager 111a, the resource manager (2) 211-2 performs rollback processing.

[0155] S1014: Since a certain amount of time (log retention time TS3) has elapsed since the time when the rollback settlement result log was recorded (the time stored in recording time 112d), the transaction management unit 111a deletes the log (row (record)) containing the settlement result log (rollback) for the transaction from log 900.

[0156] In a particular environment, when a certain time (log retention time TS3) has elapsed since the time when the rollback settlement result log was recorded in log 900 (S1008), and the processing order is no longer changed in the resource management unit (2) 211-2, even if the rollback settlement result log is retained in log 900, there is no need to use the rollback settlement result log (there will be no opportunity to use it).

[0157] On the other hand, within a certain time (log retention time TS3) from the time when the rollback settlement result log was recorded in the log 900 (S1008), the order of processing may be changed in the resource manager (2) 211-2. For this reason, the transaction manager 111a needs to hold the rollback settlement result log during that time. Therefore, the transaction manager 111a of the transaction manager device 100 according to the second embodiment holds the rollback settlement result log until the certain time (log retention time TS3) has elapsed from the time when the rollback settlement result log was recorded in the log 900 (S1008), and deletes the log (row (record)) including the rollback settlement result log from the log 900 when the certain time (log retention time TS3) has elapsed from the time when the rollback settlement result log was recorded in the log 900 (S1008).

[0158] Fig. 11 is a flowchart showing the process flow executed by the transaction manager 111a. This flowchart is the same as the flowchart in Fig. 7 except that step 710 in Fig. 7 is replaced by step 1110 and step 765 in Fig. 7 is replaced by step 1120. Therefore, the following explanation will focus on the differences from Fig. 7.

[0159] After executing the process of step 705 described above, the transaction manager 111a proceeds to step 1110, where it either receives a message or waits for the log retention time TS3 to elapse, and then proceeds to step 715 described above.

[0160] If the transaction manager 111a judges "NO" in the processing of step 735 described above and proceeds to step 1120, it judges whether or not the log retention time TS3 has elapsed.

[0161] If the log retention time TS3 has elapsed, the transaction manager 111a judges "YES" in step 1120 and proceeds to step 770, executes the process of step 770 described above, and then returns to step 1010. If the log retention time TS3 has not elapsed, the transaction manager 111a judges "NO" in step 1120 and proceeds to step 775 described above.

[0162] By executing the above processing flow, when a recovery request is made for a transaction and a settlement result log for the transaction does not exist in log 900, the transaction manager 111a assumes a rollback and records (stores) the rollback in the settlement result 112b corresponding to the transaction identifier 112a of that transaction in log 900, and records the recording time in record time 112d.

[0163] If at least one of the prepare success / failure votes is denied, the transaction manager 111a rolls back the settlement of the transaction, and records (stores) the rollback in the settlement result 112b corresponding to the transaction identifier 112a of that transaction in the log 900.

[0164] The transaction management unit 111a deletes the log of the transaction (the row (record) containing the transaction settlement result log (rollback) corresponding to the transaction identifier) ​​from the log 900 after a certain amount of time (log retention time TS3) has elapsed since the rollback settlement result log was recorded.

[0165] If all of the prepare success / failure votes indicate a prepare success, the transaction manager 111a determines the conclusion of the transaction as a commit, and records (stores) the commit in the conclusion result 112b corresponding to the transaction identifier of the transaction in the log 900.

[0166] When the transaction manager 111a receives a commit processing completion notification from all of the resource managers 211 participating in the transaction, it deletes the log of that transaction (the row (record) corresponding to the transaction identifier) ​​from the log 900.

[0167] By recording and deleting the transaction settlement result log in this way, the transaction manager 111a can prevent an increase in the storage area for recording the log 900 while ensuring the consistency of the distributed transaction.

[0168] <Effects> As described above, the transaction management device 100 according to the second embodiment of the present invention can prevent an increase in the storage area of ​​the log 900 (transaction log) while ensuring the consistency of distributed transactions.

[0169] <<Third embodiment>> A description will be given of a distributed transaction management device (1) 100-1 and a distributed transaction management device (2) 100-2 according to a third embodiment of the present invention. FIG. 12 is a system configuration diagram showing a configuration example of a system (distributed transaction system) including a distributed transaction management device (1) 100-1 and a distributed transaction management device (2) 100-2 according to the third embodiment of the present invention. Hereinafter, the "distributed transaction management device (1) 100-1" will be referred to as the "transaction management device (1) 100-1", and the distributed transaction management device (2) 100-2 will be referred to as the "transaction management device (2) 100-2". When there is no particular need to distinguish between the transaction management device (1) 100-1 and the transaction management device (2) 100-2, they will be referred to as the "transaction management device 100".

[0170] 12, the system includes a transaction manager device (1) 100-1, a transaction manager device (2) 100-2, and computers (1) 200-1 through (N) 200-N. The transaction manager device (1) 100-1, the transaction manager device (2) 100-2, and the computers (1) 200-1 through (N) 200-N are connected to each other via a network NW1 so as to be able to communicate with each other.

[0171] The transaction management device (1) 100-1 has a transaction management unit 111a and a compressed log 1300. The hardware configuration of the transaction management device (1) 100-1 is similar to the hardware configuration shown in FIG. 2 except that the program 111 does not include the transaction start processing unit 111b and the log 112 is replaced with a compressed log 1300.

[0172] The hardware configuration of the transaction manager device (2) 100-2 is the same as that shown in FIG. 2, except that the program 111 does not include a transaction manager 111a and the storage device 110 does not include a log 112.

[0173] The transaction management device (1) 100-1 holds (stores, memorizes) a compressed log 1300 shown in FIG. 13 in the storage device 110. As shown in FIG. 13, the compressed log 1300 includes a transaction identifier range 1301 and usage information 1302 as columns for storing information (values). In the compressed log 1300, information corresponding to each column related to the settlement result of a transaction is stored as information (records) in rows in association with each other. Specifically, the transaction identification range 1301 stores a range of TR identification numbers, which are transaction identifiers. The usage information 1302 stores "used." Note that "used" stored in the usage information 1302 may also be referred to as a "settlement result log" or a "transaction settlement result log" for convenience.

[0174] <Summary> The transaction manager 111a temporarily records information about each transaction in the storage device 110 of the transaction manager device (1) 100-1 as an uncompressed log 1400 shown in Fig. 14A. The uncompressed log 1400 includes a transaction identifier 1401, a settlement result 1402, and processing information 1403 as columns for storing information (values). Although not shown, the uncompressed log 1400 includes a column similar to the list of resource management identifiers 112c in Fig. 3. This column stores a list of resource managers 211 participating in the transaction indicated by the TR identification number stored in the transaction identifier 1401.

[0175] The transaction identifier 1401 stores a TR identification number, which is a transaction identifier. The settlement result 1402 stores either R or C, which indicates the settlement result of the transaction, or unused. R indicates rollback, and C indicates commit. If the corresponding settlement result is C, the processing information 1403 stores either "commit settlement" (not shown) or "processed."

[0176] "Commit concluded" is a state in which the transaction has been concluded by a commit, but the commit processing of the resource manager 211 participating in the transaction has not been completed. "Processed" is a state in which the commit processing of the resource manager 211 participating in the transaction has been completed (concluded). If the corresponding conclusion result is R, the processing information 1403 is "Null".

[0177] The transaction manager 111a creates a compressed log 1300 by compressing (converting) the uncompressed log 1400, and records the compressed log 1300 permanently (long-term) in the storage device 110. This enables the transaction manager device 100-1 to prevent an increase in the storage area for transaction logs while ensuring the consistency of distributed transactions.

[0178] The method executed by the transaction manager 111a to compress the uncompressed log 1400 into the compressed log 1300 will now be described. As described above, a TR identification number is stored in the transaction identifier 1401 of the uncompressed log 1400 shown in Fig. 14A. A predetermined range of TR identification numbers (TR identification numbers from 10 to 19 in this example) for assigning TR identification numbers to transactions is assigned to the transaction start processor 111b. Note that the predetermined range of TR identification numbers in this example is merely an example and is not limited to this.

[0179] The transaction origin processing unit 111b assigns numbers to each of the multiple transactions in ascending order (starting from the smallest number, 10, in this example) from a pre-assigned range of TR identification numbers (TR identification numbers from 10 to 19 in this example).

[0180] As multiple transactions are being processed, the transaction manager 111a compresses the uncompressed log 1400 at a predetermined timing by referring to the transaction identifier 1401 in the uncompressed log 1400, the settlement result 1402 corresponding to the TR identification number, and the processing information 1403.

[0181] The transaction management unit 111a converts the TR identification numbers (in the example of Figure 14A, TR identification numbers from 10 to 13) corresponding to multiple transactions in the pre-compression log 1400 that have been settled and have consecutive TR identification numbers into information indicating the range of those multiple TR identification numbers (the range of TR identification numbers (in the example of Figure 14A, 10-13)), and associates information indicating that the range of TR identification numbers has been used (used).

[0182] As a result, the transaction manager 111a compresses the uncompressed log 1400, creates the compressed log 1300, and permanently stores the compressed log 1300 in the storage device 110. Note that the TR identification numbers corresponding to multiple settled transactions are the TR identification numbers in the uncompressed log 1400 for which the settlement result 1402 corresponds to R or C. Note that the above C is a C for which the corresponding processing information 1403 has been processed.

[0183] 14B, the transaction start processing unit 111b assigns a TR identification number, which is a transaction identifier, to the transaction, and as the processing of multiple transactions progresses, the uncompressed log 1400 is compressed in a state in which the transactions corresponding to the TR identification numbers 14 to 19 in the uncompressed log 1400 become settled. In this case, the transaction management unit 111a converts the TR identification numbers 14 to 19, which indicate that the corresponding transactions have been settled and have consecutive TR identification numbers, into information indicating the range of multiple TR identification numbers added to the range (10-13) of the TR identification numbers in the compressed log 1300 shown in FIG. 14A (the range of TR identification numbers (10-19 in the example of FIG. 14B)), and associates information indicating that the range of TR identification numbers has been used (used) with the range of TR identification numbers (i.e., stores "used" in the usage information 1302). As a result, the transaction manager 111 a compresses the uncompressed log 1400 , creates the compressed log 1300 , and stores the compressed log 1300 in the storage device 110 permanently.

[0184] The transaction manager 111a uses the compressed log 1300 when there is a request to recover a transaction. In this case, the transaction manager 111a refers to the compressed log 1300, and if the usage information corresponding to the range of TR identification numbers including the TR identification number of the transaction is "used", it determines that the transaction should be rolled back. Therefore, even if the order of processing is changed as shown in FIG. 6, for example, it is possible to avoid transaction inconsistency.

[0185] Furthermore, when the transaction origin processing unit 111b stops due to a failure or the like, the transaction manager 111a may mark all of the usage information corresponding to the range of TR identification numbers assigned to the transaction origin processing unit 111b as used.

[0186] <Activation> 15 is a sequence diagram for explaining the processes executed by the transaction start processing unit 111b, the transaction management unit 111a, and the resource management unit 211. The transaction start processing unit 111b, the transaction management unit 111a, and the resource management unit 211 sequentially execute the processes from S1501 to S1510 described below.

[0187] S1501: The transaction origin processing unit 111b assigns a TR identification number, which is a transaction identifier, to a transaction. At this time, the transaction origin processing unit 111b assigns the TR identification numbers in ascending order from the range of TR identification numbers (in this example, TR identification numbers from 10 to 19) previously assigned to the transaction origin processing unit 111b.

[0188] S1502: The transaction start processing unit 111b transmits the transaction identifier, SQL, and the like to the resource management unit 211, and instructs the multiple resource management units 211 participating in the transaction to execute transaction processing.

[0189] S1503: The transaction start processing unit 111b instructs the transaction management unit 111a to conclude the transaction by sending the transaction identifier to the transaction management unit 111a.

[0190] S1504: When the transaction manager 111a receives a transaction determination instruction from the transaction start processor 111b, it starts completion processing (commit or rollback) of the transaction corresponding to the transaction identifier received from the transaction start processor 111b. The transaction manager 111a sends a prepare instruction to the multiple resource managers 211 participating in the transaction.

[0191] S1505: In response to the prepare instruction from the transaction manager 111a, the multiple resource managers 211 participating in the transaction execute the prepare process.

[0192] S1506: Each of the multiple resource managers 211 participating in the transaction transmits a prepare success / failure vote to the transaction manager 111a.

[0193] S1507: The transaction manager 111a records the transaction settlement result in a log (uncompressed log 1400). Note that this uncompressed log 1400 is compressed (converted) into the compressed log 1300 at a predetermined timing by executing the process flows of Fig. 16 and Fig. 17 described later.

[0194] S1508: The transaction start processing unit 111b assigns to the transaction, as a transaction identifier, the TR identification number next in sequence to the TR identification number assigned in S1501. For example, in this example, the TR identification number assigned in S1501 is 10, and 11, which is the TR identification number next in sequence to 10, is assigned.

[0195] S1509: The transaction start processing unit 111b transmits the transaction identifier, SQL, and the like to the resource management unit 211, and instructs the multiple resource management units 211 participating in the transaction to execute transaction processing.

[0196] S1510: The transaction start processing unit 111b transmits a prepare command to the multiple resource management units 211 participating in the transaction.

[0197] Thereafter, the transaction start processing unit 111b, the transaction management unit 111a, and the resource management unit 211 process a plurality of transactions by repeatedly performing the processes of S1504 to S1508 for the number of transactions that need to be processed.

[0198] Fig. 16 is a flowchart showing the process flow executed by the transaction manager 111a. This flowchart is the same as the flowchart in Fig. 7 except that step 1605 is added between step 725 and step 730 in Fig. 7, step 1610 is added between step 750 and step 730, steps 1615 and 1620 are added after step 775, and step 765 is deleted.

[0199] 16. In addition, steps 720, 725, 730, 740, 750, 760, and 775 in the flowchart of FIG. 16, which have the same reference numerals as the steps in FIG. 7, differ from the steps in FIG. 7 in that compressed log 1300 and / or uncompressed log 1400 are used instead of log 112.

[0200] Therefore, the following description will focus on the differences from FIG.

[0201] In step 720, the transaction manager 111a determines whether or not the log (settlement result log) for the transaction that is the target of the recovery request has already been recorded in the compressed log 1300 or the pre-compression log 1400. If the log (settlement result log) for the transaction that is the target of the recovery request has not already been recorded in the compressed log 1300 and has not already been recorded in the pre-compression log 1400, the transaction manager 111a determines "NO" in step 720 and proceeds to step 725. In step 725, since the log (settlement result log) for the transaction that is the target of the recovery request has not already been recorded in the compressed log 1300 or the pre-compression log 1400, the transaction manager 111a presumes that the settlement of the transaction is a rollback, and records the rollback settlement result in the settlement result 112b of the pre-compression log 1400.

[0202] Thereafter, the transaction manager 111 a proceeds to step 1605 , compresses the uncompressed log 1400 , and creates the compressed log 1300 , after which the process proceeds to step 730 .

[0203] When the transaction manager 111 a proceeds to step 730 , it sends an instruction corresponding to the usage information 1302 of the compressed log 1300 or the settlement result 1402 of the uncompressed log 1400 to the resource manager 211 , and returns to step 710 .

[0204] In step 720, if the log (settlement result log) for the transaction that is the subject of the recovery request has already been recorded in the compressed log 1300 or the pre-compression log 1400, the transaction management unit 111a judges "YES" in step 720 and proceeds directly to step 730, executes the processing of step 730 described above, and then returns to step 710.

[0205] When the transaction manager 111a proceeds to step 740, it determines whether or not a log (a settlement result log) for the transaction has already been recorded in the compressed log 1300 or the uncompressed log 1400.

[0206] If the log for the transaction (settling result log) has already been recorded in the compressed log 1300 or the uncompressed log 1400, the transaction manager 111a judges "YES" in step 740 and proceeds to step 730, executes the processing of step 730 described above, and then returns to step 710.

[0207] If the log for the transaction (settlement result log) has not been recorded in the compressed log 1300 and has not been recorded in the uncompressed log 1400, the transaction manager 111a determines “NO” in step 740 and proceeds to step 745.

[0208] If the transaction manager 111a judges the result to be "YES" in step 745 and proceeds to step 750, it records the rollback settlement result in the pre-compression log 1400, then proceeds to step 1610, compresses the pre-compression log 1400, creates the compressed log 1300, and then proceeds to step 730.

[0209] If the transaction manager 111a determines "YES" in step 755 and proceeds to step 760, the transaction manager 111a determines that the prepare was successful by all of the voting results of the resource managers 211 participating in the transaction, so decides to commit the transaction and records the commit decision result in the decision result 112b of the pre-compression log 1400.

[0210] When the transaction manager 111a proceeds to step 775, it determines whether or not the message is the final commit processing completion notification from the resource managers 211 participating in the transaction, based on the list of resource managers 211 participating in the transaction in the uncompressed log 1400. If the message is the final commit processing completion notification, the transaction manager 111a determines "YES" in step 775, and then executes the processes of steps 1615 and 1620 described below in order, and then returns to step 710.

[0211] Step 1615: The transaction manager 111a changes the content (processing information 1403) of the log (uncompressed log 1400) from "commit concluded" to "commit processed" (processed).

[0212] Step 1620: The transaction manager 111a compresses the uncompressed log 1400 to create the compressed log 1300, and then returns to step 710.

[0213] Fig. 17 is a flowchart showing the process flow of log compression executed by the transaction manager 111a. When the transaction manager 111a proceeds to the log compression process (step 1605, step 1610, step 1615 or step 1620) of Fig. 16, it starts the process from step 1700, executes the processes of steps 1705 and 1710 described below in order, and then proceeds to step 1715.

[0214] Step 1705: The transaction manager 111a scans the log entries (rows (records)) of the uncompressed log 1400.

[0215] Step 1710: The transaction manager 111a searches for a part where rollback or commit processing is continuous. The rollback part is a part (row (record)) where the settlement result 1402 is "R", and the commit processing part is a part (row (record)) where the settlement result 1402 is "C" and the processing information 1403 is "Processed".

[0216] When the transaction management unit 111a proceeds to step 1715, it determines whether there is a portion where rollback or commit processing is continuous (i.e., a portion where rows (records) in which "C" or "R" is stored in the pre-compression log 1400 are continuous).

[0217] If there is a portion where rollback or commit processing is continuous, the transaction manager 111a determines "YES" in step 1715 and proceeds to step 1720. When the transaction manager 111a proceeds to step 1720, it creates a compressed log 1300 by compressing the portion where rollback or commit processing is continuous by converting it into a TR identification number range and used, as described above, and then returns to step 1705.

[0218] If there are no consecutive rollbacks or consecutive committed sections, the transaction manager 111a judges "NO" in step 1715, proceeds to step 1795, and temporarily ends this processing flow.

[0219] <Effects> As described above, the transaction management device 100 according to the third embodiment of the present invention compresses and records the settlement result logs of transactions that occur in large quantities, thereby ensuring the consistency of distributed transactions while preventing an increase in the storage area of ​​transaction logs.

[0220] <<Fourth embodiment>> A description will be given of a distributed transaction management device (1) 100-1, a distributed transaction management device (2) 100-2, and a distributed transaction management device (3) 100-3 according to a fourth embodiment of the present invention. FIG. 18 is a system configuration diagram showing a configuration example of a system (distributed transaction system) including the transaction management device 100-1, the transaction management device 100-2, and the transaction management device 100-3 according to the fourth embodiment of the present invention. Hereinafter, the "distributed transaction management device (1) 100-1" will be referred to as the "transaction management device (1) 100-1", the distributed transaction management device (2) 100-2 will be referred to as the "transaction management device (2) 100-2", and the distributed transaction management device (3) 100-3 will be referred to as the "transaction management device (3) 100-3". When there is no particular need to distinguish between the transaction management device (1) 100-1, the transaction management device (2) 100-2, and the transaction management device (3) 100-3, they will be referred to as the "transaction management device 100".

[0221] 18, the system includes transaction manager device (1) 100-1, transaction manager device (2) 100-2, transaction manager device (3) 100-3, and computers (1) 200-1 to (N) 200-N. Transaction manager device (1) 100-1, transaction manager device (2) 100-2, transaction manager device (3) 100-3, and computers (1) 200-1 to (N) 200-N are connected to each other via network NW1 so as to be able to communicate with each other.

[0222] The transaction management device (1) 100-1 has a transaction management unit 111a and a compressed log 1900. The hardware configuration of the transaction management device (1) 100-1 is similar to the hardware configuration shown in FIG. 2 except that the program 111 does not include the transaction start processing unit 111b and the log 112 is replaced with a compressed log 1900.

[0223] The hardware configuration of the transaction management device (2) 100-2 is similar to the hardware configuration shown in FIG. 2, except that the program 111 does not include a transaction management unit 111a, the storage device 110 does not include a log 112, and the transaction start processing unit 111b replaces the transaction start processing unit (1) 111b1.

[0224] The hardware configuration of the transaction management device (3) 100-3 is similar to the hardware configuration shown in FIG. 2, except that the program 111 does not include a transaction management unit 111a, the storage device 110 does not include a log 112, and the transaction start processing unit 111b is replaced by the transaction start processing unit (2) 111b2.

[0225] Hereinafter, the transaction start processing unit (1) 111b1 and the transaction start processing unit (2) 111b2 will be referred to as the "transaction start processing unit 111b" when there is no particular need to distinguish between them.

[0226] The transaction management device (1) 100-1 holds (stores, memorizes) a compressed log 1900 shown in FIG. 19 in place of the log 112. The compressed log 1900 includes a transaction identifier range 1901 and usage information 1902 as columns for storing information (values). In the compressed log 1900, information corresponding to each column relating to the settlement results of transactions related to the transaction start processing unit (1) 111b1 and the transaction start processing unit (2) 111b2 is stored as information (records) in rows in association with each other. The transaction identifier range 1901 and usage information 1902 store information similar to the transaction identifier range 1301 and usage information 1302 in FIG. 13.

[0227] <Summary> The transaction manager 111a temporarily records information about each transaction for each transaction start processor 111b in the storage device 110 of the transaction manager device (1) 100-1 as an uncompressed log 2000 shown in FIG. 20A.

[0228] The uncompressed log 2000 in Fig. 20A includes columns for storing information (values), such as a transaction identifier 2001, a settlement result 2002, and processing information 2003. Although not shown, the uncompressed log 2000 includes a column similar to the list of resource management identifiers 112c in Fig. 3. This column stores a list of resource managers 211 participating in the transaction indicated by the TR identification number stored in the transaction identifier 1401.

[0229] In the uncompressed log 2000 in Fig. 20, information corresponding to each column for each transaction to which a TR identification number, which is a transaction identifier, has been assigned by each of the transaction start processing unit (1) 111b1 and the transaction start processing unit (2) 111b2 is associated with each other and stored as row-by-row information (records). The information stored in the transaction identifier 2001, the settlement result 2002, and the processing information 2003 is similar to the transaction identifier 1401, the settlement result 1402, and the processing information 1403 in Fig. 14A described above.

[0230] The transaction manager 111a creates a compressed log 1900 shown in Fig. 19 by compressing (converting) the uncompressed log 2000 in Fig. 20A, and permanently records the compressed log 1900 in the storage device 110. This enables the transaction manager device (1) 100-1 to prevent an increase in the storage area for transaction logs while ensuring the consistency of distributed transactions.

[0231] The method of compressing the uncompressed log 2000 into the compressed log 1900 executed by the transaction manager 111a will now be described. As described above, a TR identification number is stored in the transaction identifier 2001 of the uncompressed log 2000. A range of TR identification numbers (in this example, TR identification numbers from 10 to 19) for assigning TR identification numbers to transactions is assigned to the transaction start processor (1) 111b1. A range of TR identification numbers (in this example, TR identification numbers from 20 to 29) for assigning TR identification numbers to transactions is assigned to the transaction start processor (2) 111b2.

[0232] The transaction start processing unit (1) 111b1 assigns numbers to each of a plurality of transactions in ascending order from a predetermined pre-assigned range of numbers (numbers from 10 to 19).

[0233] The transaction start processing unit (2) 111b2 assigns numbers to each of a plurality of transactions in ascending order from a predetermined pre-assigned range of numbers (numbers from 20 to 29).

[0234] While the processing of a plurality of transactions is in progress, the transaction manager 111a refers to the TR identification number of the uncompressed log 2000 in FIG. 20A and the settlement result corresponding to the TR identification number at a predetermined timing, and compresses the uncompressed log 2000.

[0235] The transaction management unit 111a converts the TR identification numbers (in the example of Figure 20A, TR identification numbers from 10 to 13) corresponding to multiple transactions for which the uncompressed log 2000 for the transaction starting processing unit (1) 111b1 has been settled and which have consecutive TR identification numbers into information indicating the range of the multiple TR identification numbers (the range of TR identification numbers (in the example of Figure 20A, 10-13)), and associates information indicating that the range of TR identification numbers has been used (used).

[0236] The transaction management unit 111a converts the TR identification numbers (in the example of Figure 20A, TR identification numbers from 20 to 23) corresponding to multiple transactions for which the pre-compression log 2000 for the transaction starting processing unit (2) 111b2 has been settled and which have consecutive TR identification numbers into information indicating the range of the multiple TR identification numbers (the range of TR identification numbers (in the example of Figure 20A, 20-23)), and associates information indicating that the range of TR identification numbers has been used (used).

[0237] As a result, the transaction manager 111 a compresses the uncompressed log 2000 , creates a compressed log 1900 , and stores the compressed log 1900 in the storage device 110 permanently.

[0238] Thereafter, as shown in FIG. 20B, a TR identification number, which is a transaction identifier, is assigned to the transaction by each of the transaction origin processing unit (1) 111b1 and the transaction origin processing unit (2) 111b2, and as the processing of multiple transactions progresses, the pre-compression log 2000 is compressed in a state in which the transactions corresponding to TR identification numbers 14 to 19 and 24 to 29 in the pre-compression log 2000 have been settled.

[0239] In this case, the transaction manager 111a converts the TR identification numbers 14 to 19 and 24 to 29, which are consecutive and for which the corresponding transactions have been settled, into information indicating a range of multiple TR identification numbers added to the range of TR identification numbers in the compressed log 1900 shown in FIG. 20A (the range of TR identification numbers (10-29 in the example of FIG. 20B)), and associates information indicating that the range of TR identification numbers has been used (used). As a result, the transaction manager 111a compresses the uncompressed log 2000, creates the compressed log 1900, and permanently stores the compressed log 1900 in the storage device 110.

[0240] <Activation> 21 is a sequence diagram for explaining the processing of the transaction origin processing unit (1) 111b1, the transaction origin processing unit (2) 111b2, and the transaction management unit 111a. In this sequence diagram, a range of transaction identifiers is assigned to each transaction origin processing unit 111b in ascending order, and the processing when each transaction origin processing unit 111b assigns a transaction identifier to a transaction from the assigned range is explained. Note that the range of transaction identifiers is, for example, a range numbered in sequence from a start number X by a predetermined number Y, and the ranges generated in sequence are assigned in sequence.

[0241] For example, the Nth transaction identifier range is generated by sequentially assigning a predetermined number Y of numbers starting from number X (the number of numbers assigned includes number X). Here, X=X0+(Y×(N-1)). In this example, X0=10 and Y=10. In this case, the first transaction identifier range is 10 to 19, with 10 numbers assigned starting from number 10. The number X of the second transaction identifier range is 20 (=10+(10×(2-1))), with 10 numbers assigned starting from number 20, and the range is 20 to 29. The number X of the third transaction identifier range is 30 (=10+(10×(3-1)), with 10 numbers assigned starting from number 30, and the range is 30 to 39.

[0242] The transaction start processing unit (1) 111b1, the transaction start processing unit (2) 111b2, and the transaction manager 111a sequentially execute the processes of S2101 to S2112 described below.

[0243] S2101: The transaction start processing unit (1) 111b1 acquires the range of transaction identifiers (the range of transaction identifiers in the smallest order (for example, the range of TR identification numbers from 10 to 19)).

[0244] S2102: The transaction manager 111a assigns a range of transaction identifiers (for example, a range of TR identification numbers from 10 to 19) to the transaction origin processor (1) 111b1.

[0245] S2103: The transaction start processing unit (2) 111b2 acquires the next range of transaction identifiers (for example, the range of TR identification numbers from 20 to 29).

[0246] S2104: The transaction manager 111a assigns a range of transaction identifiers (for example, TR identification numbers from 20 to 29) to the transaction origin processor (2) 111b2.

[0247] S2105: The transaction origin processing unit (1) 111b1 assigns the TR identification number (10), which is a transaction identifier, to the transaction from the acquired range (for example, the range of TR identification numbers from 10 to 19).

[0248] S2106: The transaction origin processing unit (2) 111b2 assigns the TR identification number (20), which is a transaction identifier, to the transaction from the acquired range (for example, TR identification numbers from 20 to 29).

[0249] S2107: The transaction origin processing unit (1) 111b1 assigns the next transaction identifier, TR identification number (11), from the acquired range (for example, the range of TR identification numbers from 10 to 19), to the transaction.

[0250] S2108: The transaction origin processing unit (2) 111b2 assigns the next transaction identifier (21) from the acquired range (for example, TR identification numbers from 20 to 29) to the transaction.

[0251] S2119: When all the TR identification numbers in the acquired range (e.g., TR identification numbers from 10 to 19) have been assigned to transactions, the transaction origin processing unit (1) 111b1 acquires the next sequential range (e.g., TR identification numbers from 30 to 39) after the currently used range of transaction identifiers (the range of TR identification numbers from 10 to 29).

[0252] S2110: The transaction manager 111a assigns the range of transaction identifiers (the range of TR identification numbers from 30 to 39) to the transaction start processor (1) 111b1.

[0253] S2111: When all the TR identification numbers in the acquired range (e.g., the range of TR identification numbers from 20 to 29) have been assigned to transactions, the transaction origin processing unit (2) 111b2 acquires the next range of transaction identifiers (e.g., the range of TR identification numbers from 40 to 49) in the currently used transaction identification range (e.g., the range of TR identification numbers from 10 to 39).

[0254] S2112: The transaction manager 111a assigns a range of transaction identifiers (for example, TR identification numbers from 40 to 49) to the transaction origin processor (2) 111b2.

[0255] By carrying out the above operations, the transaction manager 111a assigns a range of transaction identifiers to each transaction start processing unit 111b.

[0256] 16 and 17, the transaction manager 111a records a transaction settlement result log corresponding to the TR identification number assigned to the transaction, and further compresses the recorded transaction settlement result log. This enables the transaction manager 100-1 to prevent an increase in the storage area for transaction logs while ensuring the consistency of distributed transactions.

[0257] <Effects> As described above, the transaction management device 100-1 according to the fourth embodiment of the present invention compresses and records the settlement result logs of transactions that occur in large quantities, thereby preventing an increase in the storage area of ​​transaction logs while ensuring the consistency of distributed transactions.

[0258] <<Modifications>> The present invention is not limited to the above-described embodiments, and various modifications can be adopted within the scope of the present invention. Furthermore, the above-described embodiments can be combined with each other without departing from the scope of the present invention.

[0259] In the second embodiment, after rollback determination due to a recovery process request, the rollback determination result log may be deleted when a predetermined time has elapsed from the time the transaction was determined by the prepare success / failure vote.

[0260] The transaction management device 100 may be configured to be able to execute either a method for deleting a transaction settlement result log of rollback of the transaction management device 100 according to the first embodiment (first deletion) or a method for deleting a transaction settlement result log of rollback of the transaction management device 100 according to the second embodiment (second deletion). In this case, the transaction management device 100 may be configured to be able to select and execute either the first deletion or the second deletion depending on the system environment.

[0261] The present invention can also have the following configuration.

[0262] A distributed transaction management device that is applied to a distributed transaction system, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and includes an information processing device that manages the transaction settlement result log, The information processing device includes: When a rollback process completion notification is received from any one of a plurality of resource management units participating in the transaction, a first deletion of the transaction conclusion result log of the rollback and a second deletion of the transaction conclusion result log of the rollback after a certain time from the transaction conclusion are selectively performed according to an environment of the distributed transaction system. A distributed transaction management device.

[0263] A distributed transaction management method that is applied to a distributed transaction system in a specific environment, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and uses an information processing device that manages the transaction settlement result log, By the information processing device, when a rollback processing completion notification is received from any one of the multiple resource management units participating in the transaction, deleting the transaction conclusion result log of the rollback. Distributed transaction management methods.

[0264] A distributed transaction management method that is applied to a distributed transaction system in a specific environment, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and uses an information processing device that manages the transaction settlement result log, By the information processing device, a rollback transaction determination result log is deleted after a certain time has elapsed since the rollback transaction determination based on recovery requests from a plurality of resource management units participating in the transaction has been determined; Distributed transaction management methods.

[0265] A distributed transaction management method that is applied to a distributed transaction system, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and uses an information processing device that manages the transaction settlement result log, By the information processing device, a transaction identification number having a magnitude relationship is used as a transaction identifier for identifying the transaction, a plurality of consecutive transaction identification numbers corresponding to settled transactions are converted into range information indicating a range of the plurality of consecutive transaction identification numbers, and used information indicating that the transaction has been used is associated with the converted range information, thereby compressing the transaction settlement result log to create a compressed log, and recording the compressed log in a storage device. Distributed transaction management methods. [Explanation of symbols]

[0266] 100... transaction management device, 111a... transaction management section, 111b... transaction start processing section, 112... log, 200-1 to 200-N... computers 1 to N, 211-1 to 211-N... resource management section 1 to resource management section N, 1300... compressed log

Claims

1. A distributed transaction management device that is applied to a distributed transaction system in a specific environment, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and includes an information processing device that manages the transaction settlement result log, The information processing device includes: when a rollback processing completion notification is received from any one of the multiple resource management units participating in the transaction, deleting the transaction conclusion result log of the rollback. It was configured as follows: A distributed transaction management device.

2. 2. The distributed transaction management system according to claim 1, The specific environment is an environment in which a situation may occur in which a reordering of processes does not occur in the resource management unit other than the resource management unit in which a reordering of processes occurs first, in which a rollback process occurs due to a recovery request before the arrival of a transaction completion instruction based on the conclusion of the transaction by a prepare success / fail vote. A distributed transaction management device.

3. 2. The distributed transaction management system according to claim 1, The specific environment is (1) Recovery process invocation timeout time + minimum recovery request communication time < maximum prepare success / failure voting communication time, and (2) Maximum prepare success / failure voting communication time < Processing delay time of recovery process activation This is an environment where A distributed transaction management device.

4. 2. The distributed transaction management system according to claim 1, The information processing device includes: when there is a recovery request for the transaction from the resource management unit, if there is no transaction settlement result log corresponding to the transaction, it is assumed to be a rollback, and the transaction settlement result log indicating a rollback is recorded in the storage device; It was configured as follows: A distributed transaction management device.

5. A distributed transaction management device that is applied to a distributed transaction system in a specific environment, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and includes an information processing device that manages the transaction settlement result log, The information processing device includes: a log of the rollback transaction determination result is deleted after a certain time has elapsed since the rollback transaction determination based on recovery requests from a plurality of resource management units participating in the transaction has been determined. It was configured as follows: A distributed transaction management device.

6. 6. The distributed transaction management system according to claim 5, The specific environment is The distributed transaction system is an environment in which a situation may occur in which a reordering of processing does not occur for a certain period of time or more after the conclusion of a transaction due to a recovery request of an activated recovery process in a resource management unit other than the resource management unit in which a reordering of processing occurs first, in which a rollback process due to a recovery request occurs before the arrival of a commit instruction based on the conclusion of the transaction by a prepare success / fail vote. A distributed transaction management device.

7. 6. The distributed transaction management system according to claim 5, The specific environment is (1) The environment satisfies the following: (a) recovery process initiation timeout time + minimum recovery request communication time < maximum prepare success / failure voting communication time, (b) maximum prepare success / failure voting communication time < processing delay time for initiating recovery process, and (c) maximum prepare success / failure voting communication time < recovery process initiation timeout time + minimum recovery request communication time + log retention time. A distributed transaction management device.

8. 6. The distributed transaction management system according to claim 5, The information processing device includes: when there is a recovery request for the transaction from the resource management unit, if there is no transaction settlement result log corresponding to the transaction, it is assumed to be a rollback, and the transaction settlement result log indicating a rollback is recorded in the storage device; It was configured as follows: A distributed transaction management device.

9. A distributed transaction management device that is applied to a distributed transaction system, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and includes an information processing device that manages the transaction settlement result log, The information processing device includes: a transaction identification number having a magnitude relationship is used as a transaction identifier for identifying the transaction, a plurality of consecutive transaction identification numbers corresponding to settled transactions are converted into range information indicating a range of the plurality of consecutive transaction identification numbers, and used information indicating that the transaction has been used is associated with the converted range information, thereby compressing the transaction settlement result log to create a compressed log, and recording the compressed log in a storage device. It was configured as follows: A distributed transaction management device.

10. 10. The distributed transaction management system according to claim 9, The information processing device includes: assigning a predetermined range of transaction identification numbers to a transaction origin processing unit that starts processing of the transaction and assigns the transaction identification number to the transaction; the transaction origin processing unit assigns the transaction identification numbers to the transactions in ascending order from the assigned transaction identification number range. It was configured as follows: A distributed transaction management device.

11. 10. The distributed transaction management system according to claim 9, The information processing device includes: assigning a different predetermined range of transaction identification numbers to each of a plurality of transaction origin processing units which start processing of the transaction and assign the transaction identification numbers to the transaction; each of the plurality of transaction origin processing units assigns the transaction identification numbers to the transactions in ascending order from the assigned transaction identification number range; It was configured as follows: A distributed transaction management device.

12. 10. The distributed transaction management system according to claim 9, The information processing device includes: when a recovery request is made for a transaction participating in the transaction, referring to the compressed log, and when the range information corresponding to the transaction identification number of the transaction for which the recovery request is made is present in the compressed log, determining that the conclusion of the transaction is to be rolled back; It was configured as follows: A distributed transaction management device.

13. A distributed transaction management method that is applied to a distributed transaction system in a specific environment, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and uses an information processing device that manages the transaction settlement result log, By the information processing device, when a rollback processing completion notification is received from any one of the multiple resource management units participating in the transaction, deleting the transaction conclusion result log of the rollback. Distributed transaction management methods.

14. A distributed transaction management method that is applied to a distributed transaction system in a specific environment, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and uses an information processing device that manages the transaction settlement result log, By the information processing device, a log of the rollback transaction determination result is deleted after a certain time has elapsed since the rollback transaction determination based on recovery requests from a plurality of resource management units participating in the transaction has been determined; Distributed transaction management methods.

15. A distributed transaction management method that is applied to a distributed transaction system, includes a storage device that records a transaction settlement result log that indicates a settlement result of a transaction in the distributed transaction system, and uses an information processing device that manages the transaction settlement result log, By the information processing device, a transaction identification number having a magnitude relationship is used as a transaction identifier for identifying the transaction, a plurality of consecutive transaction identification numbers corresponding to settled transactions are converted into range information indicating a range of the plurality of consecutive transaction identification numbers, and used information indicating that the transaction has been used is associated with the converted range information, thereby compressing the transaction settlement result log to create a compressed log, and recording the compressed log in a storage device. Distributed transaction management methods.

Images