Control Method, Adapter

Abstract

To start a service promptly after a data store recovers from a data-store down.SOLUTION: According to this method, in a process by an adapter that is connected to a data store which has a non-distributed transaction control function, the data store includes a commitment managing map that stores a GXID which is an identifier of a distributed transaction. When a commit command is accepted from a transaction manager, a GXID adding query that adds the GXID to be committed to the commitment managing map is executed through a transaction at the data-store side, and the transaction at the data-store side is then committed. When the data store recovers from a data-store down, with reference to the commitment managing map, a new transaction is started at the data store for the distributed transaction in an in-doubt state, and a query that has been perpetuated is restored, and the distributed transaction which is subjected to the commitment but is still in the in-doubt state is committed using a confirmation process.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a control method and an adapter. [Background technology]

[0002] The concept of distributed transaction processing has existed since the 1990s, but at that time, the growth in machine performance such as CPUs was remarkable, and multiple databases could be stored on a single server using machine resources gained by scaling up, so the demand for distributed transaction processing did not increase much. In recent years, microservices have become popular due to the spread of cloud and containers. In microservices, each independent service has its own data store. A data store is a general term for functions such as databases and KVS (Key-Value Store) that aim to store data. Therefore, the demand for distributed transaction processing is increasing in order to realize advanced services using multiple microservices. Here, with emerging data store products such as KVS, there are many development items that have a higher priority than distributed transaction processing, such as scalability and availability, so even if transaction control functions are implemented, the implementation of distributed transaction processing tends to be postponed. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2015-514247 Summary of the Invention [Problem to be solved by the invention]

[0004] In the invention described in Patent Document 1, the process when the data store recovers from a downtime is not clear. [Means for solving the problem]

[0005] A control method according to a first aspect of the present invention is a control method executed by an adapter connected to a data store having a transaction control function but not having a distributed transaction control function, the data store having a commit management map which is an area for storing a GXID which is an identifier of a distributed transaction, and when the adapter receives an incoming query which is a query from an application program, the adapter locks data targeted by the incoming query, temporarily stores the incoming query, and then executes a command to the data store. The data store controls the Transaction As before a persistence process for determining whether or not a commit is possible using lock information when the adapter receives a prepare command from a transaction manager that manages distributed transaction control among a plurality of the data stores, and persisting the GXID to be committed and the temporarily stored received query if the commit is possible; and a persistence process for persisting a GXID addition query, which is a query for adding the GXID to be committed to the commit management map, to the data store when the adapter receives a commit command from the transaction manager. The data store controls the Transaction As a After executing the above to The method includes a confirmation process that commits a transaction, and a store resume process in which, when the data store recovers from a down state, the adapter refers to the commit management map, starts a new transaction in the data store for the in-doubt distributed transaction, replays the persisted query, and commits the distributed transaction that should have been committed but remains in an in-doubt state. A control method according to a second aspect of the present invention is a control method executed by an adapter connected to a data store having neither a transaction control function nor a distributed transaction control function, the data store having a commit management map which is an area for storing a GXID which is an identifier of a distributed transaction, and when the adapter receives an incoming query which is a query from an application program, the adapter performs an acting process of locking data which is the target of the incoming query, obtaining initial data which is the target of the incoming query from the data store, simulating execution of the incoming query on behalf of the data store using the initial data or intermediate data, and retaining a result of the simulation as the intermediate data, and the adapter performs distributed transaction control between a plurality of the data stores. The adapter includes a persistence process which, when it receives a prepare command from a transaction manager it manages, uses lock information to determine whether or not commit is possible, and if commit is possible, persists the GXID, the initial data, and the simulated received query to be committed; a commitment process which, when it receives a commit command from the transaction manager, causes the data store to execute a series of queries that concatenate a query to update the initial data, the received query, and a GXID addition query that is a query to add the GXID to the commit management map; and, when the data store recovers from a downtime, a store resume process which, by referring to the commit management map of the data store, commits distributed transactions that should have been committed but remain in an in-doubt state. An adapter according to a third aspect of the present invention is an adapter that has a transaction control function and is connected to a data store that does not have a distributed transaction control function, the data store having a commit management map that is an area for storing a GXID that is an identifier for a distributed transaction, and when the adapter receives an incoming query from an application program, the adapter locks data that is the target of the incoming query, temporarily stores the incoming query, and then executes a command to the data store. The data store controls transaction As beforea persistence unit that, when the adapter receives a prepare command from a transaction manager that manages distributed transaction control among a plurality of the data stores, determines whether or not a commit is possible using lock information, and if the commit is possible, persists the GXID to be committed and the temporarily stored received query; and, when the adapter receives a commit command from the transaction manager, persists a GXID addition query, which is a query to add the GXID to be committed to the commit management map, to the data store. The data store controls the Transaction As a After executing the above to The adapter includes a confirmation processing unit that commits a transaction, and when the data store recovers from a down state, the adapter refers to the commit management map, starts a new transaction in the data store for the in-doubt distributed transaction, replays the persisted received query, and commits the distributed transaction that should have been committed but remains in an in-doubt state. Effect of the Invention

[0006] According to the present invention, when a data store recovers from a down state, service can be started quickly. [Brief description of the drawings]

[0007] [Figure 1] Overall configuration of the processing system [Diagram 2] A functional configuration diagram of a first RM adapter and a first KVS when the first KVS has a transaction control function. [Diagram 3] A functional configuration diagram of a first RM adapter and a first KVS when the first KVS does not have a transaction control function. [Figure 4] FIG. 13 is a diagram showing an example of a GXID management table. [Diagram 5] FIG. 13 is a diagram showing an example of a query management table. [Figure 6] FIG. 13 is a diagram showing an example of a lock management table. [Figure 7] FIG. 13 is a diagram showing an example of a temporary data management table. [Figure 8] An example of a commit management map [Figure 9] An example of a sequence number management file. [Figure 10] An example of a persistent query management file [Figure 11] An example of a permanent Tx management file [Figure 12] Flowchart showing the process of the TM reception program [Figure 13] Flowchart showing distributed Tx cleanup process [Figure 14] Flowchart showing distributed Tx start processing [Figure 15] Flowchart showing the process of the AP reception program [Figure 16] Flowchart showing the process of the AP reception program [Figure 17] Flowchart showing the process of the AP reception program [Figure 18] Flowchart showing distributed Tx preparation process [Figure 19] Flowchart showing distributed Tx preparation process [Figure 20] Flowchart showing distributed Tx determination first process [Figure 21] Flowchart showing distributed Tx determination second process [Figure 22] Flowchart showing the process of the Tx end detection program [Figure 23] Flowchart showing the process of the KVS cleaning program [Figure 24] Flowchart showing the processing of the KVS restart program [Diagram 25] Flowchart showing the processing of the RM adapter restart program [Figure 26] Flowchart showing lock management table cleanup processing [Figure 27] Flowchart showing lock management table update processing [Figure 28]Flowchart showing lock management table update processing [Figure 29] Flowchart showing lock management table update processing [Diagram 30] Flowchart showing lock management table verification processing [Diagram 31] Flowchart showing lock management table regeneration processing [Diagram 32] Diagram showing the process when the RM adapter receives xa_start and a query in pattern 1 [Diagram 33] Diagram showing the process when the RM adapter receives xa_prepare in pattern 1 [Diagram 34] A diagram showing the process when the KVS recovers from downtime in pattern 1 [Diagram 35] A diagram showing the process when the RM adapter recovers from a down state in pattern 1 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] --First embodiment-- Hereinafter, a first embodiment of a processing system will be described with reference to FIGS.

[0009] (composition) 1 is an overall configuration diagram of a processing system 1. The processing system 1 includes a TM 100, a first AP 110-1, a second AP 110-2, a first DBMS 130-1, a second DBMS 130-2, a first RM adaptor 150-1, a second RM adaptor 150-2, a third RM adaptor 150-3, a first KVS 160-1, a second KVS 160-2, and a third KVS 160-3. The first KVS 160-1, the second KVS 160-2, and the third KVS 160-3 form a KVS cluster 170.

[0010] The first AP 110-1 and the second AP 110-2 have a common configuration described later. The first AP 110-1 and the second AP 110-2 may include configurations other than those described later, and some configurations may be provided only in one of them. Hereinafter, when there is no need to distinguish between the first AP 110-1 and the second AP 110-2, they are referred to as AP 110. The processing system 1 shown in FIG. 1 includes two APs 110, but the processing system 1 only needs to include at least one AP 110, and there is no upper limit to the number of APs included.

[0011] The first DBMS 130-1 and the second DBMS 130-2 have a common configuration, which will be described later. The first DBMS 130-1 and the second DBMS 130-2 may include configurations other than those described later, and some configurations may be provided in only one of them. Hereinafter, when there is no need to distinguish between the first DBMS 130-1 and the second DBMS 130-2, they will be referred to as DBMS 130. The processing system 1 shown in FIG. 1 includes two DBMSs 130, but the processing system 1 may include zero or more DBMSs 130, and there is no upper limit to the number included.

[0012] The first KVS 160-1, the second KVS 160-2, and the third KVS 160-3 have a common configuration described later. The first KVS 160-1, the second KVS 160-2, and the third KVS 160-3 may include configurations other than those described later, and some configurations may be provided in only one of them. In the following, the first KVS 160-1, the second KVS 160-2, and the third KVS 160-3 are referred to as KVS 160 when there is no need to distinguish between them. In the following, the KVS 160 is also referred to as a "data store." The processing system 1 shown in FIG. 1 only needs to include at least two KVSs 160, and there is no upper limit to the number of KVSs included. In addition, the processing system 1 shown in FIG. 1 includes one KVS cluster 170, and there is no upper limit to the number of KVSs included, as long as it includes at least one KVS cluster 170. The TM 100, the AP 110, the DBMS 130, and the RM adapter 150 are each connected by a network. The communication between these devices may be wired or wireless.

