Information processing system, information processing device, and information processing method

Abstract

To provide a technology in which execution of optimum control can be attained in a distributed transaction adopting a Saga pattern and lock early release.SOLUTION: An information processing system comprises: a plurality of transaction management units which manage a plurality of transactions executed in a predetermined order with respect to an external service unit, respectively; and a transaction control unit which calls the external service unit, to execute the plurality of transactions in the predetermined order, executes a plurality of compensation transactions, in a reverse order to the predetermined order, when an execution result of the plurality of transactions shows failure, operates a lock function before calling the external service unit, when executing each transaction, and releases the lock function after execution of the transaction to be processed and before outputting the execution result of the transaction to be processed.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to an information processing system, an information processing device, and an information processing method. [Background technology]

[0002] In recent years, microservices (microservice architecture) have been attracting attention as a technique for building large applications or websites by combining and linking multiple small-scale services. Microservices perform what is known as a distributed transaction, in which the processing of a single transaction (a series of indivisible processes) is distributed and executed across multiple computers on a network.

[0003] In distributed transactions, it is necessary to guarantee the consistency (eventual consistency) of update processing across multiple services. For example, update processing is performed using a distributed consensus method called two-phase commit. In two-phase commit, the transaction manager that manages the distributed transaction first receives update execution results (hereinafter referred to as "prepare votes") from all managed databases. Then, based on the received prepare votes, the transaction manager decides whether to commit (succeed) or roll back (fail) the transaction, and sends this decision (settlement) result to each database (hereinafter referred to as "settlement notification"). The database that receives the settlement notification performs processing according to the settlement result (commit / rollback).

[0004] Furthermore, in a distributed transaction, when multiple services are executed in parallel to obtain a single update result, it is necessary to guarantee that the update result will be the same as if the multiple services had been executed serially in a specified order (serializability). This rule is also known as Commitment Ordering. To comply with this rule, of the multiple services executed in parallel, the preceding transaction process (hereinafter referred to as the "preceding transaction") is executed first. Then, the subsequent transaction process (hereinafter referred to as the "subsequent transaction") receives the settlement result (commit / rollback) of that transaction before starting the subsequent transaction. Note that each transaction process is executed with resources locked. Therefore, at the start of each transaction process, resource locks are acquired, and at the end, the resource locks are released. Then, while the preceding transaction is being executed, the subsequent transaction waits to acquire the resource lock.

[0005] Furthermore, in the past, when multiple services are executed in parallel in a distributed transaction, a technique called early lock release has been proposed to shorten the lock period at the time of commit settlement. With early lock release, the preceding transaction releases the resource lock before receiving a settlement notification (commit / rollback) from the transaction manager, specifically before the prepare vote is executed. However, with this technique, even if the settlement result of the subsequent transaction is commit (success), if the settlement result of the preceding transaction is rolled back (failure), the settlement result of the subsequent transaction must also be rolled back. Hereinafter, this process will be referred to as "chained rollback."

[0006] Furthermore, there is a design pattern known as the Saga pattern that can be applied to guarantee eventual consistency in microservice architectures. The concept of the Saga pattern is as follows: When a series of processes involving multiple services is being carried out and an error occurs during the processing of a service, a process known as a compensation transaction is executed to cancel the processing of each service that preceded the error. In this case, the compensation transactions (rollback processing) of each service are executed in the reverse order of the order of service execution before the error occurred.

[0007] In the technical field of distributed transactions described above, various techniques have been proposed to optimize processing, for example (see, for example, Patent Document 1). Patent Document 1 discloses a technique that guarantees serializability between distributed transactions by selecting commit, abort, or delay of a transaction and executing the commitment order in the same order as the execution order of conflict operations of the transaction. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] U.S. Patent No. 5,504,900 Summary of the Invention [Problem to be solved by the invention]

[0009] In microservices, when multiple services are executed in parallel, there is a demand for shortening lock periods while ensuring consistency in distributed transactions. One possible method for meeting this demand is to employ the aforementioned early lock release in distributed transactions that apply the Saga pattern, and an optimal control method for this is being sought. Note that Patent Document 1 above discloses early lock release and chained rollback, but does not consider the Saga pattern (compensating transaction).

[0010] The present invention has been made in consideration of the above situation, and an object of the present invention is to provide a technology that enables optimal control to be performed in distributed transactions that employ the Saga pattern and early lock release. [Means for solving the problem]

[0011] In order to solve the above problems, the information processing system of the present invention includes multiple transaction management units and a transaction control unit. The multiple transaction management units each manage multiple transactions that are executed in a predetermined order with respect to an external service unit. The transaction control unit is connected to the multiple transaction management units and the external service unit. The transaction control unit calls the external service units and executes the multiple transactions in a predetermined order. If the execution result of the multiple transactions is a failure, the transaction control unit calls the external service unit and executes multiple compensation transactions for each of the multiple transactions in the reverse order to the predetermined order, in order to restore the state of the external service unit to the state before the execution of the multiple transactions. When executing each of the multiple transactions, the transaction control unit activates a locking function that disables execution of transactions other than the transaction to be processed among the multiple transactions before calling the external service unit. Furthermore, the transaction control unit releases the locking function after execution of the transaction to be processed and before outputting the execution result of the transaction to be processed to a transaction management unit that manages the transaction to be processed within the multiple transaction management units.

[0012] In order to solve the above problem, an information processing device of the present invention is an information processing device including a transaction control unit included in the information processing system of the present invention.

[0013] Furthermore, to solve the above-mentioned problems, an information processing method of the present invention is an information processing method performed by the information processing device of the present invention. In the information processing method of the present invention, a transaction control unit calls a service unit and executes multiple transactions in a predetermined order. If the execution result of the multiple transactions is a failure, the transaction control unit calls the service unit and executes multiple compensation transactions for each of the multiple transactions in the reverse order of the predetermined order to restore the state of the service unit to the state before the execution of the multiple transactions. When executing each of the multiple transactions, the transaction control unit activates a lock function that disables execution of transactions other than the transaction to be processed among the multiple transactions before calling the service unit. Furthermore, the transaction control unit releases the lock function after executing the transaction to be processed and before outputting the execution result of the transaction to be processed to a transaction management unit that manages the transactions to be processed within the multiple transaction management units. [Effects of the Invention]

[0014] According to the present invention having the above configuration, optimal control can be performed in distributed transactions that employ the Saga pattern and early lock release. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a functional block diagram of a distributed transaction control system according to an embodiment of the present invention. [Figure 2] 1 is a hardware configuration diagram of a distributed transaction control system according to an embodiment of the present invention. [Figure 3] 10 is a diagram showing an example of the configuration of service execution order information created by a service proxy in a distributed transaction control system according to an embodiment of the present invention; FIG. [Figure 4]1 is a diagram showing an example of the configuration of service control information created by a service proxy in a distributed transaction control system according to an embodiment of the present invention; [Figure 5] 1 is a diagram for explaining the basic operation of distributed transaction control performed in a distributed transaction control system according to an embodiment of the present invention. [Figure 6] FIG. 10 is a diagram illustrating an example of a control operation when a distributed transaction performed in a distributed transaction control system according to an embodiment of the present invention is successfully updated. [Figure 7] FIG. 10 is a diagram illustrating an example of a control operation when an update of a distributed transaction performed in a distributed transaction control system according to an embodiment of the present invention fails. [Figure 8] 10 is a flowchart showing the procedure of a distributed transaction control process performed by a service proxy of the distributed transaction control system according to one embodiment of the present invention. [Figure 9] 10 is a flowchart showing the procedure of a distributed transaction management process performed by a transaction manager of a distributed transaction control system according to an embodiment of the present invention. [Figure 10] FIG. 2 is a diagram showing an example of the configuration of a prepare vote waiting list created by a transaction manager of a distributed transaction control system according to one embodiment of the present invention. [Figure 11] FIG. 2 is a diagram showing an example of the configuration of a prepare vote waiting list created by a transaction manager of a distributed transaction control system according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0016] A distributed transaction control system and a distributed transaction control method according to an embodiment of the present invention will be specifically described below with reference to the drawings. The distributed transaction control system of this embodiment is a system capable of executing distributed transactions that employ the Saga pattern and early lock release.

[0017] [Issues in distributed transactions using the Saga pattern and early lock release] Before describing the distributed transaction control system and distributed transaction control method according to this embodiment, we will first explain problems that may occur in a distributed transaction that employs the Saga pattern and early lock release.

[0018] In a distributed transaction control system that employs the Saga pattern and early lock release, it is necessary to guarantee the result consistency of distributed transactions even when early lock release is used to shorten the resource lock period. Specifically, the following requirements (A) to (C) must be met. (A) Serializability is achieved when multiple transactions are executed in parallel (commitment ordering rules are followed). (B) Data integrity is guaranteed in the event of a rollback (failure) (recoverability). (C) In the case of processing for the same resource (same service), in the event of a rollback (failure), compensation transactions are executed in the reverse order of the data update. The requirement (A) above is a requirement called the isolation of a distributed transaction, and the requirements (B) and (C) above are requirements called the atomicity of a distributed transaction.

[0019] However, for example, if a resource update process is performed within a service (application) connected to a transaction manager and the service does not have a function that enables multiple transactions to be executed in parallel (hereinafter referred to as a "concurrency control function"), the following problem arises: (a) Within the service, it is not possible to notify subsequent transactions whether a preceding transaction has been settled or not. (b) When a preceding transaction within a service is rolled back (failed), the subsequent transaction cannot be notified of this fact. (c) The order in which compensation transactions are executed within the service cannot be controlled.

[0020] In the above problem (a), for example, cases may occur in which the processing order of prepare votes and commit notifications for each transaction does not match the execution order of transactions for the service, or in which global serializability is not achieved. In other words, in the above problem (a), requirement (A) may not be met. In addition, in the above problem (b), cases may occur in which chained rollback cannot be performed in subsequent transactions when a preceding transaction rolls back (fails). Furthermore, in the above problem (c), cases may occur in which recoverability cannot be achieved. In other words, in the above problems (b) and (c), requirements (B) and (C) may not be met.

[0021] Therefore, in order to solve the above-mentioned problems, the distributed transaction control system of this embodiment provides a service proxy (transaction control unit) with a transaction concurrency control function between the transaction manager (transaction management unit) and the service (application).The service proxy then notifies subsequent transactions of the settled / unsettled status of the preceding transaction, notifies subsequent transactions of the settlement information when the preceding transaction is rolled back, and controls the execution order of compensation transactions.

