Transaction processing device and transaction processing method

Abstract

This transaction processing device (for example, an availability unit (12)), when a priority assigned to a transaction τ that is directed to an entity of a replica which is a database partition is equal to or higher than a priority assigned to a transaction (valid reservation holder) that holds a reservation of an entity, cancels the reservation held by the valid reservation holder, and causes the transaction τ to hold the reservation of the entity. Further, the coordinator (122) causes the replica to commit the transaction that holds the reservation.

Description

Transaction processing device and transaction processing method

[0001] The present invention relates to a transaction processing device and a transaction processing method.

[0002] Distributed database management systems are becoming increasingly popular, achieving high availability and scalability by splitting and replicating databases across multiple servers. In these distributed database management systems, the mechanism for executing transactions in parallel while maintaining database integrity and replication consistency is called distributed transaction processing. A transaction is a series of read and write operations on database entities.

[0003] TAPIR, a distributed transaction processing method based on multi-version optimistic timestamp ordering, is known (see, for example, Non-Patent Document 1). In a full replication configuration where each region has a complete data set, TAPIR can commit a conversational distributed transaction in 1-2 WAN RTT. A conversational distributed transaction is one in which a client executes transaction operations interactively.

[0004] TAPIR consists of replicas of database partitions, a coordinator that executes transaction operations and arbitrates between replicas, and clients that request each transaction operation. When a read request is received from a client, the coordinator reads the latest value of the database entity from the replica in the local region and sends a prepare-to-commit request to all replicas in all partitions. A replica that receives a prepare-to-commit request verifies the set of versions of the read entity with the set of entities to be written, determines whether the transaction in that partition can be committed, and responds with the result to the coordinator. The coordinator collects the replica responses, determines whether the transaction can be committed, and returns the result to the client. The coordinator also asynchronously sends learn and commit requests to all replicas in all partitions to reflect the changes made by the transaction in the database.

[0005] In TAPIR, multiple transactions accessing the same entity may be executed in parallel on each replica in a different order, which may result in the transaction being committed with a delay of 2 WAN RTTs or the transaction itself being aborted.

[0006] Also known is Natto (see, for example, Non-Patent Document 2), which is a method for prioritizing and processing distributed transactions based on Carousel (see, for example, Non-Patent Document 3).

[0007] Natto is a distributed transaction processing method based on hybrid concurrency control that combines lock-based concurrency control and optimistic concurrency control. Natto assumes two-round fixed-set interactive (2FI) transactions, where the entities being accessed are known before execution and all write operations are executed after all read operations. It also assumes that transactions are assigned a binary priority (high or low). In a full replication configuration, Natto can commit a 2FI transaction in 1 WAN RTT.

[0008] In Natto, when a read request is received from a client, the coordinator simultaneously sends a read request and a prepare to commit request to the leader replica of each partition. The replica that receives the request responds to the client with the value of the entity and determines whether to commit the transaction in that partition.

[0009] Here, replicas decide whether to commit using lock-based concurrency control for transactions with higher priority and optimistic concurrency control for transactions with lower priority. The replicas respond to the coordinator whether to commit and then asynchronously replicate the results to other replicas. When the client receives the entity values, it calculates the entity values ​​to write and sends a commit request to the coordinator. The coordinator collects responses from leader replicas of all partitions, determines whether the entire transaction can be committed, and returns the result to the client. If the transaction can be committed, the coordinator sends a commit request to all leader replicas, and the leader replicas reflect the changes made by the transaction in the database.

[0010] Irene Zhang, Naveen Kr. Sharma, Adriana Szekeres, Arvind Krishnamurthy, and Dan R. K. Ports. "Building consistent transactions with inconsistent replication," In Proc. SOSP '15, p. 263-278, 2015. Linguan Yang, Xinan Yan, and Bernard Wong. "Natto: Providing distributed transaction prioritization for high-contention workloads," In Proc. SIGMOD '22, p. 715-729, 2022. Xinan Yan, Linguan Yang, Hongbo Zhang, Xiayue Charles Lin, Bernard Wong, Kenneth Salem, and Tim Brecht. "Carousel: Low-latency transaction processing for globally-distributed data," In Proc. SIGMOD '18, p.231-243, 2018.