[0013] The first RM adapter 150-1, the second RM adapter 150-2, and the third RM adapter 150-3 have a common configuration, which will be described later. The first RM adapter 150-1, the second RM adapter 150-2, and the third RM adapter 150-3 may include configurations other than those described later, and some configurations may be provided in only one of them. In the following, the first RM adapter 150-1, the second RM adapter 150-2, and the third RM adapter 150-3 are referred to as RM adapters 150 when there is no need to distinguish between them. In the following, the RM adapter 150 is also referred to as a "data store adapter" or an "adapter." Each RM adapter 150 corresponds to the KVS 160 in a one-to-one correspondence. In other words, the processing system 1 includes the same number of RM adapters 150 as the KVS 160.

[0014] In the following, a pair of a predefined RM adapter 150 and a KVS 160 will be expressed as a "pair," "corresponding," and "connected." For example, as shown in Fig. 1, the first RM adapter 150-1 can be expressed as corresponding to the first KVS 160-1. Also, the RM adapter 150 connected to the second KVS 160-2 can be expressed as the second RM adapter 150-2.

[0015] The KVS 160, which is a key-value store, may or may not have a transaction control function. The presence or absence of the transaction control function does not have to be common to the KVS 160 constituting the processing system 1. For example, only the first KVS 160-1 may have the transaction control function, and the second KVS 160-2 and the third KVS 160-3 may not have the transaction control function. Furthermore, when there is no distributed transaction being executed, in other words, when the GXID management table 204 of the corresponding RM adapter 150 is empty, the transaction control function of the KVS 160 may be enabled or disabled. Depending on whether the KVS 160 has a transaction control function, the configuration that the paired RM adapter 150 should have is different. Later, the configuration when the KVS 160 has the transaction control function will be explained with reference to FIG. 2, and the configuration when the KVS 160 does not have the transaction control function will be explained with reference to FIG. 3.

[0016] Each RM adapter 150 can know in advance or in real time whether the corresponding KVS 160 has a transaction control function. In this embodiment, either optimistic locking or pessimistic locking may be adopted for the exclusive control. Moreover, the adoption of optimistic locking and pessimistic locking does not have to be common to the RM adapters 150 constituting the processing system 1. For example, only the first RM adapter 150-1 may adopt pessimistic locking, and the second RM adapter 150-2 and the third RM adapter 150-3 may adopt optimistic locking. Furthermore, when there is no distributed transaction being executed, in other words, when the GXID management table 204 of the RM adapter 150 is empty, the exclusive control in the RM adapter 150 can be switched between optimistic locking and pessimistic locking. However, each RM adapter 150 can know in advance or in real time whether to adopt optimistic locking or pessimistic locking. The difference in processing depending on the exclusive control method will be explained later with reference to a flowchart, etc.

[0017] The TM 100 manages transactions. The TM 100 includes a CPU 101 which is a central processing unit, a memory 103 which is a main storage device such as a DIMM, an external storage device 102 which is a non-volatile storage device such as a hard disk, a communication interface (hereinafter referred to as a "communication IF") 104 which realizes communication, and a TM program 105 which manages transactions. The CPU 101 realizes the TM program 105 by expanding a program stored in the external storage device 102 into the memory 103 and executing it.

[0018] The operation of the TM 100 described in this embodiment is realized by the TM program 105. The TM 100 sends XA commands to each RM adapter 150. The XA commands include four commands: xa_start, xa_prepare, xa_commit, and xa_rollback, and all four of these commands include a GXID, which is the ID of the distributed transaction, as an argument. These four XA commands are also called the start command, the prepare command, the commit command, and the rollback command, respectively.

[0019] The AP 110 executes an application. The AP 110 includes a CPU 111 which is a central processing unit, a memory 113 which is a main storage device such as a DIMM, an external storage device 112 which is a non-volatile storage device such as a hard disk, a communication IF 114 which realizes communication, and an AP program 115 which executes an application. The CPU 111 realizes the AP program 115 by expanding a program stored in the external storage device 112 into the memory 113 and executing it. The operation of the AP 110 described in this embodiment is realized by the AP program 115.

[0020] The DBMS 130 manages a database. The DBMS 130 includes a CPU 131 which is a central processing unit, a memory 133 which is a main storage device such as a DIMM, an external storage device 132 which is a non-volatile storage device such as a hard disk, a communication IF 134 which realizes communication, and a database system 135. The database system 135 includes an RM program 136 which manages resources. The CPU 131 realizes the RM program 136 by expanding the program stored in the external storage device 132 into the memory 103 and executing it.

[0021] RM adapter 150 includes CPU 151 which is a central processing unit, memory 152 which is a main storage device such as a DIMM, external storage device 153 which is a non-volatile storage device such as a hard disk, and a communication IF 153 which realizes communication. CPU 151 realizes functions described below by expanding a program stored in external storage device 132 into memory 152 and executing it.

[0022] The KVS 160 comprises a CPU 161 which is a central processing unit, a memory 162 which is a main storage device such as a DIMM, an external storage device 163 which is a non-volatile storage device such as a hard disk, and a communication IF 163 which realizes communication. The CPU 161 realizes the functions described below by expanding a program stored in the external storage device 163 into the memory 162 and executing it. Of the ACID properties that distributed transaction control must satisfy, the KVS 160 must at least satisfy "D", which is a property that the RM adapter 150 does not provide, that is, durability. Durability means that registered data will not disappear even if any kind of failure occurs.

[0023] Fig. 2 is a functional configuration diagram of the first RM adapter 150-1 and the first KVS 160-1 when the first KVS 160-1 has a transaction control function. However, Fig. 2 also shows data stored in the first RM adapter 150-1 and the first KVS 160-1. The first RM adapter 150-1 includes an AP reception program 201, a Tx end detection program 202, an RM adapter restart program 203, a GXID management table 204, a lock management table 205, a TM reception program 206, a KVS cleanup program 207, a KVS restart program 208, a query management table 209, a sequence number management file 211, and a persistent query management file 212. The first KVS 160-1 includes a commit management map 221 and a transaction control program 222 that realizes the transaction control function.

[0024] The processing of each program will be described in detail later, but the RM adapter restart program 203 is executed when the RM adapter 150 recovers from a down state, and the KVS restart program 208 is executed when the KVS 160 recovers from a down state. "Down" here means that a function has stopped without going through a prescribed procedure, which occurs, for example, due to an interruption in the power supply or a disconnection of the communication path. However, the RM adapter restart program 203 and the KVS restart program 208 may also be executed when a function has stopped after going through a prescribed procedure.

[0025] FIG. 3 is a functional configuration diagram of the first RM adapter 150-1 and the first KVS 160-1 when the first KVS 160-1 does not have a transaction control function. However, FIG. 3 also shows data stored in the first RM adapter 150-1 and the first KVS 160-1. The first RM adapter 150-1 further includes a temporary data management table 215 and a permanent Tx management file 216 in addition to the configuration shown in FIG. 2. The KVS resume program 208 is executed when the KVS 160 recovers from downtime. However, the first RM adapter 150-1 does not need to include the permanent query management file 212 shown in FIG. 2. The first KVS 160-1 does not include the transaction control program 222 shown in FIG. 2.

[0026] 4 is a diagram showing an example of the GXID management table 204. The GXID management table 204 is used to manage distributed transactions issued by the TM. The GXID management table 204 is composed of one or more records, and each record has fields of GXID 401, LXID 402, and LX status 403. In the GXID management table 204, the value of GXID 401 is a unique key. The ID of a distributed transaction issued by a transaction manager (hereinafter, GXID) is assigned to GXID 401.

[0027] The ID (LXID) of the transaction generated by the transaction control function of the data store is assigned to LXID 402. However, if KVS 160 does not have a transaction control function, then "- " is always assigned to LXID 402. Either "normal" or "recovered" is assigned to LX status 403. However, if KVS 160 does not have a transaction control function, then "normal" is always assigned to LX status 403.

[0028] FIG. 5 is a diagram showing an example of the query management table 209. The query management table 209 manages queries submitted by the AP 110. The query management table 209 is composed of one or more records, and each record has fields for a sequence number 601, a GXID 602, and a query 603. In the query management table 209, a combination of the value of the GXID 602 ​​and the value of the sequence number 601 is a unique key. A sequence number generated using the sequence number management file 211 is substituted for the sequence number 601. The GXID 602 ​​is the same as the GXID 401 in FIG. 4, and is substituted with the GXID issued by the transaction manager. A query that constitutes a distributed transaction process issued by an application program is substituted for the query column.

[0029] 6 is a diagram showing an example of the lock management table 205. The lock management table 205 manages the exclusion of data operated by the AP 110. The lock management table 205 is made up of one or more records, and each record has fields of a key 501, exclusion 502, PRS 503, CRS 504, and DRS 505. In the lock management table 205, the value of the key 501 is a unique key. The key of the data to be operated on in a query constituting a distributed transaction processing issued by an application program is assigned to the key 501.

[0030] In the exclusion 502, 0 to 1 GXID of the distributed transaction that has acquired the exclusion of this data is assigned. In the fields of PRS 503, CRS 504, and DRS 505, a data structure called a "Set collection" or "Set type" is assigned. When pessimistic locking is used for the exclusive control, the fields of PRS 503, CRS 504, and DRS 505 are not used and are fixed to "{}" indicating an empty set. This data structure is adopted to simplify the drawings and explanation, but data may be managed using multiple tables.

[0031] PRS 503 stores zero or more GXIDs of distributed transactions that have read unupdated (tainted) data and have not yet reached prepare. "PRS" stands for Pending-Read-Set, or an unresolved read set. CRS 504 stores zero or more GXIDs of distributed transactions that have read untainted data and are in an in-doubt state. A distributed transaction that has acquired exclusive access to this data cannot finish prepare until all distributed transactions contained in this set commit, that is, until it becomes an empty set. "CRS" stands for Clean-Read-Set, or a clean read set.