[0022] [Configuration of a distributed transaction control system] (Function block configuration) 1 is a functional block diagram of a distributed transaction control system according to this embodiment. Functionally, the distributed transaction control system 1 (information processing system) comprises a first transaction manager 11, a second transaction manager 12, a first service proxy 21, a second service proxy 22, and a third service proxy 23. These functional units that make up the distributed transaction control system 1 are implemented as software.

[0023] Also, although not shown in Figure 1, the functional units that make up the distributed transaction control system 1, as well as the functional units and external functional units, are connected via an external network 80 (see Figure 2) described below.

[0024] Specifically, the first transaction manager 11, the second transaction manager 12, the first service proxy 21, the second service proxy 22, and the third service proxy 23 are each connected via a network 80 to a main service unit 10 provided outside the distributed transaction control system 1. The main service unit 10 is a functional unit that accepts a user's operation to issue a command to execute a distributed transaction, and transmits a service execution request corresponding to the operation to each functional unit that constitutes the distributed transaction control system 1.

[0025] The first transaction manager 11 and the second transaction manager 12 are each connected to a first service proxy 21 via a network 80. The first service proxy 21 is also connected via the network 80 to a first service unit 31 provided outside the distributed transaction control system 1. That is, the first transaction manager 11 and the second transaction manager 12 are each connected to the first service unit 31 via the first service proxy 21.

[0026] Furthermore, the first transaction manager 11 and the second transaction manager 12 are each connected to a second service proxy 22 via a network 80. The second service proxy 22 is connected via the network 80 to a second service unit 32 provided outside the distributed transaction control system 1. That is, the first transaction manager 11 and the second transaction manager 12 are each connected to the second service unit 32 via the second service proxy 22.

[0027] Furthermore, the first transaction manager 11 and the second transaction manager 12 are each connected to a third service proxy 23 via a network 80. The third service proxy 23 is connected via the network 80 to a third service unit 33 provided outside the distributed transaction control system 1. That is, the first transaction manager 11 and the second transaction manager 12 are each connected to the third service unit 33 via the third service proxy 23.

[0028] Each of the first service unit 31, the second service unit 32, and the third service unit 33 is a functional unit that performs a predetermined application process (including a data update process) in a distributed transaction.

[0029] As described above, the distributed transaction control system 1 of this embodiment is configured (load balancing configuration) so that a service proxy is provided for each service unit (resource). In this embodiment, each service proxy calls the corresponding service unit to perform transaction processing. Note that, in this embodiment, an example is described in which the number of service units is three and the number of service proxies provided corresponding to each service unit is also three, but the present invention is not limited to this. For example, depending on the application of the distributed transaction control system 1, the number of service units (service proxies) may be two, or the number of service units (service proxies) may be four or more.

[0030] As described above, this embodiment is configured to provide a transaction manager for each transaction (load balancing configuration). In this embodiment, an example is described in which a first transaction manager 11 manages an preceding transaction T1 (a predetermined transaction), and a second transaction manager 12 manages a subsequent transaction T2 (a specific transaction). This example describes control (management) so that the result of executing preceding transaction T1 and subsequent transaction T2 in parallel is the same as when preceding transaction T1 and subsequent transaction T2 are executed serially in this order.

[0031] (Hardware configuration) 2 is a hardware configuration diagram of the distributed transaction control system 1 of this embodiment. In this embodiment, each functional unit constituting the distributed transaction control system 1 is provided in a separate information processing device. In addition, each of the main service unit 10, first service unit 31, second service unit 32, and third service unit 33 provided outside the distributed transaction control system 1 is also provided in a separate information processing device.

[0032] 2, an information processing device 51 having a first transaction manager 11 and an information processing device 52 having a second transaction manager 12 are provided separately from each other. Also, an information processing device 61 having a first service proxy 21, an information processing device 62 having a second service proxy 22, and an information processing device 63 having a third service proxy 23 are provided separately from each other. Furthermore, an information processing device 70 having a main service unit 10, an information processing device 71 having a first service unit 31, an information processing device 72 having a second service unit 32, and an information processing device 73 having a third service unit 33 are provided separately from each other. These information processing devices are connected via a network 80.

[0033] The information processing device 51 having the first transaction manager 11 is composed of a computer device or the like having calculation and communication functions, and as shown in Figure 2, has a CPU (Central Processing Unit) 100, memory 101, storage device 102, and network interface (NW I / F) 103.

[0034] The CPU 100 reads the program code of the software that enables the processing of the first transaction manager 11 from the memory 101 into the storage device 102 and executes it. At this time, variables and parameters that arise during the calculation processing are also temporarily written to the storage device 102.

[0035] The storage device 102 is made up of a RAM (Random Access Memory) and stores various data required for the arithmetic processing by the CPU 100. The memory 101 is made up of a ROM (Read Only Memory) and stores various software for executing the arithmetic processing by the CPU 100.

[0036] The network interface 103 is configured by, for example, a network interface card (NIC) or the like, and transmits and receives various data to and from each device connected via wireless communication. Therefore, the information processing device 51 is connected to the network 80 via the network interface 103.

[0037] The configuration of the information processing device 52 having the second transaction manager 12 is similar to that of the information processing device 51 having the first transaction manager 11. However, in the information processing device 52, the CPU reads the program code of the software that enables the processing of the second transaction manager 12 from memory to a storage device and executes it.

[0038] The information processing device 61 having the first service proxy 21 is composed of a computer device or the like having calculation and communication functions, and as shown in Figure 2, has a CPU 200, memory 201, storage device 202, network interface (NW I / F) 203 and data store 21a (storage unit).

[0039] The CPU 200 reads the program code of the software that enables the processing of the first service proxy 21 from the memory 201 to the storage device 202 and executes it. At this time, variables and parameters that arise during the calculation processing are also temporarily written to the storage device 202.

[0040] The storage device 202 is made up of a RAM, and stores various data required for the arithmetic processing by the CPU 200. For example, the storage device 202 stores service control information (see FIG. 4 described later) that is referenced in the processing by the first service proxy 21. The memory 201 is made up of a ROM, and stores various software for executing the arithmetic processing by the CPU 200.

[0041] The network interface 203 is configured by, for example, a NIC, and transmits and receives various data to and from each device connected via wireless communication. Therefore, the information processing device 61 is connected to the network 80 via the network interface 203.

[0042] The data store 21a can be configured as a rewritable storage device, such as a nonvolatile storage, etc. The data store 21a stores, for example, service execution order information (see FIG. 3) to be described later, which is updated (written) and referenced (read) by the first service proxy 21.

[0043] The configuration of the information processing device 62 having the second service proxy 22 is similar to that of the information processing device 61 having the first service proxy 21. However, in the information processing device 62, the CPU reads program code of software that enables the processing of the second service proxy 22 from memory to a storage device and executes it. The information processing device 62 is also provided with a data store 22a (see FIG. 1) that stores, for example, service execution order information (see FIG. 3 described below) that is updated (written) and referenced (read) by the second service proxy 22.

[0044] The configuration of the information processing device 63 having the third service proxy 23 is similar to that of the information processing device 61 having the first service proxy 21. However, in the information processing device 63, the CPU reads program code of software that enables the processing of the third service proxy 23 from memory to a storage device and executes it. The information processing device 63 is also provided with a data store 23a (see FIG. 1) that stores, for example, service execution order information (see FIG. 3 described below) that is updated (written) and referenced (read) by the third service proxy 23.

[0045] Each of the information processing device 70 having the main service unit 10, the information processing device 71 having the first service unit 31, the information processing device 72 having the second service unit 32, and the information processing device 73 having the third service unit 33 is also composed of a computer device or the like having a calculation function and a communication function. Although not shown in the figures, each of the information processing devices 70 to 73 includes a CPU, memory, a storage device, a network interface, and a data store. In each information processing device, the CPU reads program code of software that enables the processing of the corresponding service (application) from the memory to the storage device and executes it.

[0046] [Overview of the operation of each functional part of the distributed transaction control system] Next, an overview of the operation of each functional unit of the distributed transaction control system 1 will be described with reference to FIG.

[0047] (First Transaction Manager) As shown in FIG. 1, when the first transaction manager 11, which manages the processing of the preceding transaction T1, receives a service execution request F1 from the main service unit 10 via the network 80, it starts the management processing of the preceding transaction T1.

[0048] The first transaction manager 11 receives (acquires) a prepare vote FA3 (the update execution result at the first service unit 31) for the preceding transaction T1 from the first service proxy 21 via the network 80. The first transaction manager 11 receives a prepare vote FB3 (the update execution result at the second service unit 32) for the preceding transaction T1 from the second service proxy 22 via the network 80. The first transaction manager 11 also receives a prepare vote FC3 (the update execution result at the second service unit 32) for the preceding transaction T1 from the third service proxy 23 via the network 80.

[0049] Furthermore, when the first transaction manager 11 receives prepare votes from all the service proxies (service units) under its management, it determines whether to commit (succeed) or roll back (fail) the preceding transaction T1 based on these prepare votes.Then, the first transaction manager 11 transmits (outputs) settlement notifications FA4, FB4, and FC4 indicating the decision results for the preceding transaction T1 to the first service proxy 21, the second service proxy 22, and the third service proxy 23, respectively, via the network 80.

[0050] In this embodiment, a prepare vote waiting list that specifies information such as whether or not each prepare vote has been received and the settlement notice for each prepare vote is stored in the storage device 102 within the information processing device 51 that has the first transaction manager 11. Then, during the series of processes from receiving prepare votes from each service proxy to sending the settlement notice, the first transaction manager 11 updates the prepare vote waiting list. The configuration of the prepare vote waiting list and the mode of updating the prepare vote waiting list will be described in detail later (see Figures 10 and 11).

[0051] (Second Transaction Manager) As shown in FIG. 1, when the second transaction manager 12 that manages the processing of the subsequent transaction T2 receives a service execution request F2 from the main service unit 10 via the network 80, it starts the management processing of the subsequent transaction T2.

[0052] The second transaction manager 12 receives (acquires) the prepare vote FA5 (the update execution result in the first service unit 31) for the subsequent transaction T2 from the first service proxy 21 via the network 80. If the preceding transaction T1 has not yet been settled at this point, the prepare vote FA5 from the first service proxy 21 has been accompanied by instruction information (specific information) to wait for the settlement of the preceding transaction T1. Therefore, in this case, the second transaction manager 12 performs a process of waiting for the settlement notification (commit / rollback) of the preceding transaction T1 based on the instruction information to wait for the settlement of the preceding transaction T1 that was attached to the prepare vote FA5.