[0011] However, conventional techniques may not be able to perform transaction processing reliably and conveniently.

[0012] For example, under high contention conditions, TAPIR may cause a particular transaction to repeatedly abort and become unable to commit. In the worst case scenario, TAPIR may cause a particular transaction to repeatedly abort and become unable to commit.

[0013] For example, Natto is based on 2FI transactions, and requires that you specify the entity to be accessed in advance before executing a transaction, which makes it less convenient.

[0014] The present invention has been made in view of the above, and has as its object to execute transaction processing that is reliable and highly convenient.

[0015] In order to solve the above-mentioned problems and achieve the object, the transaction processing device of the present invention is characterized by having a reservation control unit that, when the priority assigned to a first transaction targeting an entity of a replica that is a database partition is equal to or higher than the priority assigned to a second transaction holding a reservation for the entity, cancels the reservation held by the second transaction and causes the first transaction to hold the reservation for the entity, and a commit control unit that causes the replica to commit the transaction holding the reservation.

[0016] According to the present invention, it is possible to execute transaction processing reliably and conveniently.

[0017] Fig. 1 is a diagram showing an example of the configuration of a transaction processing system according to an embodiment. Fig. 2 is a sequence diagram showing the flow of transaction processing according to an embodiment. Fig. 3 is a flowchart showing the flow of processing in a transaction processing device according to an embodiment. Fig. 4 is a flowchart showing the flow of processing in a transaction processing device according to an embodiment. Fig. 5 is a diagram showing an example of a computer that executes a transaction processing program. Fig. 6 is a sequence diagram showing the flow of conventional transaction processing.

[0018] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to this embodiment. In addition, in the description of the drawings, the same parts are designated by the same reference numerals.

[0019] 1 is a diagram illustrating an example of the configuration of a transaction processing system according to an embodiment. As illustrated in FIG. 1, the transaction processing system has multiple availability units (availability unit 12, availability unit 22, and availability unit 32). Each availability unit is an example of a transaction processing device.

[0020] An availability unit may be determined based on the required fault tolerance, such as a single server rack (or server racks for each region or country). An availability unit may be one server or multiple servers (e.g., a data center and a server rack). Data is replicated between availability units to ensure fault tolerance.

[0021] For example, to tolerate a power failure in a server rack, each server rack with a different power supply system must be replicated as an availability unit.

[0022] For example, to tolerate system failure due to a regional disaster, data centers in different regions must be replicated as availability units.

[0023] Furthermore, to allow for the blocking of access to the system due to political reasons, for example, it is necessary to replicate each data center in a different country as an availability unit.

[0024] For example, if only a single server failure needs to be tolerated, multiple different servers in the same data center can be replicated as availability units.

[0025] The availability unit 12 has an application 121, a coordinator 122, a replica X1, and a replica Y1. The application 121 functions as a client that requests each operation of a transaction based on the operation of the user 11, etc. The coordinator 122 executes the transaction operations and arbitrates between the replicas. The replica X1 and the replica Y1 are database partitions.

[0026] The availability unit 22 and the availability unit 32 have the same configuration as the availability unit 12. That is, the availability unit 22 has an application 221, a coordinator 222, a replica X2, and a replica Y2. The availability unit 32 has an application 321, a coordinator 322, a replica X3, and a replica Y3. The availability unit 22 is operated by a user 21, and the availability unit 32 is operated by a user 31. Furthermore, the availability unit 12, the availability unit 22, and the availability unit 32 are connected by a network and are capable of data communication with each other. Furthermore, the coordinator is capable of data communication with each replica. For example, the coordinator 122 is connected to each replica with a solid line, which means that the coordinator 122 can communicate with each replica.

[0027] When a transaction accesses a database entity, the coordinator 122 can prevent other transactions with lower priority from accessing the same entity, thereby allowing the transaction with higher priority to be executed first.

[0028] The coordinator 122 can prioritize and execute transactions using a method that extends TAPIR.