[0032] DRS 505 stores zero or more GXIDs of distributed transaction processes that have read dirty data. Distributed transactions stored in this set will always result in an error in prepare, and the distributed transaction will be aborted. "DRS" stands for Dirty-Read-Set.

[0033] 7 is a diagram showing an example of the temporary data management table 215. The temporary data management table 215 manages changes to data operated by the AP 110. The temporary data management table 215 is composed of one or more records, and each record has fields of a key 701, a GXID 702, an initial value 703, and an intermediate value 704. In the temporary data management table 215, a combination of the value of the GXID 702 and the value of the key 701 is a unique key. The key 701 and the GXID 702 are the same as the key 501 in FIG. 6 and the GXID 401 in FIG. 4.

[0034] The value corresponding to the key 701 at the start of the distributed transaction is stored in the initial value 703. If there is no value corresponding to the key in the data store, a special character string indicating that no value exists, such as "NIL" or "NULL", is stored in the initial value 703. The value of the initial value 703 is initially substituted for the intermediate value 704, and when the simulation of the query by the RM adapter 150 is completed, it is overwritten with the simulation result.

[0035] 8 is a diagram showing an example of the commit management map 221. The commit management map 221 manages committed distributed transactions. The commit management map 221 is made up of one or more records, and each record has fields for a KVS key 801 and a KVS value 802. In the commit management map 221, the value of the KVS key 801 is a unique key.

[0036] The KVS key 801 stores information that uniquely identifies the KVS or RM adapter 150, and data based on the committed GXID. In the first record of the example shown in FIG. 8, a character string is stored in which "KVS1" indicating the first KVS 601-1, "GID10" which is the GXID, and "$DTP" which is the collision avoidance keyword are connected with the delimiter colon. The order of the character strings, the delimiter, and the collision avoidance keyword may be changed. The KVS value 802 stores data based on the time when the distributed transaction processing is committed. In the example shown in FIG. 8, a combination of the character string "Committed:" and numbers indicating the year, month, day, hour, and minute is stored. "Committed:" may be another character string, and the granularity of the date and time may be changed appropriately according to the frequency of commits. Furthermore, other metadata may be incorporated into the KVS value 802.

[0037] 9 is a diagram showing an example of the sequence number management file 211. The sequence number management file 211 permanently manages the sequence numbers issued by the RM adapter 150. The sequence number management file 211 includes reserved sequence numbers 901 for issue and a batch issuance constant 902. The reserved sequence numbers 901 store sequence numbers that have been reserved for issue. The batch issuance constant 902 stores a predetermined constant. The batch issuance constant 902 is referenced when the RM adapter 150 recovers from a down state.

[0038] 10 is a diagram showing an example of a persistent query management file 212. The persistent query management file 212 persistently manages queries submitted by AP100. The persistent query management file 212 is generated for each GXID, and in this embodiment, the file name is the GXID itself. In other words, the persistent query management file 212 is a general term for files that are generated for each GXID and persistently manage queries submitted by AP100. Each persistent query management file 212 stores one or more combinations of sequence numbers and queries.

[0039] 11 is a diagram showing an example of the permanent Tx management file 216. The permanent Tx management file 216 permanently manages queries and initial data input by the AP100. The permanent Tx management file 216 is generated for each GXID, and in this embodiment, the file name is the GXID itself. In other words, the permanent Tx management file 216 is a general term for files that are generated for each GXID and permanently manage queries and initial data input by the AP100.

[0040] (flowchart) 12 is a flowchart showing the processing of the TM reception program 206. The TM reception program 206 is started when it receives any XA command from the TM 100. As described above, each XA command includes a GXID as an argument, so when the flowchart described below is executed, the XA command and the GXID given as an argument are specified. Below, the GXID given as an argument of the XA command from the TM 100 is called the "specified GXID."

[0041] The TM reception program 206 first judges the type of the received XA command in step S701. If the TM reception program 206 judges that the received XA command is "xa_start", the process proceeds to step S702. If the TM reception program 206 judges that the received XA command is "xa_prepare", the process proceeds to step S703. If the TM reception program 206 judges that the received XA command is "xa_rollback", the process proceeds to step S704. If the TM reception program 206 judges that the received XA command is "xa_commit", the process proceeds to step S705. In step S702, the TM reception program 206 starts a distributed Tx start process, which will be described in detail later with reference to FIG. 14, and ends the process shown in FIG. 12. In step S703, the TM reception program 206 starts a distributed Tx preparation process, which will be described in detail later with reference to FIG. 18, and ends the process shown in FIG. 12. In step S704, the TM reception program 206 starts a distributed Tx end process, which will be described in detail later with reference to FIG. 13, and ends the process shown in FIG. 12.

[0042] In step S705, the TM reception program 206 judges whether or not the KVS 160 connected to the RM adapter 150 executing the program has a transaction control function. If the TM reception program 206 judges that the connected KVS 160 has a transaction control function, the program proceeds to step S707, and if the TM reception program 206 judges that the connected KVS 160 does not have a transaction control function, the program proceeds to step S706. In step S706, the TM reception program 206 starts a distributed Tx determination second process, which will be described in detail later with reference to Fig. 21, and ends the process shown in Fig. 12. In step S707, the TM reception program 206 starts a distributed Tx determination first process, which will be described in detail later with reference to Fig. 20, and ends the process shown in Fig. 12.

[0043] Fig. 13 is a flowchart showing the distributed Tx cleanup process executed by the TM reception program 206. It can also be said that Fig. 13 shows the detailed process of step S704 in Fig. 12. First, in step S801, the TM reception program 206 starts exclusive control. In the following step S802, the TM reception program 206 deletes all records in the query management table 209 whose GXID602 values ​​match the specified GXID. In the following step S803, the TM reception program 206 executes lock management table cleanup process, which will be described in detail later with reference to Fig. 26, and proceeds to step S804. In step S804, the TM reception program 206 ends exclusive control.

[0044] In the following step S805, the TM reception program 206 judges whether or not the connected KVS 160 has a transaction control function. If the TM reception program 206 judges that the connected KVS 160 has a transaction control function, it proceeds to step S808, and if it judges that the connected KVS 160 does not have a transaction control function, it proceeds to step S806. In step 806, the TM reception program 206 deletes the permanent Tx management file 216 with the same file name as the specified GXID. In the following step S807, the TM reception program 206 deletes all records in the temporary data management table 215 whose GXID 702 value matches the specified GXID, and proceeds to step S812.

[0045] In step S808, the TM reception program 206 deletes the persistent query management file 212 with the same file name as the specified GXID. In the following step S809, the TM reception program 206 acquires record A in the GXID management table 204, whose GXID401 value matches the specified GXID. In the following step S810, the TM reception program 206 determines whether record A exists. In other words, in this step, it is determined whether a record exists in the GXID management table 204 having a GXID401 value that matches the specified GXID. If the TM reception program 206 determines that record A exists, it proceeds to step S811, and if it determines that record A does not exist, it proceeds to step S812.

[0046] In step S811, the TM reception program 206 rolls back the transaction corresponding to the value of LXID402 of the acquired record A, and proceeds to step S812. In step S812, the TM reception program 206 deletes a record in the GXID management table 204 whose GXID401 value matches the specified GXID, and ends the processing shown in FIG.

[0047] Fig. 14 is a flowchart showing the distributed Tx start processing executed by the TM reception program 206. Fig. 13 can also be said to show detailed processing of step S702 in Fig. 12. First, in step S901, the TM reception program 206 executes distributed Tx termination processing. In the following step S902, the TM reception program 206 judges whether or not the connected KVS 160 has a transaction control function. If the TM reception program 206 judges that the connected KVS 160 has a transaction control function, it proceeds to step S903, and if it judges that the connected KVS 160 does not have a transaction control function, it proceeds to step S906.

[0048] In step S903, the TM reception program 206 starts a new transaction with the connected KVS 160. In the following step S904, the TM reception program 206 acquires the LXID of the started transaction. In the following step S905, the TM reception program 206 adds a new record to the GXID management table 204 using the specified GXID and the LXID acquired from the KVS 160, and ends the processing shown in FIG. 14. However, the LX status 403 of this record is "normal". In step S906, the TM reception program 206 adds a new record to the GXID management table 204 using the specified GXID, and ends the processing shown in FIG. 14. However, the LXID 402 of this record is "-", and the LX status 403 is "normal".

[0049] 15 to 17 are flowcharts showing the processing of the AP reception program 201. First, in step S1001, the AP reception program 201 acquires record A in the GXID management table 204, whose GXID 401 value matches the specified GXID. In the following step S1002, the AP reception program 201 determines whether the acquired record A exists. If the AP reception program 201 determines that record A exists, it proceeds to step S1003, and if it determines that record A does not exist, it ends the processing of FIG. 15 with an error.

[0050] In step S1003, the AP reception program 201 extracts a key from the received query. In the following step S1004, the AP reception program 201 determines whether or not the key extracted in step S1003 falls within the key range of the connected KVS 160. If the AP reception program 201 determines that the key falls within the key range, it proceeds to step S1005, and if it determines that the key does not fall within the key range, it ends the processing in Fig. 15 with an error.

[0051] In step S1005, the AP reception program 201 begins exclusive control. In the following step S1006, the AP reception program 201 performs a lock management table update process, which will be described in detail in Fig. 27. In the following step S1007, the AP reception program 201 generates a sequence number. In the following step S1008, the AP reception program 201 adds a new record to the query management table 209 using the sequence number generated in step S1007 and the received query and GXID.