[0053] In addition, if the prepare vote FA5 is accompanied by instruction information to wait for the settlement of the preceding transaction T1, the second transaction manager 12 receives information on the settlement details of the preceding transaction T1 (hereinafter referred to as the ``preceding settlement notification'') FA6 from the first service proxy 21 via the network 80 after receiving the prepare vote FA5.

[0054] The second transaction manager 12 receives the prepare vote FB5 (the update execution result in the second service unit 32) from the second service proxy 22 via the network 80. If the preceding transaction T1 has not yet been settled at this point, the prepare vote FB5 from the second service proxy 22 includes an instruction to wait for the settlement of the preceding transaction T1. Therefore, in this case, the second transaction manager 12 waits for the settlement notification (commit / rollback) of the preceding transaction T1 based on the instruction to wait for the settlement of the preceding transaction T1 included in the prepare vote FB5.

[0055] In addition, if the prepare vote FB5 is accompanied by instruction information to wait for the settlement of the preceding transaction T1, the second transaction manager 12 receives a notice FB6 of the preceding settlement of the preceding transaction T1 from the second service proxy 22 via the network 80 after receiving the prepare vote FB5.

[0056] The second transaction manager 12 receives a prepare vote FC5 (the update execution result in the third service unit 33) from the third service proxy 23 via the network 80. If the preceding transaction T1 has not yet been settled at this point, the prepare vote FC5 from the third service proxy 23 includes an instruction to wait for the settlement of the preceding transaction T1. Therefore, in this case, the second transaction manager 12 waits for the settlement notification (commit / rollback) of the preceding transaction T1 based on the instruction to wait for the settlement of the preceding transaction T1 that is included in the prepare vote FC5.

[0057] In addition, if the prepare vote FC5 is accompanied by instruction information to wait for the settlement of the preceding transaction T1, the second transaction manager 12 receives a notice FC6 of the preceding transaction T1's settlement from the third service proxy 23 via the network 80 after receiving the prepare vote FC5.

[0058] Then, after receiving prepare votes and prior settlement notifications from all service proxies under its management, the second transaction manager 12 decides whether to commit (succeed) or roll back (fail) subsequent transaction T2 based on these notifications.The second transaction manager 12 then transmits (outputs) settlement notifications FA7, FB7, and FC7 indicating the decision results to the first service proxy 21, the second service proxy 22, and the third service proxy 23, respectively, via the network 80.

[0059] However, if the content of the preceding settlement notification of preceding transaction T1 received from the service proxy is rollback (failure), the second transaction manager 12 sends a settlement notification indicating rollback (failure) of subsequent transaction T2 to the service proxy, regardless of the actual settlement result (commit / rollback) of subsequent transaction T2. ​​This achieves chained rollbacks.

[0060] (First service proxy) In a distributed transaction, the first service proxy 21 calls the first service unit 31 to perform the corresponding application processing (data update processing). The first service proxy 21 has a transaction concurrency control function and can perform lock control for each transaction.

[0061] In this embodiment, the first service proxy 21 executes a preceding transaction T1 and a subsequent transaction T2 for the first service unit 31 in parallel. Specifically, for each transaction, the first service proxy 21 executes a series of processes: acquiring (activating) a lock (locking function), calling the first service unit 31, executing the transaction for the first service unit 31, obtaining the execution result, and releasing the lock. Note that when the lock (locking function) is activated, the transaction to be processed can be executed, but other transactions cannot be executed. Therefore, during the lock period for executing the preceding transaction T1, the subsequent transaction T2 is in a waiting state for execution.

[0062] Furthermore, if the settlement result of the distributed transaction is a rollback (failure), the first service proxy 21 calls the first service unit 31 to perform a compensation transaction (processing to restore the original state). At this time, the first service proxy 21 refers to the service execution order information (see FIG. 3 described later) described below and performs the compensation transaction in the reverse order of the transaction execution order (predetermined order). Specifically, the first service proxy 21 first calls the first service unit 31 to perform a compensation transaction for the subsequent transaction T2, and then performs a compensation transaction for the preceding transaction T1. Note that each compensation transaction involves a series of processes: acquiring a lock, calling the first service unit 31, executing the compensation transaction for the first service unit 31, obtaining the execution result, and releasing the lock.

[0063] The outline of the flow of processing operations performed by the first service proxy 21 is as follows. As shown in FIG. 1, when the first service proxy 21 receives a service execution request FA from the main service unit 10 via the network 80, it acquires a lock on the preceding transaction T1 and starts executing the preceding transaction T1 for the first service unit 31. In this embodiment, information indicating the execution order of transactions executed by the first service proxy 21 (hereinafter referred to as "service execution order information") is stored in the data store 21a of the information processing device 61 (see FIG. 2) that has the first service proxy 21. Then, when the first service proxy 21 acquires the lock on the preceding transaction T1, it accesses the data store 21a and stores information about the preceding transaction T1 in the service execution order information (see FIG. 3, described later).

[0064] Furthermore, when preceding transaction T1 for first service unit 31 is executed and the lock is released, first service proxy 21 sends (outputs) a prepare vote FA3 corresponding to the execution result (success / failure) of preceding transaction T1 for first service unit 31 to first transaction manager 11 via network 80. At this time, first service proxy 21 stores information about the execution result (success / failure) of preceding transaction T1 for first service unit 31 in service control information (see FIG. 4 described later) stored in storage device 202 of information processing device 61 that has first service proxy 21. Then, after releasing the lock on preceding transaction T1, first service proxy 21 receives (acquires) a settlement notification FA4 (commit / rollback) of preceding transaction T1 from first transaction manager 11 via network 80.

[0065] Furthermore, when the lock on the preceding transaction T1 is released, the first service proxy 21 acquires a lock on the subsequent transaction T2 and starts executing the subsequent transaction T2 for the first service unit 31. When the first service proxy 21 acquires the subsequent transaction T2, the first service proxy 21 accesses the data store 21a and stores information about the subsequent transaction T2 in the service execution order information.

[0066] After acquiring the lock for subsequent transaction T2 for first service unit 31, subsequent transaction T2 is executed and the lock is released. Then, first service proxy 21 sends (outputs) a prepare vote FA5 corresponding to the execution result (success / failure) of subsequent transaction T2 for first service unit 31 to first transaction manager 11 via network 80. If settlement notification FA4 for preceding transaction T1 has not been received at this point, first service proxy 21 sends prepare vote FA5 to first transaction manager 11, adding settlement wait instruction information for preceding transaction T1. At this time, first service proxy 21 also stores information related to the execution result (success / failure) of subsequent transaction T2 in the service control information stored in storage device 202.

[0067] Furthermore, if the settlement notification FA4 of the preceding transaction T1 has not been received when the first service proxy 21 sends the prepare vote FA5, after receiving the settlement notification FA4 of the preceding transaction T1, the first service proxy 21 sends (outputs) the preceding settlement notification FA6 (information on the decision result) to the second transaction manager 12 via the network 80. After that, the first service proxy 21 receives (acquires) the settlement notification FA7 (commit / rollback) of the subsequent transaction T2 from the first transaction manager 11 via the network 80.

[0068] Then, if the settlement result (settlement notification FA7) of the subsequent transaction T2 (distributed transaction) is commit (success), the first service proxy 21 deletes the service control information stored in the memory device 202 of the information processing device 61 that has the first service proxy 21 and the service execution order information stored in the data store 21a.

[0069] On the other hand, if the settlement result (settlement notification FA7) of the subsequent transaction T2 is rollback (failure), the first service proxy 21 calls the first service unit 31 to perform a corresponding compensation transaction (processing to restore the original state). Specifically, the first service proxy 21 refers to the service execution order information (see FIG. 3 described later) stored in the data store 21a, performs the compensation transaction in the reverse execution order of the transactions, and then deletes the service control information and the service execution order information.

[0070] (Second service proxy) In transaction processing, the second service proxy 22 calls the second service unit 32 to perform corresponding application processing (data update processing). The second service proxy 22 has a transaction concurrency control function and can control locks for each transaction. Therefore, in this embodiment, the second service proxy 22 executes a preceding transaction T1 and a subsequent transaction T2 for the second service unit 32 in parallel within the second service proxy 22. Specifically, for each transaction, the second service proxy 22 executes a series of processes: acquiring a lock, calling the second service unit 32, executing the transaction for the second service unit 32, obtaining the execution result, and releasing the lock.

[0071] Furthermore, if the settlement result of the distributed transaction is a rollback (failure), the second service proxy 22 calls the second service unit 32 to perform a compensation transaction (a process to restore the original state). At this time, the second service proxy 22 references the service execution order information and performs the compensation transaction in the reverse order of the transaction execution order. Specifically, the second service proxy 22 first calls the second service unit 32 to perform a compensation transaction for the subsequent transaction T2, and then performs a compensation transaction for the preceding transaction T1. Note that each compensation transaction involves a series of processes: acquiring a lock, calling the second service unit 32, executing the compensation transaction for the second service unit 32, obtaining the execution result, and releasing the lock.

[0072] 1, when the second service proxy 22 receives a service execution request FB from the main service unit 10 via the network 80, it acquires a lock on the preceding transaction T1 and starts executing the preceding transaction T1 for the second service unit 32. The subsequent processing operations of the second service proxy 22 for the first transaction manager 11 and the second transaction manager 12 are performed in the same manner as the processing operations of the first service proxy 21. Therefore, a description thereof will be omitted here.

[0073] (Third Service Proxy) In transaction processing, the third service proxy 23 calls the third service unit 33 to perform corresponding application processing (data update processing). The third service proxy 23 has a transaction concurrency control function and can control locks for each transaction. Therefore, in this embodiment, the third service proxy 23 executes a preceding transaction T1 and a subsequent transaction T2 for the third service unit 33 in parallel within the third service proxy 23. Specifically, for each transaction, the third service proxy 23 executes a series of processes: acquiring a lock, calling the third service unit 33, executing the transaction for the third service unit 33, obtaining the execution result, and releasing the lock.

[0074] Furthermore, if the settlement result of the distributed transaction is a rollback (failure), the third service proxy 23 calls the third service unit 33 to perform a compensation transaction (processing to restore the original state). At this time, the third service proxy 23 refers to the service execution order information and performs the compensation transaction in the reverse order of the transaction execution order. Specifically, the third service proxy 23 first calls the third service unit 33 to perform a compensation transaction for subsequent transaction T2, and then performs a compensation transaction for preceding transaction T1. Note that each compensation transaction involves a series of processes: acquiring a lock, calling the third service unit 33, executing a compensation transaction for the third service unit 33, obtaining the execution result, and releasing the lock.