[0029] The flow of transaction processing in TAPIR is shown in Fig. 6. Fig. 6 is a sequence diagram showing the flow of conventional transaction processing.

[0030] As shown in FIG. 6, when a coordinator 122a in a conventional availability unit 12a receives a read request from a client, it reads the latest value X of a database entity from replica X1, which is a replica in the local region (a replica in the same availability unit 12a as the coordinator 122a).

[0031] The coordinator 122a then sends a prepare to commit request for the write transaction of Y to all replicas (X1, Y1, X2, Y2, X3, and Y3) of all partitions.

[0032] Each replica that receives the prepare to commit request verifies the set of versions of the entities that it reads and the set of entities to write, determines whether or not the transaction in that partition can be committed, and responds with the result to the coordinator 122a.

[0033] The coordinator 122a collects the replica responses, determines whether the transaction can be committed, and returns the result to the client. The coordinator 122a also asynchronously sends learning and commit requests to all replicas in all partitions to reflect the changes made by the transaction in the database.

[0034] In Figure 6 and other figures, the combination of an arrow and a straight line has the following meaning. For example, the combination of a solid line and a normal arrow (e.g., prepare to commit) indicates synchronous communication. For example, the combination of a solid line and an open arrow (e.g., learn & commit) indicates a request via asynchronous communication. For example, the combination of a dashed line and a normal arrow (e.g., ready to commit) indicates a response via asynchronous communication.

[0035] The flow of transaction processing according to the embodiment is shown in Figure 2. Figure 2 is a sequence diagram showing the flow of transaction processing according to the embodiment. Replicas X1, X2, and X3 are database partitions of a common database. Replicas Y1, Y2, and Y3 are database partitions of a common database.

[0036] Here, it is assumed that a transaction τ occurs in the coordinator 122, and the transaction τ requests a read of X from replica X1, replica X2, or replica X3, and a write of Y to replica Y1, replica Y2, and replica Y3.

[0037] At this time, as shown in FIG. 2, the coordinator 122 of the availability unit 12 attempts to reserve an entity of replica X1, which is a replica of the local region (a replica in the same availability unit 12 as the coordinator 122), by transaction τ.

[0038] If transaction τ fails to reserve an entity on replica X1, the coordinator 122 aborts transaction τ.

[0039] Hereinafter, it is assumed that the coordinator 122 has successfully reserved an entity of replica X1 by transaction τ. In this case, the coordinator 122 reads the value of X. That is, the coordinator 122 attempts to make a reservation before reading the value.

[0040] Furthermore, replica X1 asynchronously exchanges reservation states with replicas X2 and X3, so that entities in replica X1 as well as replicas X2 and X3 are reserved for transaction τ.

[0041] The coordinator 122 asynchronously attempts to reserve the entity on replica Y1 with transaction τ.

[0042] If transaction τ fails to reserve an entity on replica Y1, the coordinator 122 aborts transaction τ.

[0043] Assume that the coordinator 122 has successfully reserved an entity on replica Y1 for transaction τ. Furthermore, replica Y1 asynchronously exchanges reservation status with replicas Y2 and Y3. As a result, entities on replica Y1, as well as replicas Y2 and Y3, are reserved for transaction τ.

[0044] The coordinator 122 then sends a prepare to commit request for Y to all replicas (X1, Y1, X2, Y2, X3, and Y3) of all partitions. Furthermore, the coordinator 122 releases the reservation of the entity on replica X1, replica X2, and replica X3.

[0045] Each replica that receives the prepare to commit request verifies the set of versions of the read entities, the set of entities to write, and the reservation status, determines whether or not to commit the transaction in that partition, and responds with the result to the coordinator 122 .

[0046] The coordinator 122 collects the replica responses, determines whether the transaction can be committed, and returns the result to the client. The coordinator 122 also asynchronously sends requests to all replicas in all partitions to learn, commit, and release the reservation for Y (release the reservation for the entities in replica Y1, replica Y2, and replica Y3), thereby reflecting the changes made by the transaction in the database. The coordinator 122 writes the value Y to replica Y1, which is a replica in the local region. At this time, the coordinator 122 writes the value using replica Y1 as a buffer.