[0052] In the following step S1009, the AP reception program 201 ends the exclusive control. In the following step S1010, the AP reception program 201 judges whether or not the connected KVS 160 has a transaction control function. If the TM reception program 206 judges that the connected KVS 160 has a transaction control function, it proceeds to step S1101 in Fig. 16 via circled A, and if it judges that the connected KVS 160 does not have a transaction control function, it proceeds to step S1201 in Fig. 17 via circled B.

[0053] In step S1101 of Fig. 16, the AP reception program 201 judges whether the value of the LX status 403 in the record A acquired in step S1001 of Fig. 15 is "normal". If the AP reception program 201 judges that the value of the LX status 403 is "normal", the program proceeds to step S1102, and if the AP reception program 201 judges that the value of the LX status 403 is not "normal", the program proceeds to step S1104. In step S1102, the AP reception program 201 resumes the transaction corresponding to the value of the LXID 402 in the acquired record A. In the following step S1103, the AP reception program 201 causes the resumed transaction to execute the received query and returns the result to the AP 110. In step S1104, the AP reception program 201 waits for a certain period of time and returns to step S1101.

[0054] 17, the AP reception program 201 retrieves a record in the temporary data management table 215 where the value of GXID 702 matches the specified GXID and the value of key 701 matches the extracted key. In the following step S1202, the AP reception program 201 determines whether or not record B retrieved in step S1201 exists. If the AP reception program 201 determines that the retrieved record exists, it proceeds to step S1205, and if it determines that the retrieved record does not exist, it proceeds to step S1203.

[0055] In step S1203, the AP reception program 201 acquires a value corresponding to the key extracted in step S1003 from the KVS 160. In the following step S1204, the AP reception program 201 generates record B in the temporary data management table 215 using the key extracted in step S1003, the value acquired in step S1203, and the specified GXID, and proceeds to step S1205. However, the value acquired in step S1203 is used as a value common to the initial value 703 and the intermediate value 704.

[0056] In the next step S1205, the AP reception program 201 simulates the execution of the query using the intermediate value 704 of record B acquired or created and the received query. In the next step S1206, the AP reception program 201 substitutes the result of the simulation in step S1205 for the intermediate value 704 of record B in the temporary data management table 215, and returns the query execution result (the intermediate value 704 if it is a reference query, or update success or failure if it is an update query) to the AP 110, and ends the processing shown in FIG.

[0057] Fig. 18 is a flowchart showing the distributed Tx preparation process executed by the TM reception program 206. Fig. 18 can also be said to show detailed processing of step S703 in Fig. 12. First, in step S1301, the TM reception program 206 acquires record A in which the value of GXID401 in the GXID management table 204 matches the specified GXID. In the following step S1302, the TM reception program 206 judges whether or not the record A acquired in step S1301 exists. If the TM reception program 206 judges that the acquired record exists, it proceeds to step S1303, and if it judges that the acquired record does not exist, it ends the processing of Fig. 18 with an error.

[0058] In step S1303, the TM reception program 206 determines whether or not pessimistic locking is used for exclusive control, and if it determines that pessimistic locking is used, proceeds to step S1307 in Fig. 19 via circled C. If the TM reception program 206 determines that pessimistic locking is not used for exclusive control, that is, that optimistic locking is used, proceeds to step S1304. In step S1304, the TM reception program 206 executes a lock management table verification process, the details of which are shown in Fig. 30. In the following step S1305, the TM reception program 206 determines whether the process in the previous step was successful or not.

[0059] As described later, the lock management table verification process can end with an error or end normally, and end normally means that the lock management table verification process is successful. If the TM reception program 206 determines that the lock management table verification process is successful, it proceeds to step S1307 in Fig. 19 via circled C, and if it determines that the lock management table verification process is unsuccessful, it proceeds to step S1306. In step S1306, the TM reception program 206 executes the distributed Tx cleanup process shown in detail in Fig. 13, and ends the process in Fig. 18 with an error.

[0060] The explanation will continue by moving to Fig. 19. In step S1307 in Fig. 19, which transitions via circled C, the TM reception program 206 acquires all records B in the query management table 209 where the value of GXID 602 ​​matches the specified GXID. In the following step S1308, the TM reception program 206 judges whether or not the KVS 160 connected to the RM adapter 150 that is executing this program has a transaction control function. If the TM reception program 206 judges that the connected KVS 160 has a transaction control function, it proceeds to step S1311, and if it judges that the connected KVS 160 does not have a transaction control function, it proceeds to step S1309.

[0061] In step S1309, the TM reception program 206 acquires all records C in the temporary data management table 215 whose GXID 702 values ​​match the specified GXID. In the following step S1310, the TM reception program 206 creates a permanent Tx management file 216 using the specified GXID, the acquired record B, and the acquired record C, and ends the processing shown in Fig. 19. In step S1311, the TM reception program 206 creates a permanent query management file 212 using the specified GXID and the acquired record B, and ends the processing shown in Fig. 19.

[0062] Fig. 20 is a flowchart showing the first distributed Tx determination process executed by the TM reception program 206. Fig. 20 can also be said to show detailed processing of step S707 in Fig. 12. First, in step S1401, the TM reception program 206 acquires record A in which the value of GXID401 in the GXID management table 204 matches the specified GXID. In the following step S1402, the TM reception program 206 judges whether the value of LX status 403 of the acquired record A is "normal". If the TM reception program 206 judges that the value of LX status 403 is "normal", the program proceeds to step S1403, and if the TM reception program 206 judges that the value of LX status 403 is not "normal", the program proceeds to step S1407.

[0063] In step S1407, the TM reception program 206 waits for a fixed period of time and returns to step S1402. In step S1403, the TM reception program 206 resumes the transaction corresponding to the value of LXID 402 of the acquired record A. In the following step S1404, the TM reception program 206 generates query A that adds the specified GXID to the commit management map 221 of the KVS 160, and has the resumed transaction execute it. In the following step S1405, the TM reception program 206 commits the resumed transaction. In the following step S1406, the TM reception program 206 generates query B that acquires the specified GXID from the commit management map 221 of the KVS 160, and has the KVS 160 execute the query.

[0064] In the next step S1408, the TM reception program 206 determines whether or not a value has been acquired from the result of query B executed in step S1406. If the TM reception program 206 determines that a value has been acquired, it ends the processing of FIG. 20, and if it determines that a value has not been acquired, it proceeds to step S1409. In step S1409, the TM reception program 206 waits until the value of LXID402 of the acquired record A becomes different from the LXID of the resumed transaction, and returns to step S1402. That is, the TM reception program 206 remains in step S1409 as long as the value of LXID402 of the acquired record A is the same as the LXID of the resumed transaction.

[0065] Fig. 21 is a flowchart showing the second distributed Tx determination process executed by the TM reception program 206. Fig. 21 can also be said to show detailed processing of step S706 in Fig. 12. First, in step S1501, the TM reception program 206 creates an empty query list A. In the following step S1502, the TM reception program 206 acquires all records B in the temporary data management table 215 whose GXID702 values ​​match the specified GXID.

[0066] In the following step S1503, the TM reception program 206 creates a query that registers the values ​​of the keys 701 and initial values ​​703 of all acquired records B in the KVS 160, and adds it to the query list A. In the following step S1504, the TM reception program 206 acquires all records C in the query management table 209 whose GXID 602 ​​values ​​match the specified GXID. In the following step S1505, the TM reception program 206 sorts the values ​​of the queries 603 of all acquired records C in ascending order of the sequence numbers 601, and adds them to the end of the query list A.

[0067] In the following step S1506, the TM reception program 206 generates a query D that adds the specified GXID to the commit management map 221 of the KVS 160, and adds it to the end of the query list A. In the following step S1507, the TM reception program 206 causes the connected KVSs 160 to execute the query list A in order from the top. In the following step S1508, the TM reception program 206 generates a query E that obtains the specified GXID from the commit management map 221 of the KVS 160, and causes the KVS 160 to execute that query.

[0068] In the next step S1509, the TM reception program 206 judges whether or not the value has been acquired based on the result of the query executed in step S1508. If the TM reception program 206 judges that the value has been acquired, the program proceeds to step S1510, and if the TM reception program 206 judges that the value has not been acquired, the program returns to step S1501. In step S1510, the TM reception program 206 executes a distributed Tx termination process, and ends the process shown in FIG.

[0069] 22 is a flowchart showing the processing of the Tx end detection program 202. The Tx end detection program 202 is started when the RM adapter 150 is started, and is forcibly terminated when the RM adapter 150 is shut down. In other words, the Tx end detection program 202 is a program that is always executed. First, in step S1601, the Tx end detection program 202 detects a completed transaction and obtains the LXID of that transaction. In the following step S1602, the Tx end detection program 202 obtains record A in the GXID management table 204, whose LXID 402 value matches the LXID obtained in step S1601.

[0070] In the following step S1603, the Tx end detection program 202 judges whether the record A acquired in step S1602 exists. If the Tx end detection program 202 judges that the record A exists, the program proceeds to step S1604, and if the program judges that the record A does not exist, the program returns to step S1601. In step S1604, the Tx end detection program 202 acquires the value of GXID401 of the acquired record A.

[0071] In the following step S1605, the Tx end detection program 202 generates a query to obtain the GXID obtained in step S1604 from the commit management map 221 of the KVS 160, and causes the KVS 160 to execute the query. In the following step S1606, the Tx end detection program 202 determines whether or not a value was obtained from the result of the query executed in the previous step. If the Tx end detection program 202 determines that a value was obtained, it proceeds to step S1607, and if it determines that a value was not obtained, it proceeds to step S1608.

[0072] In step S1607, the Tx end detection program 202 executes distributed Tx cleanup processing and returns to step S1601. In step S1608, the Tx end detection program 202 assigns "recovery" to the LX status 403 of record A acquired in step S1602. In the following step S1609, the Tx end detection program 202 starts a new transaction and acquires its LXID. In the following step S1610, the Tx end detection program 202 assigns the LXID acquired in step S1609 to the LXID 402 of record A acquired in step S1602.