[0075] 1, when the third service proxy 23 receives a service execution request FC from the main service unit 10 via the network 80, it acquires a lock for the preceding transaction T1 and starts executing the preceding transaction T1 for the third service unit 33. The subsequent processing operations of the third service proxy 23 for the first transaction manager 11 and the second transaction manager 12 are performed in the same manner as the processing operations of the first service proxy 21. Therefore, a description thereof will be omitted here.

[0076] [Service execution order information configuration] Next, the configuration of the service execution order information (predetermined information) stored in the data store of the information processing device having each service proxy will be described. Fig. 3 is a diagram showing the configuration of the service execution order information stored in the data store 21a of the information processing device 61 having the first service proxy 21. The configuration of the service execution order information stored in the data store 22a of the second service proxy 22 and the data store 23a of the third service proxy 23 is also the same as the configuration shown in Fig. 3. Therefore, only the configuration of the service execution order information stored in the data store 21a of the first service proxy 21 will be described here.

[0077] The service execution order information is data in the form of a table. In the service execution order information, as shown in FIG. 3, a transaction ID, a transaction manager ID, and the execution status of a transaction are associated with each registration number ("1" to "3") indicating the order in which the lock was acquired. The registration numbers for the lock acquisition order indicate the order in which the lock was acquired, and "1" is set for the registration number with the earliest lock acquisition order. Therefore, in the example shown in FIG. 3, the data set with registration number "1" arranged at the top of the service execution order information is the data set for the transaction that acquired the lock first.

[0078] A transaction ID is identification information for a transaction. Transaction IDs "T1" and "T2" in Fig. 3 are identification information for preceding transaction T1 and subsequent transaction T2, respectively. Although detailed explanation is omitted, transaction ID "T0" in Fig. 3 is identification information for a transaction executed by a transaction manager (not shown) other than the first transaction manager 11 and the second transaction manager 12 for the first service unit 31 before preceding transaction T1.

[0079] The transaction manager ID is the identification information of the transaction manager that manages the transaction. The transaction manager IDs "TM1" and "TM2" in Figure 3 are the identification information of the first transaction manager 11 that manages the preceding transaction T1 and the second transaction manager 12 that manages the subsequent transaction T2, respectively. Note that the transaction manager ID "TM0" in Figure 3 is the identification information of another transaction manager (not shown) that manages the transaction ID "T0."

[0080] The transaction execution status is information indicating whether the registered transaction is in progress or has been resolved. When the service proxy acquires a lock on a transaction, the transaction execution status is set to "in progress." If the settlement notification received by the service proxy is a commit (success), the transaction execution status is set to "resolved" at the time of receiving the settlement notification. On the other hand, if the settlement notification received by the service proxy is a rollback (failure), the transaction execution status is set to "resolved" after each compensation transaction is executed.

[0081] In this embodiment, as will be described later, the service execution order information is updated at a predetermined timing during distributed transaction control processing by the service proxy (see FIGS. 6 and 7 described later). Therefore, if the service proxy (distributed transaction control system 1) stops for some reason during distributed transaction control processing by the service proxy, the service execution order information at that time may be left unchanged rather than cleared. In this case, when the system is restarted, the transaction execution order can be confirmed by referring to the service execution order information, so the data update state of the service section can be reliably restored to its original state, improving fault tolerance.

[0082] [Service control information configuration] Next, the configuration of the service control information stored in the storage device of the information processing device having each service proxy will be described. Fig. 4 is a diagram showing the configuration of the service control information stored in the storage device 202 of the information processing device 61 having the first service proxy 21. The configuration of the service control information stored in each storage device (not shown) of the second service proxy 22 and the third service proxy 23 is also the same as the configuration shown in Fig. 4. Therefore, only the configuration of the service control information stored in the storage device 202 of the first service proxy 21 will be described here.

[0083] The service control information is data in the form of a table. As shown in Fig. 4, the service control information specifies a service ID, a service call result, and a preceding transaction ID in association with each other for each transaction ID. The service control information is updated every time the service proxy obtains the transaction execution result from the corresponding service unit.

[0084] The service ID is identification information of a service unit controlled by a service proxy, and the service ID "SA" in Fig. 4 is identification information of the first service unit 31 controlled by the first service proxy 21. In this embodiment, the service ID of the second service unit 32 controlled by the second service proxy 22 is "SB", and the service ID of the third service unit 33 controlled by the third service proxy 23 is "SC".

[0085] The service invocation result is the execution result (success / failure) obtained when the first service proxy 21 invokes the first service unit 31 after acquiring a lock to perform application processing (data update processing). Information on the service invocation result is information contained in the prepare vote sent from the first service proxy 21 to the first transaction manager 11 and the second transaction manager 12. Therefore, in the example shown in FIG. 4, a prepare vote FA3 containing information of "failure" as the execution result of the preceding transaction T1 for the first service unit 31 is sent from the first service proxy 21 to the first transaction manager 11. Also, in the example shown in FIG. 4, a prepare vote FA5 containing information of "success" as the execution result of the subsequent transaction T2 for the first service unit 31 is sent from the first service proxy 21 to the second transaction manager 12.

[0086] The preceding transaction ID is the identification information of the transaction executed before the transaction itself. Therefore, in the example shown in Figure 4, there is no preceding transaction for preceding transaction T1, so no information is specified in the preceding transaction ID field in the service control information. On the other hand, there is a preceding transaction T1 for subsequent transaction T2, so the identification information (T1) of preceding transaction T1 is set in the preceding transaction ID field in the service control information.

[0087] [Example of control operation of distributed transaction control system] Next, various control operation examples of distributed transactions performed in the distributed transaction control system 1 of this embodiment will be described. However, in the following, for the sake of simplicity, an example of control operation of transaction processing for the first service unit 31 will be described. Note that each transaction processing for the second service unit 32 and the third service unit 33 is also performed in the same manner as the transaction processing for the first service unit 31 described below.

[0088] (Basic control operation) First, an example of a basic control operation of a distributed transaction performed for the first service unit 31 in the distributed transaction control system 1 will be described. Fig. 5 is a diagram showing a basic operation flow of distributed transaction control performed for the first service unit 31 in the distributed transaction control system 1.

[0089] First, when a user issues a transaction processing execution command, the main service unit 10, as shown in Fig. 5, sends service execution requests F1, F2, and FA to the first transaction manager 11 (first TM in the figure), the second transaction manager 12 (second TM in the figure), and the first service proxy 21, respectively. This starts management and control of the preceding transaction T1 by the first transaction manager 11, and management and control of the succeeding transaction T2 by the second transaction manager 12.

[0090] Furthermore, the first service proxy 21, which has received the service execution request FA, performs lock acquisition processing for the preceding transaction T1. At this time, the first service proxy 21 also starts lock wait processing for the subsequent transaction T2.

[0091] After acquiring the lock for the preceding transaction T1, the first service proxy 21 calls the first service unit 31 for the preceding transaction T1 (arrow FA1 in the figure) and performs application processing (data update) for the first service unit 31. The first service proxy 21 then obtains the execution result of the preceding transaction T1 for the first service unit 31 (arrow FA2 in the figure). Next, the first service proxy 21 releases the lock for the preceding transaction T1. That is, the lock for the preceding transaction T1 is released (early lock release) before receiving the settlement notification FA4 for the preceding transaction T1. After that, the first service proxy 21 sends a prepare vote FA3 for the preceding transaction T1 for the first service unit 31 to the first transaction manager 11.

[0092] Furthermore, when releasing the lock on preceding transaction T1, the first service proxy 21 performs lock acquisition processing for subsequent transaction T2 in subsequent transaction T2 (arrow R in the figure). Thereafter, in subsequent transaction T2, the first service proxy 21 calls the first service unit 31 (arrow FA1 in the figure) and performs application processing (data update) in the first service unit 31. The first service proxy 21 then obtains the execution result of subsequent transaction T2 for the first service unit 31 (arrow FA2 in the figure). Next, the first service proxy 21 releases the lock on subsequent transaction T2. ​​Thereafter, the first service proxy 21 sends a prepare vote FA5 for subsequent transaction T2 for the first service unit 31 to the second transaction manager 12.

[0093] 5, if the first service proxy 21 has not yet received the settlement notification FA4 for preceding transaction T1 from the first transaction manager 11 at the time of sending the prepare vote FA5, the first service proxy 21 sends the prepare vote FA5 to the second transaction manager 12, along with the settlement-wait instruction information for preceding transaction T1. Note that if the first service proxy 21 has received the settlement notification FA4 for preceding transaction T1 from the first transaction manager 11 at the time of sending the prepare vote FA5, the settlement-wait instruction information for preceding transaction T1 is not added to the prepare vote FA5.

[0094] The second transaction manager 12, which has received the prepare vote FA5 for subsequent transaction T2, performs a settlement waiting process for preceding transaction T1 based on the settlement waiting instruction information for preceding transaction T1 attached to the prepare vote FA5. The second transaction manager 12 then waits until it receives a notice FA6 of the preceding transaction T1's settlement from the first service proxy 21.

[0095] 5, after receiving the prepare vote FA5 for subsequent transaction T2 by the second transaction manager 12, the first transaction manager 11 determines the settlement outcome of the preceding transaction T1 (commit (success) / rollback (failure)). The first transaction manager 11 then sends a corresponding settlement notification FA4 to the first service proxy 21.

[0096] 5, before the first transaction manager 11 determines the settlement result of preceding transaction T1, the second service proxy 22 sends a prepare vote FB3 for preceding transaction T1 for the second service unit 32 to the first transaction manager 11, and the third service proxy 23 sends a prepare vote FC3 for preceding transaction T1 for the third service unit 33 to the first transaction manager 11. Therefore, in the process of determining the settlement result of preceding transaction T1 described above, the first transaction manager 11 determines the settlement result (commit (success) / rollback (failure)) of preceding transaction T1 based on the contents of the prepare votes for preceding transaction T1 received from each service proxy.

[0097] Then, the first service proxy 21, which has received the settlement notification FA4 of the preceding transaction T1, sends a preceding settlement notification FA6 to the second transaction manager 12 for the preceding transaction T1.

[0098] Upon receiving the preceding settlement notification FA6 from the first service proxy 21, the second transaction manager 12 releases the settlement wait state for the preceding transaction T1. The second transaction manager 12 then determines the settlement result (commit (success) or rollback (failure)) for the subsequent transaction T2. ​​The second transaction manager 12 then sends a corresponding settlement notification FA7 to the first service proxy 21.