[0047] Now, let us consider the reservation of an entity. If transaction τ holds a reservation for an entity, a reservation for that entity by a transaction with a lower priority than transaction τ will fail. However, a reservation for that entity by a transaction with a higher priority than transaction τ (or with the same priority as transaction τ) will succeed.

[0048] The reservation processing performed by the coordinator 122 will be described with reference to Fig. 3. Fig. 3 is a flowchart showing the flow of processing performed by the transaction processing device according to the embodiment. Note that the subject performing the reservation processing may be each replica.

[0049] First, each entity manages two sets of transactions: a reservation acquirer list and a reservation releaser list. For example, a transaction that is included in entity x's reservation acquirer list but not in entity x's reservation releaser list is a transaction that holds a reservation for entity x and is a valid reserver. Furthermore, the coordinator 122 is assumed to be able to obtain the priority of at least the transactions included in the reservation acquirer list.

[0050] 3, the coordinator 122 calculates a list of valid reservers and the maximum priority of the valid reservers from the reservation acquirer list and reservation releaser list (step S101).

[0051] The coordinator 122 adds the transaction τ to the reservation acquirer list (step S102). At this point, the transaction τ is added to the reservation acquirer list, but whether or not it will ultimately become a valid reserver depends on subsequent processing.

[0052] The coordinator 122 compares the maximum priority of the valid reservers with the priority of transaction τ (step S103). If the maximum priority of the valid reservers is less than or equal to the priority of transaction τ (step S103; Yes), the coordinator 122 proceeds to step S104. If the maximum priority of the valid reservers is greater than the priority of transaction τ (step S103; No), the coordinator 122 proceeds to step S107.

[0053] In step S104, the coordinator 122 determines whether the maximum priority of the valid reservers is equal to the priority of transaction τ. If the maximum priority of the valid reservers is not equal to the priority of transaction τ (step S104; No), the coordinator 122 adds the valid reservers to the reservation releaser list (step S105) and proceeds to step S106. In other words, transaction τ is the only valid reserver.

[0054] If the maximum priority of the valid subscribers is equal to the priority of transaction τ (step S104; Yes), the coordinator 122 proceeds to step S106. That is, transaction τ becomes one of multiple valid subscribers with the same priority.

[0055] In step S106, the coordinator 122 notifies the user that the reservation has been successfully completed (step S106).

[0056] In step S107, the transaction τ is added to the reservation releaser list, and then the coordinator 122 notifies the reservation failure (step S108).

[0057] The process of releasing a reservation by the coordinator 122 will be described with reference to Fig. 4. Fig. 4 is a flowchart showing the flow of processing in the transaction processing device according to the embodiment. Note that the entity that processes the reservation may be each replica.

[0058] 4, the coordinator 122 adds transaction τ to the reservation releaser list (step S201). In this case, even if transaction τ is included in the reservation acquirer list, it is no longer a valid reserver.

[0059] The coordinator 122 (or each replica) functions as a reservation controller and a commit controller. The reservation acquirer list is an example of a first set. The reservation releaser list is an example of a second set. Transaction τ is an example of a first transaction. Valid reservers are an example of a second transaction. Adding a transaction to the reservation releaser list corresponds to canceling a reservation.

[0060] For example, if the priority assigned to a transaction τ targeting an entity in a replica that is a database partition is equal to or higher than the priority assigned to a transaction (a valid reserver) that holds a reservation for the entity, the coordinator 122 cancels the reservation held by the valid reserver and allows transaction τ to hold the reservation for the entity. The coordinator 122 also causes the replica to commit the transaction that holds the reservation. Furthermore, if transaction τ does not hold a reservation for the entity, the coordinator 122 halts the process of having the replica commit transaction τ.

[0061] 3 and 4, the coordinator 122 adds transaction τ to the reservation acquirer list, and if the priority assigned to transaction τ is higher than the priority assigned to a transaction (valid reserver) that is included in the reservation acquirer list but not included in the reservation releaser list, adds the transaction that is a valid reserver to the reservation releaser list, and if the priority assigned to transaction τ is lower than the priority assigned to a transaction that is a valid reserver, adds transaction τ to the reservation releaser list. Also, the coordinator 122 considers a transaction that is included in the reservation acquirer list but not included in the reservation releaser list to be a transaction that holds a reservation, and has the replica commit it.