[0073] In the next step S1611, the Tx end detection program 202 acquires all records C in the query management table 209 whose GXID 602 ​​values ​​match the GXID acquired in step S1604. In the next step S1602, the Tx end detection program 202 sorts the acquired records C in ascending order by the values ​​of the sequence number column, and executes the values ​​of each query 603 in the transaction that started it. In the next step S1613, the Tx end detection program 202 assigns "normal" to the value of the LX status 403 of the record A acquired in step S1602, and returns to step S1601.

[0074] 23 is a flowchart showing the processing of the KVS cleaning program 207. The KVS cleaning program 207 is executed when the RM adapter 150 is started up, and is forcibly terminated when the RM adapter 150 is shut down. In other words, the KVS cleaning program 207 is always running. First, in step S1701, the KVS cleaning program 207 acquires the commit management map 221 from the connected KVS 160.

[0075] In the following step S1702, the KVS cleaning program 207 references the KVS value 802 of the acquired commit management map 221, extracts the committed time of each record, generates a query to delete records with sufficiently old committed times, and has the KVS 160 execute it. Records with sufficiently old committed times are deleted because they are not necessary for recovery. A sufficiently old committed time means, for example, that it is more than one hour before the current time. In the following step S1703, the KVS cleaning program 207 waits for a fixed period of time and then returns to step S1701.

[0076] 24 is a flowchart showing the processing of the KVS resume program 208. When any of the KVS 160 recovers from a down state, the KVS resume program 208 is executed by the corresponding RM adaptor 150. For example, when the first KVS 160-1 recovers from a down state, the first RM adaptor 150-1 executes the KVS resume program 208.

[0077] First, in step S1801, the KVS resume program 208 assigns "recovery" to the LX status 403 of all records in the GXID management table 204. In the following step S1802, the KVS resume program 208 executes a new transaction for each record in the GXID management table 204, and assigns the LXID to the LXID 402. In the example shown in Fig. 34, two records were stored in the GXID management table 204, so a total of two transactions are started in S504 and S506.

[0078] In the following step S1803, the KVS resume program 208 acquires record A with the smallest value in the sequence number column from the query management table 209, and proceeds to step S1804. In step S1804, the KVS resume program 208 determines whether the acquired record A exists. If the KVS resume program 208 determines that record A exists, it proceeds to step S1805, and if it determines that record A does not exist, it proceeds to step S1808.

[0079] In step S1805, the KVS resume program 208 identifies a record from the GXID management table 204 whose GXID 401 matches the value of GXID 602 ​​of the record A acquired, and resumes the transaction corresponding to the value of LXID 402 of the identified record. In the following step S1806, the KVS resume program 208 causes the resumed transaction to execute the value of the query 603 of the acquired record A. In the following step S1807, the KVS resume program 208 acquires from the query management table 209 record A whose value of the sequence number column is greater than the value of the sequence number 601 of the acquired record A and is the smallest, and returns to step S1804. In step S1808, which is executed when a negative judgment is made in step S1804, the KVS resume program 208 assigns "normal" to the LX status 403 of all records in the GXID management table 204, and ends the processing shown in FIG. 24.

[0080] 25 is a flowchart showing the processing of the RM adapter restart program 203. The RM adapter restart program 203 is started when the RM adapter 150 recovers from a down state. For example, when the first RM adapter 150-1 recovers from a down state, the RM adapter restart program 203 is started in the first RM adapter 150-1.

[0081] First, in step S1901, the RM adapter resume program 203 acquires a list A of all records in the commit management map 221 from the connected KVS 160. In the following step S1902, the RM adapter resume program 203 determines whether or not the KVS 160 connected to the RM adapter 150 that is executing this program has a transaction control function. If the RM adapter resume program 203 determines that the connected KVS 160 has a transaction control function, it proceeds to step S1903, and if it determines that the connected KVS 160 does not have a transaction control function, it proceeds to step S1910.

[0082] In step S1903, the RM adapter resume program 203 extracts the GXID from the KVS key 801 of all the acquired records A, and deletes the persistent query management files 212 having file names that match the GXID. In the following step S1904, the RM adapter resume program 203 reads all the persistent query management files 212 that were not deleted in step S1903, and generates the GXID management table 204 and the query management table 209. However, in the GXID management table 204 generated at this time, the LXID 402 is "-" and the LX status 403 is "recovered".

[0083] In the following step S1906, the RM adapter resume program 203 executes lock management table regeneration processing. In the following step S1907, the RM adapter resume program 203 ends exclusive control. In the following step S1908, the RM adapter resume program 203 rolls back all transactions held by the KVS 160. In the following step S1909, the RM adapter resume program 203 starts execution of the KVS resume program 208, and ends the processing shown in FIG.

[0084] If a negative decision is made in step S1902, the RM adapter resume program 203 extracts the GXID from the KVS key 801 of all acquired record A in step S1910, and deletes the permanent Tx management file 216 having the file name that matches the GXID. In the following step S1911, the RM adapter resume program 203 starts exclusive control.

[0085] In the next step S1912, the RM adapter resume program 203 reads all permanent Tx management files 216 that were not deleted in step S1910, and generates the GXID management table 204, the query management table 209, and the temporary data management table 215. However, in the GXID management table 204 generated at this time, the LXID 402 is "-" and the LX status 403 is "normal". Also, the intermediate value 704 of the temporary data management table 215 generated at this time is "-".

[0086] In the next step S1913, the RM adapter restart program 203 performs a lock management table regeneration process. In the next step S1914, the RM adapter restart program 203 ends the exclusive control and ends the process shown in FIG.

[0087] Fig. 26 is a flowchart showing the lock management table cleanup process. Fig. 26 can also be said to show detailed processing of step S803 in Fig. 13. The subject of execution of this process is the TM reception program 206, as in Fig. 13. First, in step S2001, the TM reception program 206 determines whether or not pessimistic locking is used for exclusive control, and if it is determined that pessimistic locking is used, the process proceeds to step S2002. If the TM reception program 206 determines that pessimistic locking is not used for exclusive control, that is, that optimistic locking is used, the process proceeds to step S2005.

[0088] In step S2002, the TM reception program 206 searches for and deletes the same value as the specified GXID from the exclusion 502 of all records in the lock management table 205. In the following step S2003, the TM reception program 206 identifies all records in the lock management table 205 whose values ​​for the exclusion 502 are blank, and deletes the identified records from the lock management table 205. In the following step S2004, the TM reception program 206 notifies the release of the exclusion, and ends the processing shown in FIG.

[0089] In step S2005, the TM reception program 206 searches for and deletes the same value as the specified GXID in the exclusion 502, PRS 503, CRS 504, and DRS 505 of all records in the lock management table 205. In the next step S2006, the TM reception program 206 identifies all records in the lock management table 205 in which the value of exclusion 502 is null and the values ​​of PRS 503, CRS 504, and DRS 505 are null sets, and deletes the identified records from the lock management table 205. In the next step S2007, the TM reception program 206 notifies the release of the exclusion and ends the processing shown in Fig. 26.

[0090] In this flowchart, the process in step S2001 differs depending on whether the mode is the pessimistic lock mode or not, but the process in steps S2005 to S2007 may always be performed without making the decision in step S2001. This is because the process in steps S2002 to S2004 is included in the process in steps S2005 to S2007.

[0091] FIG. 27 is a flowchart showing the lock management table update process. FIG. 27 can be said to show detailed processing of step S1006 in FIG. 15 and step S2505 in FIG. 31. The subjects of execution of the process shown in FIG. 27 are the AP reception program 201 as in FIG. 15 and the RM adapter resume program 203 as in FIG. 31, but from this point on, reference to the RM adapter resume program 203 will be omitted. In step S2101, the TM reception program 206 extracts a key from the received query. In the following step S2102, the TM reception program 206 judges whether or not pessimistic locking is adopted for exclusive control, and if it is judged that pessimistic locking is adopted, the process proceeds to step S2103. If the TM reception program 206 judges that pessimistic locking is not adopted for exclusive control, that is, that optimistic locking is adopted, the process proceeds to step S2201 in FIG. 28 via circled D.

[0092] In step S2103, the TM reception program 206 retrieves record C in the lock management table 205, whose value of the key 501 matches the key extracted in step S2101. In the following step S2104, the TM reception program 206 judges whether the retrieved record C exists. If the TM reception program 206 judges that the retrieved record C exists, the program proceeds to step S2105, waits until the exclusive release, and returns to step S2103. In step S2106, the TM reception program 206 adds a record to the lock management table 205, using the key extracted in step S2101 and the specified GXID. However, in this record, the specified GXID is used for the exclusive 502.

[0093] 28 for further explanation. In step S2201, the TM reception program 206 retrieves from the lock management table 205 record C whose value of key 501 matches the key extracted in step S2101. In the following step S2202, the TM reception program 206 determines whether or not the record C retrieved in step S2201 exists. If the TM reception program 206 determines that record C exists, it proceeds to step S2206, and if it determines that record C does not exist, it proceeds to step S2203.

[0094] In step S2203, the TM reception program 206 judges whether the received query is an update-related query. If the TM reception program 206 judges that the received query is an update-related query, the process proceeds to step S2205. If the TM reception program 206 judges that the received query is not an update-related query, the process proceeds to step S2204. In step S2204, the TM reception program 206 adds a new record to the lock management table 205 using the key extracted in step S2101 and the specified GXID, and ends the process shown in FIG. 28. However, in this case, the specified GXID is stored in the PRS 503. In step S2205, the TM reception program 206 adds a new record to the lock management table 205 using the key extracted in step S2101 and the specified GXID, and ends the process shown in FIG. 28. However, in this case, the specified GXID is stored in the exclusive 502.