[0099] 5, it is assumed that, before the second transaction manager 12 determines the settlement result of the subsequent transaction T2, a prepare vote FB5 for the subsequent transaction T2 for the second service unit 32 is sent from the second service proxy 22 to the second transaction manager 12, and a prepare vote FC5 for the subsequent transaction T2 for the third service unit 33 is sent from the third service proxy 23 to the second transaction manager 12 (see FIGS. 6 and 7, which will be described later). Furthermore, although it is not assumed that, in the example shown in FIG. 5, it is assumed that, before the second transaction manager 12 determines the settlement result of the subsequent transaction T2, advance settlement notifications FB6 and FC6 are sent from the second service proxy 22 and the third service proxy 23 to the second transaction manager 12.

[0100] Therefore, in the process of determining the settlement result of the subsequent transaction T2 described above, the second transaction manager 12 determines the settlement result (commit (success) / rollback (failure)) of the subsequent transaction T2 based on the contents of the prepare vote for the subsequent transaction T2 and the preceding settlement notification received from each service proxy. However, if the received preceding settlement notification FA6 indicates a rollback, the second transaction manager 12 also determines the settlement result of the subsequent transaction T2 to be a rollback (chained rollback).

[0101] Then, the first service proxy 21, having received the settlement notification FA7 of the subsequent transaction T2, performs processing corresponding to the settlement notification FA7 in the subsequent transaction T2.

[0102] Specifically, if the settlement notification FA7 of the subsequent transaction T2 is commit (success), the first service proxy 21 deletes the service control information and service execution order information and terminates the distributed transaction for the first service unit 31. On the other hand, if the settlement notification FA7 of the subsequent transaction T2 is rollback (failure), the first service proxy 21 calls the first service unit 31 to execute a compensation transaction, and then deletes the service control information and service execution order information and terminates the distributed transaction for the first service unit 31.

[0103] (Example of control behavior when a distributed transaction is successful) Next, a description will be given of an example of control operations when the conclusion result of a distributed transaction performed in the distributed transaction control system 1 is successful (committed). Fig. 6 is a diagram showing a control operation flow when a distributed transaction is successful in the distributed transaction control system 1.

[0104] 6 shows the flow of processing operations after the first service proxy 21 acquires the lock of the preceding transaction T1 for the sake of simplicity. The flow of the update process of the service execution order information, which is performed during the execution of a distributed transaction for the first service unit 31, is also described here.

[0105] First, when the first service proxy 21 receives the service execution request FA, it performs processing to acquire a lock on the preceding transaction T1 for the first service unit 31. At this time, the first service proxy 21 accesses the data store 21a of the information processing device 61 that has the first service proxy 21 and updates the service execution order information (see FIG. 3) (arrow D1 in the figure). Specifically, the first service proxy 21 sets the registration number of the execution order of the preceding transaction T1 that has acquired the lock this time in the service execution order information. Furthermore, the first service proxy 21 associates the ID of the preceding transaction T1 ("T1"), the ID of the transaction manager in charge ("TM1"), and the execution status of the preceding transaction T1 ("in progress") with the set registration number and stores them.

[0106] Furthermore, when the lock is acquired for the preceding transaction T1, the first service proxy 21 starts lock wait processing for the subsequent transaction T2.

[0107] After acquiring the lock for the preceding transaction T1, the first service proxy 21 calls the first service unit 31 for the preceding transaction T1 (arrow FA1 in the figure) and performs application processing (data update) for the first service unit 31. The first service proxy 21 then obtains the execution result of the preceding transaction T1 for the first service unit 31 (arrow FA2 in the figure). Next, the first service proxy 21 releases the lock for the preceding transaction T1. That is, the lock for the preceding transaction T1 is released (early lock release) before receiving the settlement notification FA4 for the preceding transaction T1. After that, the first service proxy 21 sends a prepare vote FA3 for the preceding transaction T1 for the first service unit 31 to the first transaction manager 11.

[0108] Furthermore, when the lock on the preceding transaction T1 is released, the first service proxy 21 performs lock acquisition processing for the subsequent transaction T2 in the subsequent transaction T2 (arrow R in the figure). At this time, the first service proxy 21 accesses the data store 21a and updates the service execution order information (see FIG. 3) (arrow D2 in the figure). Specifically, the first service proxy 21 sets the registration number of the execution order of the subsequent transaction T2 that has acquired the lock this time (= the registration number of the preceding transaction T1 + 1) in the service execution order information. Furthermore, the first service proxy 21 associates the ID of the subsequent transaction T2, "T2," the ID of the transaction manager in charge, "TM2," and the execution status of the subsequent transaction T2, "running," with the registration number it has set, and stores them.

[0109] Thereafter, the first service proxy 21 calls the first service unit 31 for the subsequent transaction T2 (arrow FA1 in the figure) and performs application processing (data update) for the first service unit 31. The first service proxy 21 then obtains the execution result of the subsequent transaction T2 for the first service unit 31 (arrow FA2 in the figure). Next, the first service proxy 21 releases the lock on the subsequent transaction T2. ​​Thereafter, the first service proxy 21 sends a prepare vote FA5 for the subsequent transaction T2 for the first service unit 31 to the second transaction manager 12. Note that in the example shown in FIG. 6, at the time of sending the prepare vote FA5, the first service proxy 21 has not yet received the settlement notification FA4 for the preceding transaction T1 from the first transaction manager 11. Therefore, the first service proxy 21 sends the prepare vote FA5 to the second transaction manager 12, adding the settlement wait instruction information for the preceding transaction T1.

[0110] The second transaction manager 12, which has received the prepare vote FA5 for subsequent transaction T2, performs a settlement waiting process for preceding transaction T1 based on the settlement waiting instruction information for preceding transaction T1 attached to the prepare vote FA5. The second transaction manager 12 then waits until it receives a notice FA6 of the preceding transaction T1's settlement from the first service proxy 21.

[0111] 6, after the second transaction manager 12 receives the prepare vote FA5 for the subsequent transaction T2, the first transaction manager 11 determines the settlement result (commit (success) / rollback (failure)) of the preceding transaction T1 for the first service unit 31. Then, the first transaction manager 11 sends a corresponding settlement notification FA4 to the first service proxy 21. Note that in the example shown in FIG. 6, since the settlement result of the preceding transaction T1 is commit (success), the first transaction manager 11 sends the settlement notification FA4 of commit (success) to the first service proxy 21.

[0112] 6, before the first transaction manager 11 determines the settlement result of preceding transaction T1, the second service proxy 22 sends a prepare vote FB3 for preceding transaction T1 for the second service unit 32 to the first transaction manager 11, and the third service proxy 23 sends a prepare vote FC3 for preceding transaction T1 for the third service unit 33 to the first transaction manager 11. Therefore, in the process of determining the settlement result of preceding transaction T1 described above, the first transaction manager 11 determines the settlement result (commit) of preceding transaction T1 based on the contents of the prepare votes for preceding transaction T1 received from each service proxy.

[0113] Upon receiving the settlement notification FA4 (commit) of the preceding transaction T1, the first service proxy 21 accesses the data store 21a and updates the service execution order information (see FIG. 3) for the preceding transaction T1 (arrow D3 in the figure). Specifically, the first service proxy 21 changes the execution state of the preceding transaction T1 associated with the registration number of the preceding transaction T1 from "in progress" to "settled" in the service execution order information.

[0114] Furthermore, the first service proxy 21, which has received the settlement notification FA4 (commit) of the preceding transaction T1, sends a preceding settlement notification FA6 (commit) to the second transaction manager 12 for the preceding transaction T1.

[0115] Upon receiving the preceding settlement notification FA6 from the first service proxy 21, the second transaction manager 12 releases the settlement wait state for the preceding transaction T1. The second transaction manager 12 then determines the settlement result (commit (success) / rollback (failure)) of the subsequent transaction T2. ​​The second transaction manager 12 then sends a corresponding settlement notification FA7 to the first service proxy 21. Note that in the example shown in FIG. 6, the settlement result of the subsequent transaction T2 is commit (success), so the second transaction manager 12 sends the settlement notification FA7 of commit (success) to the first service proxy 21.

[0116] 6, it is assumed that, before the second transaction manager 12 determines the settlement result of subsequent transaction T2, a prepare vote FB5 for subsequent transaction T2 for the second service unit 32 is sent from the second service proxy 22 to the second transaction manager 12, and a prepare vote FC5 for subsequent transaction T2 for the third service unit 33 is sent from the third service proxy 23 to the second transaction manager 12. Furthermore, although not shown in the figures or in a detailed description, it is assumed that, in the example shown in FIG. 6, before the second transaction manager 12 determines the settlement result of subsequent transaction T2, advance settlement notifications FB6 and FC6 are sent from the second service proxy 22 and the third service proxy 23 to the second transaction manager 12.

[0117] Therefore, in the process of determining the settlement result of the subsequent transaction T2 described above, the second transaction manager 12 determines the settlement result (commit) of the subsequent transaction T2 based on the contents of the prepare vote and preceding settlement notification for the subsequent transaction T2 received from each service proxy.

[0118] Upon receiving the settlement notification FA7 (commit) of the subsequent transaction T2, the first service proxy 21 accesses the data store 21a and updates the service execution order information (see FIG. 3) for the subsequent transaction T2 (arrow D4 in the figure). Specifically, the first service proxy 21 changes the execution state of the subsequent transaction T2 associated with the registration number of the subsequent transaction T2 in the service execution order information from "in progress" to "settled."

[0119] Thereafter, the first service proxy 21 accesses the data store 21a and deletes the service execution order information (see FIG. 3) (arrow D5 in the figure). At this time, the first service proxy 21 also deletes the service control information (see FIG. 4) stored in the storage device 202 of the information processing device 61 that has the first service proxy 21, although this is not shown in the figure.

[0120] In the example shown in FIG. 6, the distributed transaction processing for the first service unit 31 is then completed by the above-described deletion processing of the service execution order information and the service control information.

[0121] (Example of control behavior when a distributed transaction fails) Next, we will explain an example of control operation when the settlement result of a distributed transaction performed in the distributed transaction control system 1 is failure (rollback). Also, we will explain an example of control operation when the settlement result of the preceding transaction T1 is rollback (failure).

[0122] Fig. 7 is a diagram showing the control operation flow when a distributed transaction fails in the distributed transaction control system 1. For the sake of simplicity, Fig. 7 shows the flow of processing operations after the first service proxy 21 acquires the lock for the preceding transaction T1. The flow of the process of updating the service execution order information, which is performed during the execution of the distributed transaction for the first service unit 31, is also explained here.