[0062] According to the availability unit 12 of the embodiment, like TAPIR, interactive distributed transactions can be committed with a 1-2 WAN RTT and can be prioritized for processing. For example, in the embodiment, by assigning a higher priority to aborted transactions and executing them preferentially, it is possible to prevent a specific transaction from repeatedly aborting and becoming unable to commit. As a result, according to the embodiment, it is possible to execute transaction processing reliably and conveniently.

[0063] In addition, in this embodiment, the list of valid reservers is managed using two sets of reservation acquirers and reservation releasers based on Conflict-Free Replicated Data Types (CRDT). This allows for reservation states to differ between replicas when acquiring or releasing a reservation, and the reservation states converge safely during commit preparation, commit, and abort. This enables transaction priority execution while satisfying serializability.

[0064] [Program] In one embodiment, the transaction processing device can be implemented by installing a transaction processing program that executes the above-described processing as package software or online software on a desired computer. For example, by having an information processing device execute the transaction processing program, the information processing device can function as a transaction processing device. The information processing device referred to here includes desktop and notebook personal computers. Other examples of information processing devices include smartphones, tablet terminals, etc.

[0065] 5 is a diagram showing an example of a computer that executes a transaction processing program. The computer 1000 includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0066] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012. The ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120. The video adapter 1060 is connected to, for example, a display 1130.

[0067] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define each process of the transaction processing device are implemented as program modules 1093 in which computer-executable code is written. The program modules 1093 are stored, for example, in the hard disk drive 1090. For example, the program modules 1093 for executing processes similar to those of the functional configuration of the transaction processing device are stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD.

[0068] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in the memory 1010 or the hard disk drive 1090. The CPU 1020 then reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary, and executes the processing of the above-described embodiment.

[0069] The program module 1093 and program data 1094 may not necessarily be stored in the hard disk drive 1090, but may also be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or a wide area network (WAN)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

[0070] Although the present invention has been described above as an embodiment, the present invention is not limited to the description and drawings that form part of the disclosure of the present invention. In other words, other embodiments, examples, and operational techniques that can be made by those skilled in the art based on the present invention are all included in the scope of the present invention.

[0071] 10 Transaction processing device 11, 21, 31 User 12, 22, 32 Availability unit 121, 221, 321 Application 122, 222, 322 Coordinator X1, Y1, X2, Y2, X3, Y3 Replica

Claims

1. A transaction processing device characterized by having: a reservation control unit that, when the priority assigned to a first transaction targeting an entity of a replica that is a database partition is equal to or higher than the priority assigned to a second transaction that holds a reservation for the entity, cancels the reservation held by the second transaction and causes the first transaction to hold the reservation for the entity; and a commit control unit that causes the replica to commit the transaction that holds the reservation.

2. The transaction processing device according to claim 1, characterized in that the commit control unit halts the process of committing the first transaction to the replica if the first transaction does not hold a reservation for the entity.

3. The transaction processing device described in claim 1, characterized in that the reservation control unit adds the first transaction to a first set, and if the priority assigned to the first transaction is greater than the priority assigned to the second transaction that is included in the first set but not included in the second set, adds the second transaction to the second set, and if the priority assigned to the first transaction is less than the priority assigned to the second transaction, adds the first transaction to the second set; and the commit control unit considers a transaction that is included in the first set but not included in the second set to be a transaction that holds a reservation and causes the replica to commit it.

4. A transaction processing method executed by a transaction processing device, comprising: a reservation control step of, when the priority assigned to a first transaction targeting an entity of a replica that is a database partition is equal to or higher than the priority assigned to a second transaction that holds a reservation for the entity, canceling the reservation held by the second transaction and causing the first transaction to hold the reservation for the entity; and a commit control step of causing the replica to commit the transaction that holds the reservation.

Images