[0095] In step S2206, the TM reception program 206 determines whether or not the specified GXID is included in the DRS 505 of the acquired record C. If the TM reception program 206 determines that the specified GXID is included in the DRS 505 of record C, it ends the processing in Fig. 28, and if it determines that the specified GXID is not included in the DRS 505 of record C, it proceeds to step S2301 in Fig. 29 via circled E.

[0096] The explanation continues with Fig. 29. In step S2301, the TM reception program 206 judges whether or not the value of the exclusive 502 of the acquired record C is null. If the TM reception program 206 judges that the value of the exclusive 502 of the acquired record C is null, the program proceeds to step S2302, and if the TM reception program 206 judges that the value of the exclusive 502 of the acquired record C is not null, that is, that some value is stored, the program proceeds to step S2306. In step S2302, the TM reception program 206 judges whether or not the received query is an update-related query. If the TM reception program 206 judges that the received query is an update-related query, the program proceeds to step S2304, and if the TM reception program 206 judges that the received query is not an update-related query, the program proceeds to step S2303.

[0097] In step S2303, the TM reception program 206 adds the specified GXID to the PRS 503 field of the acquired record C, and ends the processing shown in Fig. 29. In step S2304, the TM reception program 206 assigns the specified GXID to the exclusion 502 field of the acquired record C. In the following step S2305, the TM reception program 206 deletes the specified GXID from the PRS 503 field of the acquired record C, moves the value of PRS 503 after deletion to the DRS 505 field, and ends the processing shown in Fig. 29.

[0098] In step S2306, the TM reception program 206 judges whether the value of the exclusive 502 of the acquired record C matches the specified GXID. If the TM reception program 206 judges that the two match, it ends the process shown in Fig. 29, and if it judges that the two do not match, it proceeds to step S2307. In step S2307, the TM reception program 206 adds the specified GXID to the DRS 505 column of the acquired record C, and ends the process shown in Fig. 29.

[0099] FIG. 30 is a flowchart showing the lock management table verification process executed by the TM reception program 206. FIG. 30 can also be said to show detailed processing of step S1304 in FIG. 18. First, the TM reception program 206 starts exclusive control in step S2401. In the following step S2402, the TM reception program 206 acquires all records D containing the specified GXID in the DRS505 column in the lock management table 205. In the following step S2403, the TM reception program 206 judges whether the number of acquired records D is one or more. If the TM reception program 206 judges that the number of acquired records D is one or more, it proceeds to step S2404, and if the TM reception program 206 judges that the number of acquired records D is zero, it proceeds to step S2405. In step S2404, the TM reception program 206 ends exclusive control and ends the process shown in FIG. 30 with an error.

[0100] In step S2405, the TM reception program 206 acquires all records E that include the specified GXID in the PRS 503 column in the lock management table 205. In the following step S2406, the TM reception program 206 moves the specified GXID from PRS 503 to CRS 504 for the acquired records E, and proceeds to step S2407. In step S2407, the TM reception program 206 acquires all records F in the lock management table 205 in which the value of exclusion 502 is the specified GXID and the value of CRS 504 is not an empty set.

[0101] In the following step S2408, the TM reception program 206 determines whether the number of acquired records F is one or more. If the TM reception program 206 determines that the number of acquired records F is one or more, the program proceeds to step S2410, and if the TM reception program 206 determines that the number of acquired records F is zero, the program proceeds to step S2409. In step S2409, the TM reception program 206 ends the exclusive control and ends the process shown in Fig. 30, in other words, ends normally. In step S2410, the TM reception program 206 waits until the exclusive control is released, and returns to step S2407.

[0102] Fig. 31 is a flowchart showing the lock management table regeneration process. It can also be said that Fig. 31 shows detailed processing of S1906 and the like in Fig. 25. The lock management table regeneration process is executed mainly by the RM adapter resume program 203. First, in step S2501, the RM adapter resume program 203 acquires record A having the smallest value of sequence number 601 in the query management table 209. In the following step S2502, the RM adapter resume program 203 judges whether or not the acquired record A exists. If the RM adapter resume program 203 judges that record A exists, it proceeds to step S2503, and if it judges that record A does not exist, it ends the processing shown in Fig. 31.

[0103] In step S2503, the RM adapter resume program 203 acquires the values ​​of GXID 602 ​​and query 603 of the acquired record A. In the following step S2505, the RM adapter resume program 203 performs a lock management table update process. In the lock management table update process, the GXID acquired in step S2503 is treated as the designated GXID, and the query acquired in step S2503 is treated as the received query. In the following step S2506, the RM adapter resume program 203 judges whether or not pessimistic locking is adopted for exclusive control, and proceeds to step S2509 if it is judged that pessimistic locking is adopted. If the RM adapter resume program 203 judges that pessimistic locking is not adopted for exclusive control, that is, that optimistic locking is adopted, it proceeds to step S2507. In step S2507, the RM adapter resume program 203 acquires all records B whose PRS 503 values ​​in the lock management table 205 include the GXID acquired in step S2503.

[0104] In the next step S2508, the RM adapter resume program 203 moves the GXID acquired in step S2503 for all acquired records B from the PRS 503 to the CRS 504, and proceeds to step S2509. In step S2509, the RM adapter resume program 203 acquires as a new record A a record in the query management table 209 whose sequence number 601 value is greater than the sequence number 601 value of the acquired record A and is the smallest, and returns to step S2502.

[0105] (Timing chart) As explained above, the processing system 1 can use either pessimistic or optimistic locking for exclusive control of distributed transaction processing, and the KVS 160 may or may not have a transaction control function. In other words, a total of four combinations are possible: two with exclusive control and two with or without transaction control. In the following, these four combinations are referred to as patterns 1 to 4.

[0106] Specifically, pattern 1 is a combination of pessimistic locking and transaction control, pattern 2 is a combination of optimistic locking and transaction control, pattern 3 is a combination of pessimistic locking and no transaction control, and pattern 4 is a combination of optimistic locking and no transaction control. Of these four patterns, the timing charts for pattern 1 are explained below using Figures 32 to 35. In each timing chart, time passes from the top to the bottom.

[0107] 32 to 35 are specifically as follows. FIG. 32 shows the processing when the RM adapter 150 receives xa_start and a query in pattern 1. FIG. 33 shows the processing when the RM adapter 150 receives xa_prepare in pattern 1. FIG. 34 shows the processing when the KVS 160 recovers from a down state in pattern 1. FIG. 35 shows the processing when the RM adapter 150 recovers from a down state in pattern 1. Note that the timing charts are explained below, along with the corresponding step numbers in the flowchart. After that, the differences between pattern 2 and pattern 1 are explained. Patterns 3 and 4 differ in the selection of the option for the presence or absence of a transaction control function in the processing of patterns 1 and 2, as in step S705 of FIG. 12.

[0108] <1-0. Initial state of pattern 1> When the KVS 160 has a transaction control function, the configuration of the RM adapter 150 is as shown in Fig. 2. In the initial state of the RM adapter 150, the GXID management table 204, the query management table 209, and the lock management table 205 are empty, and there is no persistent query management file 212. And the value of the "sequence number reserved for issue" in the sequence number management file 211 is "0".

[0109] <1-1. When xa_start is accepted in pattern 1> When the first AP 110-1 starts a distributed transaction, it calls tx_begin, which is one of the TX interfaces, for the TM 100 (S301). Upon receiving tx_begin, the TM 100 first generates a GXID and calls xa_start, which is one of the XA interfaces, for all the KVS 160 or RM adapter 150, with the generated GXID, i.e., the specified GXID, as an argument (S302). The GXID generated at this time is "G1", and "xa_start(G1)" with the argument "G1" is called, as shown in Fig. 32.

[0110] The RM adapter 150 that has received xa_start runs the TM reception program 206. Because the received XA interface is xa_start, the TM reception program 206 advances from S701 to S702 in FIG. 12 and starts the distributed Tx start process. The distributed Tx start process (FIG. 14) performs the following four processes. First, it calls the distributed Tx clearing process for the specified GXID and deletes the remaining data related to the specified GXID from memory and storage (S901). Second, it sends "BEGIN TRANSACTION" to have the first KVS 160-1 start a new transaction (S303, S903). Third, it acquires the ID of the transaction started by the first KVS 160-1, that is, the LXID (S304, S904).

[0111] In this case, the acquired LXID was "L1". Fourthly, a new record is recorded in the GXID management table 204 using the GXID determined by TM 100 and the LXID acquired from the first KVS 160-1 (S905). The first RM adapter 150-1 assigns "normal" to the value of the LX status 403 in this record. After recording the new record in the GXID management table 204, the first RM adapter 150-1 transmits a Success indicating normal completion to TM 100 (S305). Having received the Success from the first RM adapter 150-1, TM 100 also transmits a Success indicating normal completion to the first AP 110-1 (S306). However, the communication in S306 includes data indicating the generated GXID, "G1".

[0112] When the second AP 110-2 calls tx_begin for the TM 100 in the same manner as the first AP 110-1, processing similar to that of S301 to S306 is performed as S307 to S312. However, in this case, the GXID generated by the TM 100 is "G2", and the LXID sent by the first KVS 160-1 was "L2". The GXID management table 204 of the first RM adapter 150-1 immediately before S311 is executed is as shown in the middle right part of FIG.

[0113] <1-2. When a query is received using pattern 1> After finishing calling tx_begin, the first AP 110-1 passes the GXID and a query constituting the distributed transaction processing to the first RM adapter 150-1 (S313). Here, the first AP 110-1 passes the GXID "G1" and the query "get(key A)". Having accepted the query, the first RM adapter 150-1 operates the AP reception program 201 and performs the following seven processes. The AP reception program 201 performs the processes shown in Figs. 15 to 17.

[0114] In the first process, to confirm that the distributed transaction has already received tx_begin, a record corresponding to the specified GXID is obtained from the GXID management table 204 (S1001). If there is no record, an error is returned to the AP. In the second process, the key of the data to be operated on is extracted from the received query (S1003). In the third process, to confirm that the KVS-side transaction can receive the query, it is confirmed whether the hash value of the extracted key is included in the range of the KVS managed by this RM adapter 150 (S1004). If it is not included in the range, an error is returned to the AP 110.