[0123] As is clear from a comparison of Fig. 7 and Fig. 6, the control operation flow up to the settlement waiting process for the preceding transaction T1 in the second transaction manager 12 when the distributed transaction fails as shown in Fig. 7 is the same as that when the distributed transaction is successful as shown in Fig. 6. Therefore, here we will omit the explanation of the control operation flow up to the settlement waiting process for the preceding transaction T1 in the second transaction manager 12 and will only explain the control operation flow thereafter.

[0124] In the example shown in Figure 7, after the second transaction manager 12 receives the prepare vote FA5 for subsequent transaction T2 and starts waiting for the settlement of preceding transaction T1, the first transaction manager 11 determines the settlement result of preceding transaction T1 (commit (success) / rollback (failure)).Then, the first transaction manager 11 sends a corresponding settlement notification FA4 to the first service proxy 21. However, in the example shown in Figure 7, since the settlement result of preceding transaction T1 for the first service unit 31 is rollback (failure), the first transaction manager 11 sends rollback information to the first service proxy 21 as the settlement notification FA4 of preceding transaction T1.

[0125] The first service proxy 21, which has received the settlement notification FA4 (rollback) of the preceding transaction T1, sends a preceding settlement notification FA6 (rollback) to the second transaction manager 12 for the preceding transaction T1.

[0126] Upon receiving the preceding settlement notification FA6 from the first service proxy 21, the second transaction manager 12 releases the settlement wait state for the preceding transaction T1. The second transaction manager 12 then determines the settlement result (commit (success) / rollback (failure)) of the subsequent transaction T2. ​​However, in the example shown in FIG. 7, since the settlement result of the preceding transaction T1 is rollback (failure), the second transaction manager 12 sets the settlement result of the subsequent transaction T2 to rollback, regardless of the execution result (prepare vote FA5) of the subsequent transaction T2. ​​In other words, the second transaction manager 12 executes a chained rollback.

[0127] The second transaction manager 12 then sends a settlement notification FA7 corresponding to the rollback (failure) to the first service proxy 21.

[0128] Upon receiving the rollback settlement notification FA7 of subsequent transaction T2, the first service proxy 21 performs a lock acquisition process to execute a compensation transaction (arrow RR in the figure). In the example shown in Figure 7, this lock acquisition process starts a transaction other than the preceding transaction T1 and subsequent transaction T2, and in this transaction, a compensation transaction (described below) for the first service unit 31 is executed. Note that the present invention is not limited to this, and a compensation transaction (described below) for the first service unit 31 may be executed in subsequent transaction T2, for example.

[0129] After acquiring the lock for the compensation transaction, the first service proxy 21 references the service execution order information (see FIG. 3) stored in the data store 21a and executes the compensation transaction according to the Saga pattern. Specifically, the first service proxy 21 first calls the first service unit 31 (arrow FA8 in the figure) and executes the compensation transaction for the subsequent transaction T2. ​​This process returns the state of the first service unit 31 to the state before the execution of the subsequent transaction T2. ​​The first service proxy 21 then obtains the execution result of the compensation transaction for the subsequent transaction T2 from the first service unit 31 (arrow FA9 in the figure).

[0130] After executing the compensation transaction for the subsequent transaction T2, the first service proxy 21 accesses the data store 21a and updates the service execution order information (see FIG. 3) (arrow D13 in the figure). Specifically, the first service proxy 21 changes the execution state of the subsequent transaction T2 associated with the registration number of the subsequent transaction T2 in the service execution order information from "in progress" to "settled."

[0131] The first service proxy 21 then calls the first service unit 31 (arrow FA8 in the figure) and executes a compensation transaction for the preceding transaction T1. This process returns the state of the first service unit 31 to the state before the execution of the preceding transaction T1. The first service proxy 21 then obtains the execution result of the compensation transaction for the preceding transaction T1 from the first service unit 31 (arrow FA9 in the figure).

[0132] After executing the compensation transaction for the preceding transaction T1, the first service proxy 21 accesses the data store 21a and updates the service execution order information (see FIG. 3) (arrow D14 in the figure). Specifically, the first service proxy 21 changes the execution state of the preceding transaction T1 associated with the registration number of the preceding transaction T1 in the service execution order information from "in progress" to "settled."

[0133] Thereafter, the first service proxy 21 releases the lock on the compensation transaction. At this time, the first service proxy 21 accesses the data store 21a and deletes the service execution order information (see FIG. 3) (arrow D15 in the figure). At this time, the first service proxy 21 also deletes the service control information (see FIG. 4) stored in the storage device 202 of the information processing device 61 that has the first service proxy 21, although this is not shown in the figure.

[0134] Then, in the example shown in FIG. 7, the distributed transaction processing for the first service unit 31 is completed by the above-mentioned unlocking of the compensation transaction and the deletion processing of the service execution order information and the service control information.

[0135] [Processing flow in distributed transaction control system] Next, specific processing contents of the distributed transaction executed by the distributed transaction control system 1 when executing the various control operation examples of the distributed transaction control system 1 described above will be described with reference to the drawings.

[0136] (Distributed transaction control processing performed by service proxies) 8 is a flowchart showing the procedure of a distributed transaction control process (information processing method) performed in a service proxy when a distributed transaction is executed by the distributed transaction control system 1. The distributed transaction control process shown in FIG. 8 is executed in parallel in each of the first service proxy 21, the second service proxy 22, and the third service proxy 23.

[0137] 8 is executed in software by the CPU of the information processing device (see FIG. 2) that has the service proxy. For example, the following distributed transaction control process by the first service proxy 21 is executed in software by the CPU 200 (see FIG. 2) of the information processing device 61 that has the first service proxy 21.

[0138] First, the service proxy (CPU) performs processing to receive notifications from the outside (S1). Specifically, the service proxy receives a service execution request from the main service unit 10 or a settlement notification from the transaction manager via the network 80. If there is no such notification, the service proxy waits in processing S1 until a notification is received.

[0139] Next, the service proxy determines whether the received notification is a service execution request (S2). If the service proxy determines in S2 that the received notification is not a service execution request (if S2 returns No), the service proxy performs the process of S12, which will be described later.

[0140] On the other hand, if the service proxy determines in S2 that the received notification is a service execution request (if S2 returns a Yes result), the service proxy determines whether the lock flag is set to "unlock" (S3).

[0141] The lock flag indicates whether or not a transaction or compensation transaction is being executed during a lock period, and is stored in the storage device (RAM) of an information processing device (see Figure 2) that has a service proxy. The lock flag is set to either "locked" (1) or "unlocked" (0). Specifically, under the control of the service proxy, the lock flag is set to "locked" during the period from lock acquisition to lock release (during the execution of the transaction or compensation transaction). Furthermore, the lock flag is set to "unlocked" during other periods (timings), such as when the lock is released and thereafter, or during the lock wait period for the subsequent transaction T2.

[0142] If the service proxy determines in S3 that the lock flag is not set to "unlocked" (it is set to "locked") (if S3 returns No), the service proxy repeats the process of S3. On the other hand, if the service proxy determines in S3 that the lock flag is set to "unlocked" (if S3 returns Yes), the service proxy sets the lock flag to "locked" (S4). This process acquires a lock for the transaction to be processed.

[0143] Next, the service proxy performs a process to register (update) the service execution order information (S5). In this process, the service proxy accesses the data store (see FIGS. 1 and 2) of the information processing device that has the service proxy and updates the service execution order information (see FIG. 3). Specifically, the service proxy sets the registration number of the execution order of the transaction that has acquired the lock this time in the service execution order information, and stores the transaction ID, the corresponding transaction manager ID, and the execution status (running) of the transaction in association with the registration number.

[0144] Next, the service proxy calls the corresponding service unit, executes the application processing (data update) of that service unit, and obtains the execution result (S6). Next, the service proxy sets the lock flag to "unlock" (S7). This process releases the lock on the transaction to be processed.

[0145] Next, the service proxy determines whether preceding transaction T1 is currently being executed (S8). In this process, the determination result is Yes only if the transaction currently being processed is subsequent transaction T2 and preceding transaction T1 is currently being executed; otherwise, the determination result is No. At this time, the determination of whether preceding transaction T1 is currently being executed is made by referring to the service execution order information (see FIG. 3). If the execution status of preceding transaction T1 in the service execution order information is set to "in execution," it is determined that preceding transaction T1 is currently being executed.

[0146] If the service proxy determines in S8 that the preceding transaction T1 is not currently being executed (if the determination in S8 is No), the service proxy performs the processing of S10, which will be described later.

[0147] On the other hand, if the service proxy determines in S8 that the preceding transaction T1 is currently being executed (if S8 returns a Yes result), the service proxy adds instruction information to wait for the completion of the preceding transaction T1 to the prepare vote (FA5 in Figure 1) (S9).

[0148] After S9, or if S8 returns No, the service proxy sends a prepare vote via network 80 to the transaction manager (TM) responsible for managing the transaction currently being processed (S10). The prepare vote sent in this process contains information corresponding to the execution result (success / failure) of the service department's application processing (data update) obtained in S6. If S10 is performed after S9, a prepare vote with an instruction to wait for the settlement of preceding transaction T1 is sent to the transaction manager.

[0149] Next, the service proxy determines whether the operation of the information processing device having the service proxy has been stopped (S11). For example, if the operation of the information processing device having the service proxy has been stopped (interrupted) due to the end of operation of the distributed transaction control system 1 or maintenance, the determination result in S11 will be Yes. On the other hand, if the distributed transaction control system 1 is in operation, the determination result in S11 will be No.

[0150] In S11, if the service proxy determines that the operation of the information processing device having the service proxy has not been stopped (if S11 is judged as No), the service proxy returns the process to S1 and repeats the processes from S1 onwards. On the other hand, if the service proxy determines that the operation of the information processing device having the service proxy has been stopped (if S11 is judged as Yes), the service proxy ends the distributed transaction control process.

[0151] Returning to the explanation of the processing of S2, if the result of S2 is No (if the received notification is a settlement notification), the service proxy determines whether or not there is a subsequent transaction T2 (S12). In this processing, the service proxy accesses the corresponding data store (see FIGS. 1 and 2) and references the service execution order information (see FIG. 3) to determine whether or not a subsequent transaction T2 has been registered for the transaction currently being processed. If a subsequent transaction T2 for the transaction currently being processed has been registered in the service execution order information, the service proxy determines Yes as the result of the determination in S12; if no subsequent transaction T2 has been registered, the service proxy determines No as the result of the determination in S12.