[0115] In the fourth process, exclusive control is performed to prevent simultaneous execution, and the following processes 4A to 4C are then performed. (4A) A lock management table update process is called (the process of FIG. 27 is started in S1006), and the extracted key is locked (S2106). If another distributed transaction has already been locked (S2104: YES), the process waits until the distributed transaction ends (S2105). (4B) A new sequence number is generated using the sequence number management file 211 (S1007). Note that, as with a general database, the "sequence number reserved for issue" is not necessarily persisted to the disk every time to prevent performance degradation. A "batch issue constant" that is an integer equal to or greater than 1 is determined, and the sequence number is persisted when the number of times the sequence number is issued exceeds the batch issue constant. If the RM adapter 150 goes down during the process, the issuance of sequence numbers is resumed from the persisted "sequence number reserved for issue" + "batch issue constant" to prevent duplication with sequence numbers issued before the downtime.

[0116] (4C) A record is added to the query management table 209 using the specified GXID, the received query, and the generated sequence number (YES in S1008 and S1010). In the fifth process, it is confirmed that the value of LX status 402 of the record acquired in the first process is "normal" (S1101). If it is "recovered", the process repeats waiting for a certain period of time until it changes to "normal" (S1104). In the sixth process, the KVS-side transaction corresponding to the value of LXID 402 of the record acquired in the first process is resumed (S1102). In the seventh process, the received query is executed for the resumed KVS-side transaction, and the execution result is returned to AP 110 (S1103).

[0117] <1-3. When xa_prepare is accepted in pattern 1> When the first AP 110-1 ends a distributed transaction, it calls tx_commit, which is one of the TX interfaces, to the TM 100 (S401). The TM 100, which has accepted tx_commit, calls xa_prepare, which is one of the XA interfaces, to all RM adapters 150 as the first phase, attaching the GXID "G1" as an argument (S402). The first RM adapter 150-1, which has accepted xa_prepare, runs the TM reception program 206. Since the accepted XA interface is xa_prepare, the TM reception program 206 starts distributed Tx preparation processing (S703 in FIG. 12, FIG. 18).

[0118] The distributed Tx preparation process mainly involves the following two steps. First, to confirm that the distributed transaction is one for which tx_begin has been accepted, a record corresponding to the specified GXID is obtained from the GXID management table 204 (S1301, positive determinations in S1302 and S1303 lead to FIG. 19). If the corresponding record is not stored in the GXID management table 204, the TM acceptance program 206 returns an error to the AP ( S 1302:NO, error termination).

[0119] Secondly, in the distributed Tx preparation process, a list of records corresponding to the specified GXID is obtained from the query management table 209 (S1307), and the contents are recorded in storage as the persistent query management file 212 (S1311). Then, the first RM adapter 150-1 transmits a Success indicating the success of the process to the TM 100 (S403). In the example shown in Fig. 33, as shown in the upper right corner, the persistent query management file 212 is generated with a file name of the GXID "G1", and two records with GXID "G1" that were recorded in the query management table 209 are recorded.

[0120] <1-4. When xa_commit is accepted in pattern 1> After calling xa_prepare for all RM adapters 150, the TM 100 calls xa_commit, one of the XA interfaces, for all RM adapters 150 in the second phase, attaching GXID as an argument (S404). The first RM adapter 150-1 that received xa_commit runs the TM reception program 206. Since the received XA interface is xa_commit, the TM reception program 206 starts the first distributed Tx determination process (S705 in FIG. 12: Yes, S707, FIG. 20). The first distributed Tx determination process performs the following six processes, namely the first process to the sixth process.

[0121] In the first process, the TM reception program 206 refers to the GXID management table 204 and acquires record A corresponding to the specified GXID (S1401). Note that the existence of the corresponding record A has already been confirmed at the time of xa_prepare, so a situation in which the corresponding record cannot be acquired is not assumed. In the second process, the TM reception program 206 confirms that the value of the LX status 403 of record A acquired in the previous process is "normal" (S1402). If the value of the LX status 403 of record A is "recovery", the TM reception program 206 repeatedly waits for a certain period of time until it is changed to "normal" (S1407).

[0122] In the third process, the TM reception program 206 resumes the KVS 160 side transaction corresponding to the value of LXID 402 of record A, i.e., the transaction in the first KVS 160-1 (S1403). In the fourth process, the TM reception program 206 creates a query (GXID query) for registering data corresponding to the specified GXID in the commit management map 221 on the KVS, and causes the resumed KVS 160 side transaction to execute the query (S405, S1404). When the commit is completed, the first KVS 160-1 notifies the first RM adapter 150-1 that the process was successful (S406).

[0123] In the fifth process, the TM reception program 206 commits the transaction on the KVS 160 side that has been resumed (S407, S1405). When the commit is completed, the first KVS 160-1 notifies the first RM adapter 150-1 that the process was successful (S408). In the sixth process, the TM reception program 206 causes the first KVS 160-1 to execute a query to obtain the data registered in the fourth process from the commit management map 221 on the first KVS 160-1 (S1406). Furthermore, the TM reception program 206 confirms that data can be obtained from the execution result (S409, S410, S1408). If the data is not obtained, the TM reception program 206 returns to the first process and starts over (S1409, S1402).

[0124] The RM adapter 150 has a Tx end detection program 202 resident therein in addition to the TM reception program 206 and AP reception program 201. The operation of the Tx end detection program 202 is as described with reference to FIG.

[0125] <1-5. When KVS goes down and recovers in pattern 1> When the KVS 160 recovers from a downtime, the RM adapter 150 first runs the KVS resume program 208. The KVS resume program 208 (FIG. 24) executes the following processes. First, the KVS resume program 208 overwrites the values ​​of the LX status 403 of all records in the GXID management table 204 with "recovery" (S1801). Second, the KVS resume program 208 starts a new transaction on the KVS 160 side for each record in the GXID management table 204 (S504, S506) and overwrites the LXID (S1802). In the example shown in FIG. 34, since there were two records in the GXID management table 204, a total of two transactions are started in S504 and S506.

[0126] Third, the KVS resume program 208 sorts the list of all records in the query management table 209 in ascending order by the values ​​of the sequence number 601, and then repeats the following processes 3A and 3B in order starting from the first record. (3A) A record corresponding to the value of GXID 602 ​​of the record to be processed is obtained from the GXID management table 204, and the transaction on the KVS 160 side corresponding to the value of LXID 402 of the obtained record is resumed (S1805). (3B) The value of the query 603 of the record to be processed is executed by the resumed transaction on the KVS 160 side (S1806). Fourth, the KVS resume program 208 overwrites the values ​​of LX status 403 of all records in the GXID management table 204 with "normal" (S1808).

[0127] <1-6. When the RM adapter goes down and recovers in pattern 1> When the RM adapter 150 goes down and recovers, the RM adapter 150 first executes the RM adapter restart program 203. The RM adapter restart program 203 (FIG. 25) executes the following processes 1 to 5. In the first process, all records A are obtained from the commit management map 221 on the KVS 160 (S604, S1901). In the second process, the GXID is extracted from the KVS key 801 of all records A, and the persistent query management file 212 whose file name is the same as the extracted GXID is deleted (S1903).

[0128] In the third process, exclusive control is performed to prevent simultaneous execution (S1904), and then the following processes 3A and 3B are performed. (3A) All persistent query management files 212 remaining in the external storage device 153 of the RM adapter 150 are read, and the GXID management table 204 and the query management table 209 are generated based on the contents (S1905). (3B) Lock management table regeneration processing (S1906, S1913) is invoked, and the lock management table 205 is regenerated using the query management table 209. In the fourth process, all transactions on the KVS 160 side are rolled back (S606, S1908). In the fifth process, the KVS resume program 208 is executed (S1913).

[0129] Next, Pattern 2 will be explained, focusing on the differences from Pattern 1. <2-2. When a query is received using pattern 2> In (4A) of the fourth process, the behavior when the lock management table update process shown in Figures 27 to 29 is called is different. In pattern 1, if the key cannot be locked, this process waits, but in optimistic locking, the process proceeds as is without waiting.

[0130] <2-3. When xa_prepare is accepted in pattern 2> Between the first process and the second process, a process for calling the lock management table verification process shown in Fig. 30 is inserted. If the verification fails (a dirty read occurs), a distributed Tx cleanup process is called to erase the data related to the specified GXID, and then an error is returned to the TM 100. If the verification is successful, i.e., if a dirty read does not occur, the process proceeds to the second process.

[0131] If another distributed transaction referencing the data before the update that AP 110 is trying to update is in doubt, that is, if there is one or more elements in CRS 504 of the record corresponding to the data to be updated in lock management table 205, the following processing is performed: That is, this processing waits until the in-doubt state of the distributed transaction is resolved, that is, CRS 504 becomes an empty set.

[0132] <2-4. When xa_commit is accepted in pattern 2> The Tx end detection program 202 is rewritten as follows. If data is obtained, the commit was successful, so the distributed Tx cleanup process for the GXID obtained in the fourth process is called. At that time, the GXID obtained in the fourth process is removed from the CRS 504 of all records in the lock management table 205, and the distributed Tx preparation process of another distributed transaction that was waiting for those CRS 504 to become an empty set is resumed. After the distributed Tx cleanup process is completed, the process returns to the first process.