[0152] If the service proxy determines in S12 that there is a subsequent transaction T2 (if S12 returns Yes), the service proxy sends information about the settlement of preceding transaction T1 (preceding settlement notification: FA6 in Figure 1) to the transaction manager in charge of managing subsequent transaction T2 (S13). Although not shown, if the settlement notification received in S13 for the currently being processed transaction (preceding transaction T1) indicates commit (success), the service proxy changes the execution status of the corresponding transaction registered in the service execution order information (see Figure 3) from "in progress" to "settled."

[0153] After the process of S13, the service proxy performs the process of S11 described above (processing to determine whether the operation of the service proxy has been stopped).

[0154] On the other hand, if the service proxy determines in S12 that there is no subsequent transaction T2 (if S12 returns No), the service proxy determines whether the content of the settlement notification is commit (success) (S14).

[0155] In S14, if the service proxy determines that the content of the settlement notification is commit (success) (if S14 is judged as Yes), the service proxy changes the execution status of the corresponding transaction registered in the service execution order information (see Figure 3) from "in progress" to "settled" (S15).

[0156] Next, the service proxy deletes the service execution order information (see FIG. 3) stored in the corresponding data store (see FIGS. 1 and 2) and the service control information (see FIG. 4) stored in the corresponding storage device (S16). After that, the service proxy performs the process of S11 described above (processing to determine whether the service proxy has stopped operating).

[0157] On the other hand, if the service proxy determines in S14 that the content of the settlement notification is not commit (success) (if S14 returns No), that is, if the content of the settlement notification of subsequent transaction T2 is rollback (failure), the service proxy sets the lock flag to "locked" (S17). This process acquires a lock on the compensation transaction.

[0158] Next, the service proxy sets the registration number (in the order of lock acquisition: see Figure 3) of the transaction for which it has received the settlement notification to the control parameter "i" (S18). The control parameter "i" to which the registration number is set is stored in the memory device (RAM) of the information processing device (see Figure 2) that has the service proxy.

[0159] Next, the service proxy calls the corresponding service unit, executes a compensation transaction for the transaction of the control parameter "i" (registration number), and obtains the execution result (S19).

[0160] Next, the service proxy changes the execution status of the transaction with the registration number corresponding to the control parameter "i" registered in the service execution order information (see Figure 3) from "in progress" to "settled" (S20). Next, the service proxy subtracts 1 from the control parameter "i" (registration number) and sets the result of the subtraction to the control parameter "i" (S21).

[0161] Next, the service proxy determines whether the execution status of the transaction with the registration number corresponding to the control parameter "i" is "settled" (S22). In this process, the service proxy makes the determination by referring to the service execution order information (see FIG. 3) stored in the corresponding data store (see FIGS. 1 and 2). If the transaction with the registration number corresponding to the control parameter "i" is the target of a compensation transaction at the time of processing S22, the execution status of the transaction is "in progress," and the determination result of S22 is No. On the other hand, if the transaction with the registration number corresponding to the control parameter "i" is not the target of a compensation transaction at the time of processing S22, the execution status of the transaction is "settled" (see, for example, registration number "1" in FIG. 3), and the determination result of S22 is Yes. Also, if the transaction with the registration number corresponding to the control parameter "i" is not registered in the service execution order information (see FIG. 3) at the time of processing S22, the determination result of S22 is Yes.

[0162] If the service proxy determines in S22 that the execution status of the transaction with the registration number corresponding to the control parameter "i" is not "settled" (if S22 is judged as No), the service proxy returns the process to S19 and repeats the processes from S19 onwards. In this embodiment, the process from S19 to S21 is repeated until the judgment result of S22 is judged as Yes, thereby realizing a compensation transaction according to the Saga pattern.

[0163] On the other hand, if the service proxy determines in S22 that the execution status of the transaction with the registration number corresponding to the control parameter "i" is "settled" (if S22 returns "Yes"), the service proxy sets the lock flag to "unlocked" (S23). This process releases the lock on the compensation transaction, and the compensation transaction according to the Saga pattern ends.

[0164] Next, the service proxy deletes the service execution order information (see FIG. 3) stored in the corresponding data store (see FIGS. 1 and 2) and the service control information (see FIG. 4) stored in the corresponding storage device (S24). After that, the service proxy performs the process of S11 described above (processing to determine whether the service proxy has stopped operating). In this embodiment, when a distributed transaction is executed, the service proxy performs distributed transaction control processing as described above.

[0165] (Distributed transaction management processing performed by the transaction manager) Fig. 9 is a flowchart showing the procedure for distributed transaction management processing performed by the transaction manager when a distributed transaction is executed by the distributed transaction control system 1. The distributed transaction management processing shown in Fig. 9 is executed in parallel by the first transaction manager 11 and the second transaction manager 12. Although not shown in the figure, the distributed transaction management processing by the transaction manager shown in Fig. 9 is executed repeatedly while the distributed transaction control system 1 is running.

[0166] 9 is executed in software by the CPU of an information processing device (see FIG. 2) that has the transaction manager. For example, the following distributed transaction management process by the first transaction manager 11 is executed in software by the CPU 100 (see FIG. 2) of an information processing device 51 that has the first transaction manager 11.

[0167] First, the transaction manager (CPU) creates an initialized prepare vote waiting list (S31). The prepare vote waiting list is a list that indicates whether prepare votes and advance settlement notifications have been received from each service proxy (service unit) managed by the transaction manager, and is stored in the storage device of the information processing device that has the transaction manager (see Figure 2).

[0168] Here, the configuration of the initialized prepare vote waiting list created in the processing of S31 will be specifically described with reference to Fig. 10. Fig. 10 is a diagram showing an example of the configuration of the initialized prepare vote waiting list created by the second transaction manager 12.

[0169] In the prepare voting waiting list, as shown in Figure 10, a data set is set for each service proxy (service section) managed by the transaction manager, which associates the transaction ID, previous transaction ID, service ID, and service execution result / previous settlement result.

[0170] The Service Execution Result / Preceding Settlement Result column is set with information corresponding to the execution result of the transaction in each service unit managed by the transaction manager. Also, if there is a preceding transaction T1 for the transaction being processed, information regarding the preceding settlement notification of the preceding transaction T1 is also set in the Service Execution Result / Preceding Settlement Result column. As the service execution result, if the prepare vote has not yet been received, information corresponding to "Waiting for Vote" is set, and after the prepare vote has been received, information corresponding to the content of the prepare vote ("Success" / "Failure") is set. Also, as the preceding settlement result, if the preceding settlement notification has not yet been received, information corresponding to "Waiting for Vote" is set, and after the preceding settlement notification has been received, information corresponding to the content of the preceding settlement notification ("Success" / "Failure") is set.

[0171] In the process of S31, only information related to prepare votes that is registered in common regardless of whether the transaction being processed is a preceding transaction or a succeeding transaction is set in the initialized prepare vote waiting list created by the second transaction manager 12. Specifically, for each service proxy (service unit) managed by the transaction manager, a data set (with the preceding transaction ID left blank) that associates the transaction ID, service ID, and service execution result (information related to prepare votes) is set.

[0172] Therefore, in the initialized prepare vote waiting list created by the second transaction manager 12 shown in Figure 10, the transaction ID is set to its own ID "T2", no information is set to the preceding transaction ID, the service ID is set to the corresponding ID ("SA", "SB", or "SC"), and the service execution result / preceding settlement result is set to "waiting for vote" for the prepare vote (service execution result).

[0173] Returning to the explanation of the processing flow in FIG. 9, after the processing of S31, the transaction manager performs processing to receive notifications from each service proxy (S32).

[0174] If the transaction manager is the first transaction manager 11, the notification from each service proxy is only a prepare vote (see FA3, FB3, and FC3 in FIG. 1). Therefore, in this case, in the processing of S32, the transaction manager performs processing to receive the prepare vote from each service proxy. On the other hand, if the transaction manager is the second transaction manager 12, the notification from each service proxy is a prepare vote and a pre-settlement notification (see FA5, FB5, FC5, FA6, FB6, and FC6 in FIG. 1). Therefore, in this case, in the processing of S32, the transaction manager performs processing to receive the prepare vote or pre-settlement notification from each service proxy. However, if there is no notification from each service proxy, the transaction manager performs standby processing in the processing of S32. In other words, the processing from S32 onwards, described below, is performed when the transaction manager receives a notification from each service proxy.

[0175] Next, the transaction manager determines whether there is a preceding transaction (S33). In this process, the transaction manager determines whether the received notification is a prepare vote and whether the prepare vote includes a wait-for-resolution instruction for preceding transaction T1. If the received prepare vote includes a wait-for-resolution instruction for preceding transaction T1, the transaction manager determines Yes in S33. If the received prepare vote does not include a wait-for-resolution instruction for preceding transaction T1, or if the received notification is a preceding resolution notification, the transaction manager determines No in S33.

[0176] If the transaction manager determines in the process of S33 that there is no preceding transaction (if S33 returns a No), the transaction manager performs the process of S35, which will be described later. On the other hand, if the transaction manager determines in the process of S33 that there is a preceding transaction (if S33 returns a Yes), the transaction manager adds information about the preceding settlement result to the prepare vote waiting list (S34).

[0177] Fig. 11 is a diagram showing an example of the configuration of the prepare vote waiting list to which information about the advance settlement result has been added in the processing of S34. Note that the example shown in Fig. 11 is also a prepare vote waiting list created by the second transaction manager 12. In the example shown in Fig. 11, the data set set in the bottom column in the prepare vote waiting list is the information about the advance settlement result that has been added.

[0178] In the prepare vote waiting list shown in Figure 11, in the information about the added advance settlement result, the transaction ID is set to its own ID "T2", the preceding transaction ID is set to "T1", and no information is set to the service ID. Also, since the processing time of S34 is when the prepare vote for subsequent transaction T2 is received and before the advance settlement notification for preceding transaction T1 is received, the service execution result / advance settlement result column is set to "waiting for vote" in the advance settlement notification. Furthermore, when the advance settlement notification is received, the information in the service execution result / advance settlement result column is updated from "waiting for vote" to the content of the advance settlement notification ("success" / "failure").

[0179] 9, after processing S34 or if S33 is judged as No, the transaction manager updates the information of the service execution result / preliminary settlement result in the prepare vote waiting list (S35). In this process, the transaction manager changes the information of the service execution result / preliminary settlement result in the prepare vote waiting list corresponding to the received notification (prep vote or preliminary settlement notification) from "waiting for vote" to the notification content ("success" / "failure").

[0180] Next, the transaction manager determines whether all notifications have been accepted (received) (S36).

[0181] In the process of S36, if the transaction manager determines that not all notifications have been accepted (received) (if the result of S36 is No), the transaction manager returns the process to the process of S32 and repeats the processes from S32 onwards.

[0182] On the other hand, if, in the processing of S36, the transaction manager determines that all notifications have been accepted (received) (if S36 judges Yes), the transaction manager decides whether to commit (succeed) or roll back (fail) the transaction (preceding transaction T1 or subsequent transaction T2) based on the contents of all notifications (S37).

[0183] The transaction manager then sends the result determined in the process of S39 to each service proxy as a settlement notice (S38). After the process of S37, the transaction manager then ends the distributed transaction management process.

[0184] [Various effects] As described above, in the distributed transaction control system 1 of this embodiment, a service proxy equipped with a transaction concurrency control function is provided for each service unit, and the service unit is called by the service proxy to execute multiple transactions in parallel. At this time, a lock early release technique is applied. Also, at this time, information regarding the execution order of multiple transactions (service execution order information (see FIG. 3)) is stored in a data store each time a lock is acquired.

[0185] In this embodiment, the service proxy can send a settlement notification wait instruction for the preceding transaction to the transaction manager managing the subsequent transaction based on the service execution order information. Furthermore, the transaction manager managing the subsequent transaction that receives the settlement notification wait instruction waits without issuing a settlement notification until it receives a settlement notification for the preceding transaction.

[0186] Therefore, when multiple transactions for the same resource are executed in parallel, if the above-described control processing is performed by the service proxy, the multiple transactions can be executed in the correct order even if the early lock release technique is applied. In other words, in this embodiment, when multiple transactions are executed in parallel, the lock period can be shortened and the serializability requirement can be satisfied.

[0187] Furthermore, in the distributed transaction control processing of this embodiment described above, the transaction manager managing the subsequent transaction can issue a settlement notification (commit / rollback) for the subsequent transaction while understanding the contents of the settlement notification for the preceding transaction. If the settlement result of the preceding transaction is a rollback (failure), the transaction manager managing the subsequent transaction will roll back the settlement result of the subsequent transaction, regardless of the actual settlement result (commit / rollback) of the subsequent transaction. In other words, this embodiment can achieve chained rollbacks.

[0188] Furthermore, in this embodiment, if the parallel execution of multiple transactions results in a rollback (failure), the service proxy executes the compensation transactions in the reverse order of the data update (transaction execution) order based on the service execution order information (see FIG. 3). Therefore, in this embodiment, in the event of a rollback (failure), the data state of the service unit can be reliably restored to the state before the transaction was executed, according to the Saga pattern. In other words, in this embodiment, data consistency (recoverability) can be guaranteed in the event of a rollback (failure).

[0189] As described above, the distributed transaction control system 1 of this embodiment can perform optimal control in distributed transactions that employ the Saga pattern and early lock release.

[0190] Furthermore, in the distributed transaction control system 1 of this embodiment, the transaction manager and the service proxy are configured as separate information processing devices (separate entities). In such a configuration, transaction concurrency control for the service units can be performed by the middleware (service proxy). Therefore, this embodiment can flexibly accommodate various combinations of service units, regardless of whether or not the service units have concurrency control. Furthermore, because transaction concurrency control does not need to be handled by the transaction manager or service units, an increase in the processing load on the transaction manager and service units can be suppressed.

[0191] [Various variations] The above describes the distributed transaction control system 1 according to various embodiments of the present invention, but the present invention is not limited to these, and various other modifications are possible as long as they do not deviate from the gist of the present invention as set forth in the claims.

[0192] In the above embodiment, an example has been described in which the number of transaction managers included in the distributed transaction control system 1 is two, and parallel processing (distributed transactions) is performed for two transactions (preceding transaction T1 and subsequent transaction T2). However, the present invention is not limited to this. For example, the above-described distributed transaction control technology can also be applied when the number of transaction managers included in the distributed transaction control system 1 is three or more, and parallel processing (distributed transactions) is performed for three or more transactions. In this case, the above-described distributed transaction control technology can be applied between two transactions (preceding transaction and subsequent transaction) that are adjacent in execution order among the three or more transactions.

[0193] In the above embodiment, the first transaction manager 11 manages the preceding transaction T1 and the second transaction manager 12 manages the subsequent transaction T2, but the present invention is not limited to this. For example, the first transaction manager 11 may manage the subsequent transaction T2 and the second transaction manager 12 may manage the preceding transaction T1.

[0194] In the above embodiment, an example has been described in which each of the multiple service units used in the distributed transaction control system 1 is a service unit that does not have a concurrency control function, but the present invention is not limited to this. For example, the multiple service units used in the distributed transaction control system 1 may include a service unit that has a concurrency control function. In this case, the service unit that does not have a concurrency control function is connected to the transaction manager via a service proxy that has a concurrency control function, as in the above embodiment, and the service unit that has a concurrency control function is connected directly to the transaction manager.

[0195] In the above embodiment, the first transaction manager 11, the second transaction manager 12, and each service proxy are configured as separate information processing devices (separate entities), but the present invention is not limited to this. For example, some service proxies may be included in either the first transaction manager 11 or the second transaction manager 12. Alternatively, for example, the first transaction manager 11 and the second transaction manager 12 may be configured as being included in a single information processing device. In this case, the processes executed by each transaction manager may be executed using a common CPU, or may be executed using separate CPUs.

[0196] In the above embodiment, an example was described in which the various control operation functions performed by the transaction manager and service proxy were configured using software, but the present invention is not limited to this, and some or all of the various control operation functions may be configured using hardware.

[0197] Furthermore, the above-described embodiment has described the configuration of the device in detail and specifically to clearly explain the present invention, and is not necessarily limited to an embodiment having all of the described configurations. Furthermore, the position, size, shape, range, etc. of each component shown in the drawings, etc. may not represent the actual position, size, shape, range, etc., in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc., disclosed in the drawings, etc. Furthermore, the present invention may have various other applications and modifications without departing from the gist of the present invention as set forth in the claims. [Explanation of symbols]

[0198] 1... Distributed transaction control system, 10... Main service unit, 11... First transaction manager, 12... Second transaction manager, 21... First service proxy, 21a, 23a, 23a... Data store, 22... Second service proxy, 23... Third service proxy, 31... First service unit, 32... Second service unit, 33... Third service unit, 51-53, 61-63, 70-73... Information processing device, 80... Network

Claims

1. a plurality of transaction management units that manage a plurality of transactions executed in a predetermined order for external service units; a transaction control unit connected to the plurality of transaction management units and the external service unit, calling the external service unit to execute the plurality of transactions in the predetermined order, and if the execution result of the plurality of transactions is failure, calling the external service unit to execute a plurality of compensation transactions for each of the plurality of transactions in the reverse order to the predetermined order to return a state of the external service unit to a state before the execution of the plurality of transactions, and when executing each of the plurality of transactions, before calling the external service unit, operating a lock function that disables execution of transactions other than a transaction to be processed among the plurality of transactions, and releasing the lock function after the transaction to be processed is executed and before outputting an execution result of the transaction to be processed to a transaction management unit in the plurality of transaction management units that manages the transaction to be processed. Information processing system.

2. a storage unit for storing predetermined information relating to the predetermined order; The transaction control unit controls the execution order of the plurality of transactions and the execution order of the plurality of compensation transactions based on the predetermined information stored in the storage unit. The information processing system according to claim 1 .

3. When outputting an execution result of a specific transaction executed next to a predetermined transaction included in the plurality of transactions to the transaction manager that manages the specific transaction, the transaction control unit is capable of adding, to the execution result of the specific transaction, specific information indicating that the execution result of the predetermined transaction has not yet been determined as successful or unsuccessful, based on the predetermined information, and outputting the execution result to the transaction manager that manages the specific transaction. The information processing system according to claim 2 .

4. When the transaction manager, which manages the specific transaction, acquires the execution result of the specific transaction to which the specific information is added, it waits until it acquires information on the success / failure determination result of the execution result of the specific transaction from the transaction controller. The information processing system according to claim 3 .

5. The transaction control unit outputs the execution result of the predetermined transaction to the transaction management unit that manages the predetermined transaction, and when it obtains a decision result of success / failure for the execution result of the predetermined transaction from the transaction management unit, it outputs information about the decision result to the transaction management unit that manages the specific transaction. The information processing system according to claim 4 .

6. When the transaction management unit, which manages the specific transaction, receives a failure determination result for the execution result of the specific transaction from the transaction control unit, the transaction management unit determines a failure determination result for the execution result of the specific transaction and outputs the failure determination result to the transaction control unit. The information processing system according to claim 5 .

7. The transaction control unit does not clear the predetermined information stored in the storage unit even if the operation of the transaction control unit stops during the execution of the plurality of transactions and / or the execution of the plurality of compensation transactions. The information processing system according to claim 2 .

8. The transaction control unit is configured separately from the plurality of transaction management units, and is connected to the plurality of transaction management units and the external service unit via an external network. The information processing system according to claim 1 .

9. a transaction control unit connected to an externally provided service unit and a plurality of transaction management units that manage a plurality of transactions to be executed in a predetermined order for the service unit, calling the service unit to execute the plurality of transactions in the predetermined order, and if the execution result of the plurality of transactions is failure, calling the service unit to execute a plurality of compensation transactions for each of the plurality of transactions in the reverse order to the predetermined order so as to return the state of the service unit to the state before the execution of the plurality of transactions, and when executing each of the plurality of transactions, operating a lock function that disables execution of transactions other than a transaction to be processed among the plurality of transactions before calling the service unit, and releasing the lock function after the transaction to be processed is executed and before outputting the execution result of the transaction to be processed to a transaction management unit that manages the transaction to be processed within the plurality of transaction management units. Information processing device.

10. An information processing method performed by an information processing device including an externally provided service unit and a transaction control unit connected to a plurality of transaction management units that respectively manage a plurality of transactions executed in a predetermined order for the service unit, the transaction control unit calls the service unit to execute the plurality of transactions in the predetermined order; If the execution result of the plurality of transactions is a failure, the transaction control unit calls the service unit and executes a plurality of compensation transactions for each of the plurality of transactions in a reverse order to the predetermined order, in order to return the state of the service unit to a state before the execution of the plurality of transactions; When the transaction control unit executes each of the plurality of transactions, before calling the service unit, the transaction control unit activates a lock function that disables execution of transactions other than a transaction to be processed among the plurality of transactions; the transaction control unit releasing the lock function after execution of the transaction to be processed and before outputting an execution result of the transaction to be processed to a transaction management unit that manages the transaction to be processed among the plurality of transaction management units. Information processing methods.

Images