[0133] According to the above-described first embodiment, the following advantageous effects can be obtained. (1) In patterns 1 and 2, the KVS 160, which is a data store, has a transaction control function. The KVS 160 has a commit management map 221, which is an area that stores GXID, which is an identifier for a distributed transaction. In patterns 1 and 2, the RM adapter 150, which is an adapter connected to the KVS 160, which does not have a distributed transaction control function, executes the following control method. The control method executed by the RM adapter 150 includes the following proxy processing, persistence processing, distributed Tx confirmation first processing, and store resume processing. The proxy processing is a process in which, when the RM adapter 150 receives a receive query, which is a query, from the AP 110, the RM adapter 150 locks the data targeted by the receive query (S1006 in FIG. 15), temporarily saves the receive query (S1008 in FIG. 15), and then causes the transaction on the data store side to execute the receive query (S1103 in FIG. 16). In the persistence process, when the RM adapter 150 receives a prepare command from the TM 100 that manages distributed transaction control between multiple data stores, it uses the lock management table 205 to determine whether or not commit is possible, and if commit is possible (S1305: Yes or S1303: Yes in FIG. 18), it persists the GXID to be committed and the temporarily saved received query (FIG. 19). In the first distributed Tx confirmation process (FIG. 20), when the RM adapter 150 receives a commit command from the transaction manager, it causes the transaction on the data store side to execute a GXID addition query, which is a query that adds the GXID to be committed to the commit management map 221 (S1404), and then commits the transaction on the data store side (S1405). In the store resume process (Fig. 24), when the KVS 160 recovers from a downtime, the RM adapter 150 references the commit management map 221 stored in the recovered KVS 160, starts a new transaction in the data store for the in-doubt distributed transaction, replays the persisted query, and commits the distributed transaction that should have been committed but remains in an in-doubt state. Therefore, service can be started quickly when the KVS 160, which is the data store, recovers from a downtime.

[0134] (2) The control method executed by the RM adapter 150 (S1903 to S1909 in FIG. 25) includes an RM adapter resume process which, when the RM adapter 150 recovers from a downtime, rolls back all transactions on the KVS 160 side (S1908), and uses the persistent query management data and commit management map 221, which are a collection of the GXID to be committed, initial data, simulated queries, and information used for transaction control, to regenerate locks on in-doubt transactions and cause a new transaction on the data store side to execute a query. This allows services to start quickly when the RM adapter 150 recovers from a downtime.

[0135] (3) In patterns 3 and 4, the KVS 160, which is a data store, does not have a transaction control function. The RM adapter 150 in patterns 3 and 4 executes the following control method. The control method executed by the RM adapter 150 includes the following proxy processing, persistence processing, distributed Tx confirmation second processing, and store resume processing. The proxy processing is a process in which, when the RM adapter 150 accepts a received query, which is a query, from the AP 110, the RM adapter 150 locks the data targeted by the received query (S1006 in FIG. 15), obtains initial data targeted by the received query from the KVS 160 (S1203 in FIG. 17), simulates the execution of the query instead of the data store using the initial data or intermediate data (S1205), and holds the result of the simulation as intermediate data (S1206). The persistence process is a process in which, when the RM adapter 150 receives a prepare command from a transaction manager that manages distributed transaction control between multiple data stores, it uses lock information to determine whether or not commit is possible, and if commit is possible, persists the GXID to be committed, the initial data, and the simulated query. The second distributed Tx determination process (FIG. 21) is a process in which, when the RM adapter 150 receives a commit command from the transaction manager, it causes the data store to execute a series of queries that link a query to update the initial data, a receive query, and a GXID addition query that is a query to add the GXID to the commit management map 221. The store resume process is a process in which, when the data store recovers from a downtime, it refers to the commit management map 221 of the data store and commits distributed transactions that should have been committed but remain in an in-doubt state. This allows service to be started early when the KVS 160, which is the data store, recovers from a downtime.

[0136] (4) The control method executed by the RM adapter 150 (S1910 to S1914 in FIG. 25) includes an RM adapter restart process that, when the adapter recovers from a downtime, re-establishes locks on in-doubt distributed transactions using information persisted in the KVS 160 and the commit management map 221 of the data store.

[0137] (Variation 1) In the embodiment described above, each RM adapter 150 was provided with both the RM adapter resume program 203 and the KVS resume program 208. However, it is sufficient for each RM adapter 150 to be provided with at least one of the RM adapter resume program 203 and the KVS resume program 208. Also, while the RM adapter 150 and KVS 160 support both pessimistic locking and optimistic locking, it is sufficient for them to support at least one of pessimistic locking and optimistic locking.

[0138] In each of the above-mentioned embodiments and modifications, the configuration of the functional blocks is merely an example. Some functional configurations shown as separate functional blocks may be integrated, or a configuration shown in one functional block diagram may be divided into two or more functions. In addition, some of the functions of each functional block may be provided by other functional blocks.

[0139] In the above-mentioned embodiments and modifications, the program executed by the RM adapter 150 is stored in advance in the external storage device 153, but the RM adapter 150 may also be equipped with an input / output interface (not shown), and the program may be loaded from another device via a medium available to the input / output interface when necessary. Here, the medium refers to, for example, a storage medium that is detachable from the input / output interface, or a communication medium, that is, a network such as a wired, wireless, or optical network, or a carrier wave or digital signal that propagates through the network. Furthermore, some or all of the functions realized by the program may be realized by a hardware circuit or an FPGA.

[0140] The above-mentioned embodiments and modifications may be combined with each other. Although various embodiments and modifications have been described above, the present invention is not limited to these. Other aspects that are conceivable within the scope of the technical idea of ​​the present invention are also included in the scope of the present invention. [Explanation of symbols]

[0141] 150:RM adapter 160 :KVS 201:AP Reception Program 202: Tx end detection program 203 : RM adapter resume program 204: GXID management table 205: Lock management table 206: TM Reception Program 207:KVS Cleaning Program 208:KVS Reopening Program 209 : Query management table 211: Sequence number management file 212 : Persistent query management file 215: Temporary data management table 216: Persistent Tx management file 221: Commit management map

Claims

1. A control method executed by an adapter connected to a data store having a transaction control function and not having a distributed transaction control function, comprising: The data store includes a commit management map that is an area for storing a GXID that is an identifier of a distributed transaction, an agency process in which, when the adapter receives an incoming query from an application program, the agency locks data targeted by the incoming query, temporarily stores the incoming query, and causes the data store to execute the incoming query as a transaction controlled by the data store; A persistence process in which, when the adapter receives a prepare command from a transaction manager that manages distributed transaction control among the multiple data stores, it determines whether or not a commit is possible using lock information, and if the commit is possible, it persists the GXID to be committed and the temporarily stored received query; When the adapter receives a commit command from the transaction manager, a GXID addition query is executed in the data store as a transaction controlled by the data store, which is a query for adding the GXID to be committed to the commit management map, and then a confirmation process is performed to commit the transaction; When the data store recovers from a downtime, the adapter refers to the commit management map, starts a new transaction in the data store for the in-doubt distributed transaction, replays the persisted query, and commits the distributed transaction that should have been committed but remains in the in-doubt state.

2. 2. The control method according to claim 1, The control method further includes an adapter restart process that, when the adapter recovers from a downtime, rolls back all transactions controlled by the data store, and uses the GXID to be committed, initial data, simulated queries, and persistent query management data, which is a collection of information used for transaction control, and the commit management map to regenerate locks on in-doubt transactions, and causes the data store to execute queries as new transactions.

3. 2. The control method according to claim 1, A control method using pessimistic locking for lock control in the adapter.

4. 2. The control method according to claim 1, A control method using optimistic locking for lock control in the adapter.

5. A control method executed by an adapter connected to a data store having neither a transaction control function nor a distributed transaction control function, comprising: The data store includes a commit management map that is an area for storing a GXID that is an identifier of a distributed transaction, an acting process in which, when the adapter receives an incoming query from an application program, the adapter locks data that is the target of the incoming query, acquires initial data that is the target of the incoming query from the data store, simulates execution of the incoming query on behalf of the data store using the initial data or intermediate data, and holds a result of the simulation as the intermediate data; a persistence process in which, when the adapter receives a prepare command from a transaction manager that manages distributed transaction control among the multiple data stores, the adapter uses lock information to determine whether or not a commit is possible, and if so, the adapter persists the GXID, the initial data, and the simulated received query; a commit process in which, when the adapter receives a commit command from the transaction manager, the data store executes a series of queries that are a concatenation of a query to update the initial data, the receive query, and a GXID add query that is a query to add the GXID to the commit management map; a store resume process for, when the data store recovers from a downtime, referencing the commit management map of the data store and committing distributed transactions that should have been committed but remain in an in-doubt state.

6. 6. The control method according to claim 5, The control method further includes an adapter restart process that, when the adapter recovers from a downtime, regenerates locks on in-doubt distributed transactions using information persisted in the adapter and the commit management map of the data store.

7. 6. The control method according to claim 5, A control method using pessimistic locking for lock control in the adapter.

8. 6. The control method according to claim 5, A control method using optimistic locking for lock control in the adapter.

9. An adapter connected to a data store having a transaction control function and not having a distributed transaction control function, The data store includes a commit management map that is an area for storing a GXID that is an identifier of a distributed transaction, an agent unit that, when the adapter receives an incoming query from an application program, locks data targeted by the incoming query, temporarily stores the incoming query, and causes the data store to execute the incoming query as a transaction controlled by the data store; a persistence unit that, when the adapter receives a prepare command from a transaction manager that manages distributed transaction control among the multiple data stores, determines whether or not a commit is possible using lock information, and persists the GXID to be committed and the temporarily stored received query if the commit is possible; a commit processing unit that, when the adapter receives a commit command from the transaction manager, causes the data store to execute a GXID addition query, which is a query for adding the GXID to be committed to the commit management map, as a transaction controlled by the data store, and then commits the transaction; and a store resume processing unit that, when the data store recovers from a downtime, refers to the commit management map, starts a new transaction in the data store for an in-doubt distributed transaction, replays the persisted received query, and commits a distributed transaction that should have been committed but remains in an in-doubt state.

Images