Transaction processing method and apparatus, computer device, and storage medium

Abstract

The application discloses a transaction processing method and device, computer equipment and a storage medium, and belongs to the technical field of databases. The method comprises the following steps: determining a latest transaction for modifying a data record operated by a target transaction based on the data record; performing conflict detection on lock application of the target transaction based on global read lock information and write lock waiting information of the latest transaction; and applying for adding a lock corresponding to an operation type of the operation to the data record in the case where the conflict detection indicates that there is a conflict. The application implements concurrent control through a transaction lock scheme, does not need to depend on a global lock manager, only applies to create lock information in the case where there is a conflict, does not need to consume resources to maintain lock information in the case where there is no conflict, can greatly reduce the creation of unnecessary row locks in the system, and thus saves storage overhead and memory occupation of concurrent control under the lock mechanism.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a transaction processing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] With the development of database technology, MySQL is one of the most popular open-source relational database management systems. The default storage engine of the MySQL database system is the InnoDB engine. The InnoDB engine uses table locks and record locks to implement concurrent control of database transactions.

[0003] In the InnoDB engine, a global lock manager (Lock System) is maintained. The lock manager is a global data structure used to manage table locks and row locks for each transaction. In high-concurrency scenarios, the concurrency control mechanism based on locking requires each concurrent transaction to request lock resources in the lock manager. If the conflicts between these concurrent transactions are small, it will lead to the creation of many unnecessary row locks. These unnecessary row locks consume a lot of memory and have a large storage overhead. Summary of the Invention

[0004] This application provides a transaction processing method, apparatus, computer device, and storage medium, which can reduce the memory usage and storage overhead of the system under the implementation of locking mechanisms. The technical solution is as follows:

[0005] On the one hand, a transaction processing method is provided, the method comprising:

[0006] Based on the data records operated by the target transaction, determine the latest transaction that modified the data records;

[0007] Based on global read lock information and the write lock wait information of the latest transaction, conflict detection of lock requests is performed on the target transaction. The global read lock information is used to manage read locks in the database system, and the write lock wait information is used to record each transaction waiting for the write lock held by the latest transaction.

[0008] If a conflict is detected, a lock corresponding to the operation type of the operation is requested to be added to the data record.

[0009] On one hand, a transaction processing apparatus is provided, the apparatus comprising:

[0010] The determination module is used to determine the latest transaction that modified the data record based on the data record operated on by the target transaction.

[0011] The conflict detection module is used to perform lock request conflict detection on the target transaction based on global read lock information and write lock waiting information of the latest transaction. The global read lock information is used to manage read locks in the database system, and the write lock waiting information is used to record each transaction waiting for the write lock held by the latest transaction.

[0012] The lock request module is used to request a lock corresponding to the operation type of the operation to be added to the data record when the conflict detection indication indicates a conflict.

[0013] In one possible implementation, the collision detection module includes:

[0014] The determining unit is configured to determine the lock type to be requested by the target transaction based on the operation type.

[0015] The first conflict detection unit is used to perform write lock conflict detection only on the target transaction when the lock type is a read lock;

[0016] The second conflict detection unit is used to perform read lock conflict detection and write lock conflict detection on the target transaction when the lock type is write lock.

[0017] In one possible implementation, the first collision detection unit includes:

[0018] The acquisition subunit is used to acquire the transaction status of the latest transaction when the lock type is a read lock;

[0019] The determination subunit is used to determine that there is no conflict when the transaction state is not active.

[0020] The determining subunit is further configured to determine that a conflict exists when the transaction state is active.

[0021] In one possible implementation, when the transaction state is not active, the first conflict detection unit further includes:

[0022] The query subunit is used to query the read lock holding queue of the data record in the global read lock information, using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0023] Add a sub-unit, used to add the target transaction to the read lock holding queue if the target transaction is not present in the read lock holding queue.

[0024] In one possible implementation, the write lock wait information of the latest transaction includes a write lock wait queue for each data record operated by the latest transaction, the write lock wait queue being used to record each transaction waiting for the write lock held by the latest transaction on the data record;

[0025] When the transaction state is active, the first conflict detection unit further includes:

[0026] Add a sub-unit, used to add the target transaction to the write lock wait queue of the data record in the write lock wait information of the latest transaction;

[0027] The setting subunit is used to set the blocking transaction parameter of the target transaction to the transaction identifier of the latest transaction, wherein the blocking transaction parameter is used to characterize the transaction that the target transaction is waiting for.

[0028] In one possible implementation, the second collision detection unit includes:

[0029] The read lock conflict detection subunit is used to perform read lock conflict detection on the target transaction when the lock type is a write lock;

[0030] A determining subunit is configured to determine that a conflict exists when the read lock conflict detection indicates that a read lock conflict exists;

[0031] A write lock conflict detection subunit is used to perform write lock conflict detection on the target transaction when the read lock conflict detection indicates that there is no read lock conflict;

[0032] The determining subunit is further configured to determine the conflict detection result as having a conflict if the write lock conflict detection indication indicates that a write lock conflict exists; and to determine the conflict detection result as not having a conflict if the write lock conflict detection indication indicates that a write lock conflict does not exist.

[0033] In one possible implementation, the read lock conflict detection subunit is used for:

[0034] In the global read lock information, the read lock holding queue of the data record is queried using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0035] If the read lock holding queue is empty, return that there is no read lock conflict;

[0036] If the read lock holding queue contains only the target transaction, query the read lock waiting queue of the data record. The read lock waiting queue is used to record each transaction waiting for a read lock held on the data record. If the read lock waiting queue is empty, return that there is no read lock conflict. If the read lock waiting queue is not empty, return that there is a read lock conflict.

[0037] If the read lock holding queue contains transactions other than the target transaction, a read lock conflict is returned.

[0038] In one possible implementation, if the read lock holding queue contains only the target transaction and the read lock waiting queue is not empty, or if the read lock holding queue contains transactions other than the target transaction, the second conflict detection unit further includes:

[0039] Add a sub-unit to add the target transaction to the read lock waiting queue;

[0040] The adding subunit is further configured to, based on the write lock waiting information of the target transaction, determine each transaction waiting for the target transaction to request a write lock on the data record; and add each transaction waiting for the target transaction to request a write lock on the data record to the read lock waiting queue.

[0041] In one possible implementation, the second collision detection unit further includes:

[0042] The setting subunit is used to set the blocking transaction parameter of any transaction added to the read lock waiting queue to the transaction identifier of the first transaction in the read lock holding queue other than the transaction itself. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0043] In one possible implementation, the write lock conflict detection subunit is used for:

[0044] Obtain the transaction status of the latest transaction;

[0045] If the transaction is not in an active state, return that there is no write lock conflict;

[0046] If the transaction is in an active state, a write lock conflict is detected.

[0047] In one possible implementation, if the transaction state is not active, the second conflict detection unit further includes:

[0048] A write sub-unit is used to write the transaction identifier of the target transaction into the target hidden field of the data record, wherein the target hidden field is used to record the transaction identifier of the latest transaction that modifies the data record.

[0049] In one possible implementation, the write lock wait information of the latest transaction includes a write lock wait queue for each data record operated by the latest transaction, the write lock wait queue being used to record each transaction waiting for the write lock held by the latest transaction on the data record;

[0050] When the transaction state is active, the second conflict detection unit further includes:

[0051] Add a sub-unit, used to add the target transaction to the write lock wait queue of the data record in the write lock wait information of the latest transaction;

[0052] The adding subunit is further configured to determine, based on the write lock wait information of the target transaction, each transaction waiting for the target transaction to request a write lock on the data record; and to add each transaction waiting for the target transaction to request a write lock on the data record to the write lock wait queue of the data record in the write lock wait information of the latest transaction.

[0053] In one possible implementation, the second collision detection unit further includes:

[0054] The setting subunit is used to set the blocking transaction parameter of any transaction added to the write lock waiting queue to the transaction identifier of the latest transaction. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0055] In one possible implementation, when the lock type is a read lock, the conflict detection module further includes:

[0056] The query unit is used to query the read lock holding queue of the data record in the global read lock information after the target transaction is committed, using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0057] The wake-up unit is used to wake up the first transaction in the read lock waiting queue of the data record when the read lock holding queue is empty. The read lock waiting queue is used to record each transaction waiting for a read lock held on the data record.

[0058] The wake-up unit is also configured to wake up the transaction when the read lock holding queue contains only a single transaction and the transaction happens to be the first transaction in the read lock waiting queue.

[0059] The setting unit is used to, otherwise, for each transaction in the read lock waiting queue, set the blocking transaction parameter of the transaction to the transaction identifier of the first transaction in the read lock holding queue other than the transaction itself, wherein the blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0060] In one possible implementation, for transactions woken up after the target transaction is committed, the conflict detection module further includes:

[0061] An adding unit is used to add each transaction other than the awakened transaction in the read lock waiting queue to the write lock waiting queue of the data record in the write lock waiting information of the awakened transaction.

[0062] The setting unit is further configured to set the blocking transaction parameter of any transaction added to the write lock waiting queue to the transaction identifier of the awakened transaction, wherein the blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0063] In one possible implementation, when the lock type is a write lock, the conflict detection module further includes:

[0064] The traversal unit is used to traverse the write lock wait queue of each data record in the write lock wait information of the target transaction after the target transaction is committed. The write lock wait queue is used to record each transaction waiting for the write lock held by the target transaction on the data record.

[0065] The wake-up unit is used to wake up the first transaction in the write lock waiting queue of any data record if the first transaction in the write lock waiting queue requests a write lock; and wake up all transactions in the write lock waiting queue that request a read lock if the first transaction in the write lock waiting queue requests a read lock.

[0066] In one possible implementation, for any data record's write lock waiting queue, if the first transaction in the write lock waiting queue requests a write lock, the conflict detection module further includes, for the first transaction:

[0067] An adding unit is used to add each transaction other than the first transaction in the write lock wait queue to the write lock wait queue of the data record in the write lock wait information of the first transaction.

[0068] The setting unit is further configured to set the blocking transaction parameter of any transaction added to the write lock waiting queue to the transaction identifier of the first transaction, wherein the blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0069] In one possible implementation, for any write lock waiting queue of a data record, if the lock type requested by the first transaction in the write lock waiting queue is a read lock, the conflict detection module further includes:

[0070] The addition unit is used to add all transactions with read locks applied for in the write lock waiting queue to the read lock holding queue of the data record in the global read lock information.

[0071] The adding unit is also used to add all transactions that have applied for write locks in the write lock waiting queue to the read lock waiting queue of the data record.

[0072] In one possible implementation, the setting unit is further configured to:

[0073] For any transaction added to the read lock waiting queue, the blocking transaction parameter of the transaction is set to the transaction identifier of the first transaction in the read lock holding queue other than the transaction itself. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0074] In one possible implementation, the determining module is further configured to: after the target transaction is rolled back, determine the first transaction that the target transaction is waiting for based on the blocking transaction parameters of the target transaction;

[0075] The device further includes:

[0076] The deletion module is used to delete the target transaction from the write lock wait queue of the data records operated by the target transaction in the write lock wait information of the first transaction;

[0077] The deletion module is further configured to delete the target transaction from the read lock waiting queue of the data records operated by the target transaction in the global read lock information.

[0078] In one possible implementation, the device further includes:

[0079] The query module is used to query the read lock holding queue of the data record in the global read lock information, using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0080] The wake-up module is used to wake up the transaction when the read lock holding queue contains only a single transaction and the transaction happens to be the first transaction in the read lock waiting queue.

[0081] On one hand, a computer device is provided, the computer device including one or more processors and one or more memories, the one or more memories storing at least one computer program, the at least one computer program being loaded and executed by the one or more processors to implement the transaction processing method as described above.

[0082] On the one hand, a storage medium is provided that stores at least one computer program, which is loaded and executed by a processor to implement the transaction processing method described above.

[0083] On one hand, a computer program product or computer program is provided, the computer program product or computer program comprising one or more lines of program code stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the computer device to perform the transaction processing method described above.

[0084] The beneficial effects of the technical solutions provided in this application include at least the following:

[0085] By recording read lock information in the database system through global read lock information, and modifying the latest transaction for each data record, it is possible to determine whether a write lock exists on that data record and who holds the write lock. Furthermore, write lock wait information is distributed and stored in the context information of each transaction. This allows the read-write conflict detection of the entire database system to be independent of the lock manager and does not require accessing the mutex every time. After completing the conflict detection using global read lock information and the write lock wait information of the latest transaction corresponding to the data record to be operated on, the corresponding lock information can be created only for cases where there is a conflict. For cases where there is no conflict, there is no need to consume resources to maintain lock information. This can greatly reduce the creation of unnecessary row locks in the system, thereby saving storage overhead and memory usage for concurrency control under the locking mechanism. Attached Figure Description

[0086] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0087] Figure 1 This is a schematic diagram of the implementation environment of a transaction processing method provided in an embodiment of this application;

[0088] Figure 2This is a logical diagram illustrating write lock waiting information provided in an embodiment of this application;

[0089] Figure 3 This is a logical diagram illustrating a global read lock information provided in an embodiment of this application;

[0090] Figure 4 This is a flowchart of a transaction processing method provided in an embodiment of this application;

[0091] Figure 5 This is a flowchart of a transaction processing method provided in an embodiment of this application;

[0092] Figure 6 This is a flowchart of a transaction processing method provided in an embodiment of this application;

[0093] Figure 7 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of this application;

[0094] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0095] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0096] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0097] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with essentially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor are there any restrictions on quantity or execution order.

[0098] In this application, the term "at least one" means one or more, and "multiple" means two or more, for example, multiple first positions means two or more first positions.

[0099] The term "including at least one of A or B" in this application refers to the following situations: including only A, including only B, and including both A and B.

[0100] When the user-related data involved in this application is applied to specific products or technologies using the methods of this application's embodiments, user permission, consent, or full authorization must be obtained, and the collection, use, and processing of the related data must comply with the relevant laws, regulations, and national standards of the country in which it is located.

[0101] Before introducing the embodiments of this application, it is necessary to introduce some basic concepts in the field of cloud technology.

[0102] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. It encompasses network technologies, information technologies, integration technologies, management platform technologies, and application technologies based on cloud computing business models. These technologies can form resource pools, allowing for on-demand, flexible, and convenient use. Cloud computing technology will become a crucial support in the cloud technology field. Backend services of technical network systems require substantial computing and storage resources, such as those for video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring data to be transmitted to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will require robust system support, all of which can be achieved through cloud computing.

[0103] Cloud storage is a new concept that has been extended and developed from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology and distributed storage file systems to bring together a large number of storage devices of various types in the network (storage devices are also called storage nodes) to work together through application software or application interfaces to provide data storage and business access functions to the outside world.

[0104] A database can be simply viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, capable of being shared by multiple users, with minimal redundancy, and independent of application programs.

[0105] The following explains the terminology used in the embodiments of this application.

[0106] MySQL Database: MySQL is one of the most popular open-source relational database management systems. Developed by the Swedish company MySQL AB, it is a product of Oracle. SQL stands for Structured Query Language.

[0107] InnoDB engine: One of the database engines in the MySQL database system, and currently the default storage engine in the MySQL database system. The InnoDB engine implements concurrency control of database transactions through table locks and record locks.

[0108] B+tree: A B+ tree is a multi-branch tree data structure. In the InnoDB engine, table data files consist of multiple B+trees. Each data page corresponds to a node in the B+tree. The default size of a data page in the InnoDB engine is 16KB. Furthermore, B+trees do not store data in non-leaf nodes, only key-value pairs, while leaf nodes store both key-value pairs and the actual data.

[0109] Locking mechanism: In database systems, there may be instances where different transactions need to modify the same data record simultaneously. The locking mechanism ensures the correctness of these modifications across different concurrent transactions. In other words, the locking mechanism guarantees that in a multi-concurrency transaction environment, at any given time, only one transaction can acquire the lock on a particular data record, thereby ensuring data consistency.

[0110] Lock System: The lock system is a global data structure in the InnoDB engine used to manage table locks and row locks for each transaction. The key member variable of the lock system is a hash table. The key (also called the key name) of the hash table is a unique identifier for the data table or record row, and the value of the hash table is either a table lock or a record lock. Each row in the data table corresponds to a data record; therefore, each row in the data table is also called a record row. In the InnoDB engine, mutexes control the correctness of concurrent transactions' access to and modification of the global lock system.

[0111] A data record typically refers to a row of data in a table in a relational database. This data record stores the instantiation information of all data columns in the definition of the data table (i.e., the field data corresponding to each data column), and is arranged in the order of the data column definition to form a continuous content. In other words, this continuous content is called a data record of the data table, also known as a tuple.

[0112] A transaction is a logical unit in the execution of operations by a database management system. It consists of a finite sequence of database operations and is the smallest unit of execution for database system operations. Within a system, each series of operations is called a transaction, and a single operation can also be called a transaction.

[0113] Operation: A database operation consists of three parts: operation type, transaction, and variable version. That is, it refers to which type of database operation the transaction performs on which version of the variable. The operation type includes two types: read and write. The variable is the agent (or object) of the database operation. A variable can contain several variable versions (also called versions). Whenever a transaction updates a variable, a new variable version is added. Each variable version is usually identified by a natural number as the version number. The larger the version number, the newer the variable version.

[0114] Read lock: Also known as a shared lock (S lock), if transaction T acquires a read lock on data object A, then transaction T can read A but cannot modify A. Other transactions can only acquire read locks on A, but cannot acquire write locks, until transaction T releases the read lock on A. This ensures that other transactions can read A, but cannot make any modifications to A before transaction T releases the read lock on A.

[0115] Write lock: also known as an exclusive lock (X lock), if transaction T acquires a write lock on data object A, transaction T can read and modify A, while other transactions cannot acquire any locks on A until transaction T releases the write lock on A. This ensures that other transactions cannot read or modify A before transaction T releases the write lock on A.

[0116] In the InnoDB engine of the MySQL database system, table locks and row locks are typically used for transaction concurrency control, while a global lock manager is used to maintain lock information for all concurrent transactions. In current lock-based concurrency control mechanisms, when a transaction attempts to acquire a lock on a data record—that is, when a transaction requests a lock on that data record from the lock manager—it first accesses the lock manager's mutex (i.e., a critical section allocated in memory) and performs conflict detection with existing locks in the mutex. Specifically, based on the record identifier (ID) of the data record being operated on (read or write), the mutex is checked for any existing locks conflicting with that record ID. If no conflict is detected, a new row lock for that data record is inserted into the lock manager, representing that the transaction holds the lock on that data record. For example, a row lock is added to the head of the hash table, and the transaction returns a successful lock acquisition. If a conflict is detected, a row lock for the data record is also created, but added to the tail of the hash table, and the transaction returns a lock wait. Since a hash table can be viewed as a queue with a first-in, first-out (FIFO) property, inserting a row lock at the head of the hash table is equivalent to a successful lock acquisition; the transaction has acquired and holds the lock on the data record. When inserting a row lock at the tail of the hash table, the transaction must wait for all previous transactions corresponding to row locks in the hash table to commit or rollback and release the lock resources on the data record before it can hold the lock on that data record. Furthermore, when a transaction holding a row lock on a data record commits, it first deletes the row lock from the hash table where it is recorded in the lock manager, then iterates through the lock entries with the same key (i.e., record ID) in the lock manager and determines whether it can wake up the next transaction on that data record, thus enabling the committed transaction to release the lock resources acquired on the data record.

[0117] It's evident that since each transaction needs to access the lock manager's mutex when attempting to acquire a lock, this becomes a significant bottleneck affecting database system concurrency in high-concurrency scenarios. When conflicts between concurrent transactions are relatively low, the need for each transaction to request lock resources from the lock manager leads to the creation of many unnecessary row locks. This is because, with low conflict levels, these locks are unlikely to be used for conflict resolution during their lifetime. These unnecessary row locks consume significant memory, resulting in substantial storage overhead. Furthermore, if a concurrent transaction modifies a large amount of data, it needs to request lock resources for every single record modified, causing a sharp increase in the global lock manager's memory usage. In addition, to ensure the multi-threaded safety of the global lock manager, concurrent transactions need to add mutexes when modifying elements in the lock manager. With high conflict levels, the critical code section protected by the mutex becomes longer, leading to increased contention and a sharp decline in system performance.

[0118] In view of this, this application provides a transaction processing method involving a database transaction concurrency control scheme based on transaction locks (hereinafter referred to as the "transaction lock scheme"). Since the transaction lock scheme does not rely on a global lock manager to manage lock information within the database system, it can solve the problems of memory growth and performance degradation that exist in the native InnoDB engine's global lock manager under high concurrency scenarios. Furthermore, by distributing write lock wait information within the context information of the corresponding transaction, it can resolve the performance impact caused by global mutex contention. Moreover, in the transaction lock scheme, transaction wait information is only created when a conflict actually occurs; when no conflict is detected, very little related information needs to be created, thus significantly reducing the memory consumption for lock management.

[0119] Furthermore, in the transaction locking scheme, the hidden field (TRX_ID field) containing the transaction number on each data record in the InnoDB engine can identify the latest transaction that modified that data record. By checking for conflicts between the current transaction and the latest transaction recorded on the data record it is operating on, if a conflict exists, the wait information is recorded in the context information of the latest transaction, effectively attaching the current transaction to the write lock wait information of the latest transaction. If no conflict exists, no action is required; the transaction can be executed directly and committed or rolled back without requesting any lock resources in the database system. Because the transaction locking scheme abandons the use of a centralized data structure (i.e., a lock manager) to manage lock information, it simplifies the locking logic and the number of locks created, thereby reducing the storage overhead of the native lock manager in maintaining lock information when transaction conflicts are high.

[0120] The above transaction locking scheme is applicable to any database system, such as single-machine database systems and clustered database systems. Clustered database systems include central clustered databases and distributed clustered databases, while distributed clustered databases include distributed database systems, distributed big data processing systems, and distributed database management systems with similar architectures.

[0121] The database system includes multiple computing devices, i.e., computing nodes. Each computing device's database stores one or more data tables, and each data table stores one or more data rows (data records). Each data row consists of a set of fields arranged according to the same index. The database of the computing device can be a relational database or a non-relational database, such as SQL database, MySQL, NoSQL, NewSQL (referring to various new types of scalable / high-performance databases), etc. In this embodiment, the type of database is not specifically limited.

[0122] In some embodiments, the above transaction locking scheme can also be applied to a database system based on blockchain technology (hereinafter referred to as "blockchain system"). The blockchain system is essentially a decentralized distributed database system that uses consensus algorithms to keep the ledger data recorded by different computing devices on the blockchain consistent, uses cryptographic algorithms to ensure the encrypted transmission and immutability of ledger data between different computing devices, uses a script system to extend ledger functions, and uses network routing to connect different computing devices.

[0123] A blockchain system can include one or more blockchains. A blockchain is a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and to generate the next block.

[0124] In a blockchain system, computing devices can form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP). In a blockchain system, any computing device can have the following functions: 1) Routing: A basic function of computing devices used to support communication between them; 2) Applications: Deployed in the blockchain to implement specific business needs, recording data related to the implemented functions to form ledger data. The ledger data carries a digital signature to indicate the data source and is sent to other computing devices in the blockchain system. When other computing devices successfully verify the source and integrity of the ledger data, they add it to a temporary block. The business implemented by the application can include wallets, shared ledgers, smart contracts, etc.; 3) Blockchain: Comprising a series of blocks sequentially arranged in chronological order. Once a new block is added to the blockchain, it is never removed. The blocks record the ledger data submitted by computing devices in the blockchain system.

[0125] In some embodiments, each block may include the hash value of the transaction records stored in this block (the hash value of this block) and the hash value of the previous block. The blocks are connected by hash values ​​to form a blockchain. In addition, the block may also include information such as the timestamp when the block was generated.

[0126] The system architecture of the embodiments of this application will be described below.

[0127] Figure 1 This is a schematic diagram illustrating the implementation environment of a transaction processing method provided in an embodiment of this application. See also... Figure 1 Taking a distributed cluster database system as an example, the distributed cluster database system includes: application client 101, gateway server 102 and distributed storage cluster 103.

[0128] Application client 101 refers to a client installed and running on the user-side terminal that can initiate data requests. These data requests can be DDL (Data Definition Language) requests or DML (Data Manipulation Language) requests, etc., and this application embodiment does not specifically limit the type. Optionally, the type of application client 101 includes, but is not limited to: payment applications, social applications, audio / video applications, live streaming applications, shopping applications, food delivery applications, or ride-hailing applications, etc., and this application embodiment does not specifically limit the type of application client 101. In some embodiments, the user-side terminal is also referred to as user equipment, terminal equipment, user terminal, mobile terminal, smart terminal, communication equipment, etc. Optionally, the device type of the terminal includes: smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, in-vehicle terminals, smart home appliances, smart voice interaction devices, etc., but is not limited to these.

[0129] The application client 101 and the gateway server 102 can be connected directly or indirectly through wired or wireless communication, and this application does not impose any restrictions on this.

[0130] Gateway server 102 receives external data requests and distributes the corresponding read / write transactions to distributed storage cluster 103. For example, a user logs into application client 101 on a terminal, triggering application client 101 to generate a data request. Then, the application client 101 calls the API (Application Programming Interface) provided by the distributed cluster database system to send the data request to gateway server 102. For instance, this API could be the MySQL API (an API provided by a relational database system). In a smart transportation scenario, this data request could be for adding a parking space or for querying existing parking spaces.

[0131] In some embodiments, the gateway server 102 can be merged with any computing device in the distributed storage cluster 103 on the same physical machine, that is, a certain computing device can act as the gateway server 102.

[0132] The distributed storage cluster 103 includes one or more computing devices. For example, the number of computing devices is m, where m is an integer greater than or equal to 1. This embodiment does not specifically limit the number of computing devices in the distributed storage cluster 103. Optionally, each computing device adopts a primary-backup structure (i.e., a one-primary-multiple-backup cluster), such as... Figure 1As shown, taking a computing device cluster with one primary and two backups as an example, each computing device includes one primary and two backup machines. Optionally, each primary or backup machine is configured with an agent device. The agent device can be physically independent of the primary or backup machine. Of course, the agent device can also be a proxy module on the primary or backup machine. Taking computing device 1 as an example, computing device 1 includes a primary database and an agent device (primary database + agent, referred to as primary DB + agent), and also includes two backup databases and agent devices (backup database + agent, referred to as backup DB + agent).

[0133] In an exemplary scenario, the set of database instances of the host or standby machine corresponding to each computing device is called a SET (set). For example, if a computing device is a single-machine device, then the SET of the computing device is only the database instances of that single-machine device. If a computing device is a one-master-two-standby cluster, then the SET of the computing device is the set of the host database instance and the two standby database instances.

[0134] In some embodiments, the distributed cluster database system composed of the gateway server 102 and the distributed storage cluster 103 can be regarded as a server that provides data services to user terminals. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0135] The following section will describe the representation and storage method of lock information in the transaction lock scheme involved in this application embodiment, based on the above implementation environment. The transaction lock scheme does not rely on a global lock manager. For read lock information, a global hash table is used for storage. For write lock information, the hidden field (DB_TRX_ID) containing the transaction number on each data record is reused to represent write lock information. In addition, a hash table is added to the context information of each transaction to represent write lock waiting information (i.e., relevant information of each transaction waiting for the write lock held by this transaction). This is equivalent to distributing the write lock waiting information to the context information of each transaction for maintenance, which can further save storage overhead. The following sections describe how read lock information and write lock information are represented and stored.

[0136] In the InnoDB engine, in addition to the values ​​of its own fields, each data record also contains two hidden fields at the beginning of the record: one is the transaction number (DB_TRX_ID), and the other is the rollback pointer (DB_ROLL_PTR). The storage structure of each data record is shown in Table 1 below:

[0137] Table 1

[0138] DB_TRX_ID DB_ROLL_PTR C1 C2 …

[0139] The transaction number (DB_TRX_ID) field records the transaction identifier (i.e., transaction ID) of the latest transaction that is modifying or has modified this data record. Based on this transaction ID, the transaction status of the latest transaction can be accessed from the list of active transactions in memory. The transaction status can be used to determine whether the latest transaction holds a write lock on the data record. For example, when the transaction status is active, it means that the latest transaction holds a write lock on the data record. Subsequent new transactions must wait for the latest transaction that is modifying the data record to release the write lock before they can perform read and write operations on the data record.

[0140] The rollback pointer (DB_ROLL_PTR) field records a pointer to the Undo Log of the data record, so that when a transaction is rolled back, the data record can be restored to the previous version through the rollback log.

[0141] Among them, fields C1 and C2, as well as the other fields thereafter, are the field values ​​that the data record was originally intended to store. That is, field C1 is used to store the field value of the data record in column C1, field C2 is used to store the field value of the data record in column C2, and so on. This will not be elaborated further.

[0142] In the transaction locking scheme, since the InnoDB engine can indicate the latest transaction that modified the data record by the transaction number (DB_TRX_ID) field on each data record, and the activity status of the latest transaction can reflect whether the data record has been locked by a write lock (if a write lock has been locked, it can be determined that the lock holder is the latest transaction), the transaction number (DB_TRX_ID) field can fully reflect the write lock information of each data record.

[0143] Furthermore, since each transaction initializes its context information in memory upon creation, the transaction locking scheme adds a hash table field (TRX_LOCK_WAIT) to the context information of each transaction to represent the write lock wait information of this transaction. This hash table creates a key-value data structure for all data records operated on by this transaction. For the key-value data structure of each data record, the key is the unique record identifier (i.e., record ID) of the data record, and the value is the various transactions waiting for the write lock held by this transaction on the data record. Therefore, the value is also called the write lock wait queue of the data record. The write lock wait queue contains a series of transaction IDs of transactions waiting for the write lock held by this transaction on the data record.

[0144] Figure 2 This is a logical diagram illustrating write lock wait information provided in an embodiment of this application, such as... Figure 2 As shown, the write lock wait information 200 (i.e., a hash table) acquired by a transaction within its context information is illustrated. For each data record operated on by the transaction, a key-value data structure 210 is created in the hash table. The key stores the record ID of the data record, and the value stores the write lock wait queue for that data record. In one example, key1 stores the record ID of the first data record operated on by the transaction, and the corresponding value on key1 contains the write lock wait queue (denoted as wait_que_write) formed by the transaction IDs of various transactions waiting for the write lock held by this transaction on that first data record.

[0145] In addition, a global hash table (slock_table) is maintained for read lock information. This global hash table, also known as the global read lock information, is used to manage read locks in the database system. Optionally, the global read lock information slock_table also creates a key-value data structure for each data record being read in the entire database system. For each data record's key-value data structure, the key is the unique record identifier (i.e., record ID), and the value contains a queue pair (i.e., two queues). One is the read lock holding queue (hold_que_read), which records the transaction IDs of each transaction holding the read lock for this data record. The other is the read lock waiting queue (wait_que_read), which records the transaction IDs of each transaction waiting for the read lock held by this data record.

[0146] Figure 3 This is a logical diagram of global read lock information provided in an embodiment of this application, such as... Figure 3 As shown, a global read lock information 300 is illustrated. The global read lock information 300 is a global hash table. For each data record being read, a key-value data structure 310 is created in the hash table. The key stores the record ID of the data record, and the value stores the read lock holding queue (hold_que_read) and the read lock waiting queue (wait_que_read) for the data record. In one example, key1 stores the record ID of a data record currently being read in the system. The value corresponding to key1 has two queues attached: one is the read lock holding queue (hold_que_read) formed by the transaction IDs of the transactions holding the read lock for this data record, and the other is the read lock waiting queue (wait_que_read) formed by the transaction IDs of the transactions waiting to hold the read lock for this data record.

[0147] Based on the above, since the database system maintains a global read lock information to record read lock related information, and a hash table field is opened in the context information of each transaction to represent write lock waiting information, the overall read lock information and write lock information in the system can be maintained as a whole without relying on a global lock manager.

[0148] In some embodiments, similar to global read lock information, a global data structure can be used to store write lock wait information, and the global write lock wait information can be partitioned. When locking, the transaction number (DB_TRX_ID) field on the data record is still used to determine the conflict. After a conflict, the transaction that needs to wait is added to the global data structure, and a mutex is added at the partition level. When the transaction is committed and rolled back, the mutex of the corresponding partition is also required. In the following embodiments, the example of distributing the write lock wait information into the context information of each transaction will be used for illustration.

[0149] Having introduced the representation and storage mechanism of lock information in the above transaction locking scheme, this application embodiment will briefly describe the overall transaction processing flow under the transaction locking scheme. Figure 4 This is a flowchart of a transaction processing method provided in an embodiment of this application. See also... Figure 4 This embodiment is executed by an electronic device, which can be a computing device (i.e., a computing device, SQL engine) or a storage device (i.e., a storage node, i.e., a storage engine) in the database system. Here, we take the electronic device as a computing device as an example for illustration. This embodiment includes the following steps:

[0150] 401. The computing device determines the latest transaction that modified the data record based on the data record operated on by the target transaction.

[0151] The target transaction is obtained based on data request parsing. The data request includes DDL request and DML request. DML request refers to business request. For example, a query request is a typical business request. In the financial scenario, the query request is to query the balance, query the transaction history, etc. In the smart transportation scenario, the query request is to query the nearby available parking spaces, query the traffic conditions near the destination, etc. This application embodiment does not specifically limit the content of the data request.

[0152] In some embodiments, the data request is sent by the user to the database system through an application client. For example, the user logs into the application client on a terminal, triggering the application client to generate the data request, and then calls the MySQL API to send the data request to the MySQL database system. For instance, the MySQL database system is a single-machine database system containing only the computing device, or the MySQL database system is as described above. Figure 1 The distributed database system shown in the implementation environment is a computing device, which is a computing node in a distributed storage cluster. This application does not specifically limit this aspect.

[0153] In some embodiments, after receiving any message, the computing device parses the header field of the message. When the header field indicates that the message is a data request, it parses the data field of the data request to obtain the SQL statement of the target transaction corresponding to the data request (or, the data request may also be a NoSQL request, in which case what is parsed is usually an access to a certain Key-Value data structure).

[0154] Next, based on the SQL statement of the target transaction, determine one or more data records operated on by the target transaction. The "operation" of the target transaction on the data record refers to database operation. The types of database operation include read operation and write operation, which are collectively referred to as read-write operation.

[0155] Since a target transaction is usually composed of a sequence of database operations, that is, the target transaction may involve multiple database operations, which may also point to the same or different data records. For example, the target transaction involves reading version V1 of data record R1 and modifying data record R2 from version V1 to version V2. Under the traditional locking mechanism, in order to avoid inconsistencies caused by read-write conflicts between concurrent transactions, the target transaction usually needs to send a lock request to the global lock manager to request a read lock on data record R1 and a write lock on data record R2.

[0156] In this embodiment of the application, a transaction locking scheme is provided. Since it does not rely on a global lock manager, the computing device only needs to perform lock request conflict detection on each data record involved in the operation of the target transaction in the manner described in step 402 below to identify the target transaction that actually has a conflict. If the target transaction finds that there is actually no conflict in the conflict detection, then there is no need to add unnecessary row locks to these data records. If the target transaction finds that there is a conflict in the conflict detection, then it is necessary to actually request a lock on the corresponding data record that corresponds to the operation type. For example, if the target transaction involves reading the data record, it requests a read lock; if the target transaction involves modifying the data record, it requests a write lock.

[0157] Optionally, in the InnoDB engine, since each data record contains a target hidden field, which is also the transaction number (DB_TRX_ID) field, the computing device can read the transaction ID of the latest transaction that modified the data record from the target hidden field of each data record operated on by the target transaction. This transaction ID can uniquely identify the latest transaction that modified the data record. The transaction status of this latest transaction can indicate the write lock information of the data record. This is because if a write lock is added to the data record, it can only be a write lock added by the latest transaction. If the transaction status of the latest transaction is active, it means that the latest transaction holds the write lock on the data record. If the transaction status of the latest transaction is not active, it means that no write lock has been added to the latest transaction.

[0158] 402. The computing device performs lock request conflict detection on the target transaction based on global read lock information and write lock wait information of the latest transaction. The global read lock information is used to manage read locks in the database system, and the write lock wait information is used to record each transaction waiting for the write lock held by the latest transaction.

[0159] Because the global read lock information records relevant information about read locks throughout the entire database system, including which transactions currently hold read locks on each data record being read, and which transactions are waiting for the lock holder to release the read lock, global read lock information can be used to detect read lock conflicts for a new target transaction.

[0160] Furthermore, after identifying the latest transaction modifying the data record in step 401 above, the transaction ID of the latest transaction can be used as an index to query the transaction state (e.g., a State parameter) of the latest transaction in the database system's active transaction list (maintained in memory, usually in the form of a linked list). If the transaction state of the latest transaction is active (State = Active), it means that the latest transaction holds a write lock on the data record. If the transaction state of the latest transaction is not active (State ≠ Active), it means that no write lock has been added to the data record. In addition, as previously described in the embodiments of this application, in the transaction locking scheme, a hash table field is added to the transaction context information during the initialization phase of each transaction creation to represent the write lock waiting information of the transaction, that is, to record which transactions are waiting for write locks on the data record modified by the transaction. Therefore, for a newly arrived target transaction, the write lock conflict detection of the target transaction can be completed by using the transaction ID (DB_TRX_ID) field recorded on the data record involved in its operation, which indicates the transaction state of the latest transaction, and the write lock wait information maintained by the latest transaction itself in the context information.

[0161] In some embodiments, regardless of whether the target transaction performs a read operation or a write operation on the data record, read lock conflict detection and write lock conflict detection are required separately. Only when both read lock conflict detection and write lock conflict detection pass (i.e., there is no read lock conflict or write lock conflict) is the target transaction considered to have passed the conflict detection and there is no conflict. Then the target transaction is executed directly, and after execution, it enters the verification stage to determine whether to commit or roll back the target transaction. That is, for cases where there is no conflict, there is no need to maintain any lock information, which can greatly reduce the number of locks created by the database system in high-concurrency scenarios. For some unnecessary row locks, by identifying that there is no conflict, there is no need to create and maintain these unnecessary row locks, thereby saving the memory overhead caused by lock information.

[0162] Furthermore, if a read lock conflict occurs when the read lock conflict detection fails, or a write lock conflict occurs when the write lock conflict detection fails, the target transaction needs to enter the lock waiting phase. That is, it needs to wait for the lock holder that already holds the lock on the data record to release the lock resource before the target transaction can queue up to apply for adding a lock on the data record. At this time, it is necessary to maintain some read lock waiting information or write lock waiting information so that after the lock holder that already holds the lock on the data record releases the lock resource, one or more waiting transactions can be woken up.

[0163] In the above process, read lock conflict detection and write lock conflict detection are required for any type of target transaction, providing relatively complete conflict detection logic. However, considering that read locks are shared locks rather than exclusive locks, if the target transaction performs a read operation on the data record, then regardless of whether a read lock already exists on that data record, the target transaction can share the existing read lock. This means that read lock conflict detection will pass no matter what (i.e., there can be no read lock conflict). In this case (referring to the situation where the target transaction requests a read lock on the data record), it is unnecessary to perform read lock conflict detection.

[0164] In other words, the computing device determines the lock type that the target transaction needs to request for the data record based on the type of database operation involved in the target transaction. Then, if the lock type is a read lock, there is no need to perform read lock conflict detection, only write lock conflict detection is required; only if the lock type is a write lock is it necessary to perform both read lock conflict detection and write lock conflict detection. This simplifies the conflict detection process and further avoids resource waste.

[0165] For example, suppose transaction T1 involves reading data record R1 and transaction T2 involves modifying data record R2. Then, the lock type that transaction T1 needs to request on data record R1 is a read lock, so only write lock conflict detection needs to be performed on transaction T1. The lock type that transaction T2 needs to request on data record R2 is a write lock, so both read lock conflict detection and write lock conflict detection need to be performed on transaction T2.

[0166] 403. If a conflict is detected in the conflict detection indication, the computing device requests to add a lock to the data record that corresponds to the operation type of the operation.

[0167] In some embodiments, after performing lock request conflict detection on the target transaction through the above-described 402, a conflict detection result can be obtained. For example, the conflict detection result is a return value, which is used to indicate whether there is a conflict between the lock to be requested by the target transaction on the data record and an existing lock on the data record.

[0168] Optionally, the return value can be a binary data value. When the binary data value is 1, it means that there is a conflict and the conflict detection has failed. When the binary data value is 0, it means that there is no conflict and the conflict detection has passed.

[0169] Optionally, the return value can be a boolean value. When the boolean value is True, it means that there is a conflict and the conflict detection failed; when the boolean value is False, it means that there is no conflict and the conflict detection passed.

[0170] In some embodiments, when the return value indicates a conflict, the conflict detection is considered to have failed. In this case, the target transaction needs to wait for the existing lock on the data record to be released before it can perform its own database operations on that data record. Only in this situation is it necessary to request a lock of the corresponding operation type for the data record. Since there is a conflict between the lock requested and the existing lock, the target transaction cannot immediately obtain the lock and will actually enter the lock waiting phase. Conversely, when the return value indicates no conflict, the task conflict detection passes, indicating that the lock requested by the target transaction on the data record does not actually conflict and is therefore an unnecessary row lock. In this case, it is only necessary to directly execute and commit (or rollback) the target transaction without creating or maintaining any lock information. Of course, in order to ensure that the conflict detection of other newly arrived transactions does not fail, it is only necessary to update some existing parameters. For example, when the target transaction modifies the data record, the transaction ID of the target transaction needs to be written to the transaction number (DB_TRX_ID) field of the data record.

[0171] The following analysis focuses on high-concurrency scenarios. When there are no conflicts between concurrent transactions (i.e., conflict detection passes), the transaction locking scheme does not require creating any lock information for the target transaction, greatly saving the maintenance and storage overhead of lock information. When the conflicts between concurrent transactions are low, but the number of data records updated by a single transaction is large, the transaction locking scheme greatly reduces the number of locks created in the entire database system, thereby significantly reducing memory usage. When the conflicts between concurrent transactions are high, the transaction locking scheme simplifies the locking logic of the native InnoDB engine row locks, avoiding the time consumed by the native locking logic of acquiring the mutex of the global lock manager regardless of whether there is a conflict, thus significantly improving the transaction processing performance within the database system.

[0172] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0173] The method provided in this application records relevant information about read locks in the database system through global read lock information. By modifying the latest transaction of each data record, it can determine whether a write lock exists on that data record and the lock holder of the write lock. Furthermore, the write lock wait information is scattered and stored in the context information of each transaction. This allows the read-write conflict detection of the entire database system to be independent of the lock manager and does not require accessing the mutex every time. After completing the conflict detection using global read lock information and the write lock wait information of the latest transaction corresponding to the data record to be operated on, the corresponding lock information can be requested only for cases where there is a conflict. For cases where there is no conflict, there is no need to consume resources to maintain the lock information. This can greatly reduce the creation of unnecessary row locks in the system, thereby saving the storage overhead and memory usage of concurrency control under the lock mechanism.

[0174] In the previous embodiment, the overall concurrency control strategy of the transaction lock scheme involved in this application embodiment was briefly introduced. In this application embodiment and the next embodiment, the overall conflict detection process will be introduced for two cases: the target transaction requests a read lock on the data record and the target transaction requests a write lock on the data record. The following is an explanation.

[0175] Figure 5 This is a flowchart of a transaction processing method provided in an embodiment of this application, such as... Figure 5 As shown, this embodiment is executed by an electronic device, which can be a computing device (i.e., a computing device, SQL engine) or a storage device (i.e., a storage node, i.e., a storage engine) in a database system. Here, we take the electronic device as a computing device as an example for illustration. This embodiment includes the following steps:

[0176] 501. The computing device determines the latest transaction that modified the data record based on the data record operated on by the target transaction.

[0177] Step 501 is similar to step 401 above, and will not be described in detail here.

[0178] 502. The computing device determines the lock type to be requested for the target transaction based on the operation type of the operation.

[0179] In some embodiments, when the operation type of the target transaction performing on the data record (i.e., the database operation) is a read operation, the lock type to be requested by the target transaction on the data record is determined to be a read lock; when the operation type of the target transaction performing on the data record (i.e., the database operation) is a write operation, the lock type to be requested by the target transaction on the data record is determined to be a write lock.

[0180] In this embodiment, only the case where the target transaction requests a read lock on the data record is described, including the conflict detection process, the lock request process in case of conflict, and the lock release process after transaction commit. The case where the target transaction requests a write lock on the data record will be described in detail in the next embodiment and will not be repeated here.

[0181] 503. When the lock type is a read lock, the computing device obtains the transaction status of the latest transaction.

[0182] When the lock type is a read lock, only write lock conflict detection is needed for the target transaction. This is because regardless of whether there are elements in the read lock holding queue (hold_que_read) and read lock waiting queue (wait_que_read) of the key-value data structure of the data record in the global read lock information (slock_table), the read lock conflict detection will pass. Therefore, even if there are elements in the read lock waiting queue (wait_que_read) (i.e., there are waiting transactions), since the read lock requested by the target transaction is a shared lock, the read lock on the data record can still be successfully requested, indicating that there is no read lock conflict. That is, the read lock conflict detection passes by default, so there is no need to perform read lock conflict detection. When requesting a read lock, only write lock conflict detection is performed, and the detection result of the write lock conflict detection is used as the overall conflict detection result.

[0183] In some embodiments, after the latest transaction that modifies the data record is determined in step 501 above, the transaction status (e.g., a State parameter) of the latest transaction can be obtained by querying the active transaction list of the database system (maintained in memory, usually in the form of a linked list) using the transaction ID of the latest transaction as an index, and then proceed to step 504 below.

[0184] 504. The computing device determines the conflict detection result based on the transaction status of the latest transaction.

[0185] To illustrate, the conflict detection result is a return value indicating whether a conflict exists. For example, the return value could be binary data; a value of 1 indicates a conflict exists and the conflict detection failed, while a value of 0 indicates no conflict exists and the conflict detection passed. Alternatively, the return value could be a boolean value; a value of True indicates a conflict exists and the conflict detection failed, while a value of False indicates no conflict exists and the conflict detection passed.

[0186] In some embodiments, if the transaction state of the latest transaction is not active (i.e., the State of the latest transaction is not active), it means that no write lock has been added to the data record. In this case, the target transaction does not need to wait for any transaction to release the lock resource. Therefore, the conflict detection result is determined to be that there is no conflict. Taking the conflict detection result as the return value, the binary data of the return value is configured to 0, or the boolean data of the return value is configured to False.

[0187] Optionally, to ensure that conflict detection for subsequent transactions is error-free, in the absence of conflicts, it is also necessary to query the read lock holding queue of the data record in the global read lock information, using the record identifier of the data record as an index. This global read lock information manages read locks in the database system, and the read lock holding queue records the various transactions holding read locks on the data record. Next, it is determined whether the target transaction is present in the read lock holding queue. If the target transaction is present in the queue, it is directly executed and committed (or rolled back). If the target transaction is not present in the queue, it is added to the read lock holding queue.

[0188] In an exemplary scenario, since the global read lock information is a sheet like... Figure 3 The global hash table slock_table, as shown, contains global read lock information. For each data record being read in the entire database system, a key-value data structure is created. For each data record's key-value data structure, the key is the unique record identifier (i.e., record ID), and the value contains a queue pair (i.e., two queues). One is the read lock holding queue (hold_que_read), which records the transaction IDs of each transaction holding the read lock for this data record. The other is the read lock waiting queue (wait_que_read), which records the transaction IDs of each transaction waiting for the read lock held by this data record. Therefore, for the non-conflict situation described above, it is only necessary to use the record ID of the data record operated by the target transaction as an index, query the key-value data structure hit by the index in the global read lock information slock_table, and then access the read lock holding queue (hold_que_read) stored in the value of the hit key-value data structure. It is then determined whether the read lock holding queue (hold_que_read) already contains the transaction ID of the target transaction. If the read lock holding queue (hold_que_read) already contains the transaction ID of the target transaction, the target transaction can be directly executed and committed (or rolled back). If the read lock holding queue (hold_que_read) does not contain the transaction ID of the target transaction, the transaction ID of the target transaction is added to the read lock holding queue (hold_que_read).

[0189] In some embodiments, if the transaction state of the latest transaction is active (i.e., the latest transaction's State = Active), it means that the latest transaction holds a write lock on the data record. This indicates that a conflict has occurred between the read lock that the target transaction intends to request on the data record and the write lock that the latest transaction is currently holding on the data record. Therefore, the conflict detection result is determined to be a conflict. Taking the conflict detection result as the return value as an example, the binary data of the return value is configured as 1, or the boolean data of the return value is configured as True.

[0190] Optionally, to avoid data anomalies caused by read-write conflicts, the later target transaction needs to wait for the latest transaction to release the lock resource on the data record before attempting to acquire a new write lock on that data record (i.e., attempting to acquire a new write lock on the data record). However, since there may be other transactions waiting for the latest transaction before the target transaction, write lock wait information needs to be maintained for the latest transaction to record which transactions are waiting for write locks held by the latest transaction on which data records. This allows for a decision on whether to wake up one or more transactions waiting for the latest transaction after the latest transaction commits. In the transaction locking scheme, during the initialization phase when each transaction is created, a hash table field is added to the transaction's context information to represent the transaction's write lock wait information, that is, to record which transactions are waiting for write locks on the data records modified by the transaction.

[0191] Therefore, in the event of a conflict, the target transaction needs to be added to the write lock wait information of the latest transaction. Optionally, the computing device can access the context information of the latest transaction in memory based on its transaction ID, and query the hash table field containing the write lock wait information within that context information to access the write lock wait information. This write lock wait information records all transactions waiting for the write lock held by the latest transaction. Since the latest transaction may operate on multiple data records, and different transactions waiting for the latest transaction may be waiting for lock resources on different data records, a write lock wait queue is maintained for each data record operated on by the latest transaction within the write lock wait information. In other words, the write lock wait information of the latest transaction includes the write lock wait queue for each data record operated on by the latest transaction, and each data record's write lock wait queue records all transactions waiting for the write lock held by the latest transaction on the corresponding data record. Next, the computing device adds the target transaction to the write lock wait queue of the data record operated on by the target transaction within the write lock wait information of the latest transaction.

[0192] In an exemplary scenario, the write lock wait information maintained for the latest transaction is as follows: Figure 2As shown, the computing device accesses the hash table field (TRX_LOCK_WAIT) in the context information of the latest transaction to access the write lock wait information of the latest transaction. Next, using the record ID of the data record operated on by the target transaction as an index, it queries the key-value data structure that the index hits in the write lock wait information. Then, it accesses the write lock wait queue (wait_que_write) stored in the value of the hit key-value data structure and adds the transaction ID of the target transaction to the write lock wait queue (wait_que_write).

[0193] Furthermore, in the event of a conflict, in addition to adding the target transaction to the write lock wait information of the latest transaction, the computing device also sets the blocking transaction parameter (blocking_trx) of the target transaction to the transaction identifier of the latest transaction. The blocking transaction parameter (blocking_trx) is used to characterize the transaction that the target transaction is waiting for. That is, it is equivalent to setting the blocking_trx of the target transaction to the transaction ID of the latest transaction, indicating that the target transaction is waiting for the latest transaction. In this way, the deadlock detection process of the entire database system can be executed by using the blocking transaction parameter (blocking_trx) of each transaction, so as to promptly detect transactions trapped in deadlock within the system.

[0194] 505. If the conflict detection result indicates a conflict, the computing device requests to add a read lock to the data record that corresponds to the operation type of the operation.

[0195] Step 505 is similar to step 403. That is, if the conflict detection result indicates a conflict, although the target transaction attempts to request the lock resource on the data record, the conflict causes the target transaction to enter the lock waiting phase. This means that the target transaction must wait for the latest transaction to release the write lock it holds on the data record before it can queue up to request a new read lock on the data record. After the target transaction is in the queue and the lock request is successful, the target transaction executes and commits (or rolls back), then releases the read lock it has requested, and wakes up the next transaction that requests to perform operations on the data record (of course, since the read lock is a shared lock, there may be other transactions holding the read lock that have not finished reading after the target transaction finishes reading, in which case there is no need to wake up the transaction). The relevant process will be explained in steps 507 to 508-A or 508-B or 508-C below, and will not be repeated here.

[0196] In some embodiments, step 505 above involves the computing device requesting a lock if the conflict detection result indicates a conflict exists, while if the conflict detection result indicates no conflict exists, the computing device does not need to maintain any lock information and can directly proceed to step 506 below to execute the target transaction.

[0197] 506. After the target transaction successfully adds a lock to the data record, the computing device executes the target transaction.

[0198] In this embodiment of the application, a read lock is requested for the data record. After the read lock request for the data record is successful, the target transaction reads the data record, that is, performs a read operation on the data record, for example, reads the latest visible variable version of the data record.

[0199] In some embodiments, since the target transaction may be a sequence of database operations, the target transaction may involve operations on multiple data records. Only after the target transaction has completed the corresponding database operations on each data record can it enter the verification phase of the target transaction, that is, verify whether the target transaction can be committed. If a data anomaly is found, the verification fails and the target transaction needs to be rolled back. If no data anomaly is found, the target transaction can be committed.

[0200] It should be noted that when the target transaction involves operations on multiple data records and the operation types for different data records are different, for read operations, the method of this application embodiment is used for conflict detection, and the read operation is performed on the corresponding data record when the lock is successfully acquired (or the lock is not acquired through conflict detection). For write operations, the method of the next embodiment is used for conflict detection, and the write operation is performed on the corresponding data record when the lock is successfully acquired (or the lock is not acquired through conflict detection). Only after all the data records operated on by the target transaction have completed the corresponding operations can the target transaction enter the verification phase and the commit phase (or rollback phase). This will not be elaborated here.

[0201] 507. After the target transaction is committed, the computing device queries the read lock holding queue of the data record in the global read lock information, using the record identifier of the data record as an index.

[0202] The read lock holding queue is used to record the various transactions that hold the read locks for the data record.

[0203] In some embodiments, if the target transaction passes the verification and is successfully committed, it is also necessary to update and modify some information related to the read lock in order to release the read lock that the target transaction has applied for on the data record, and to determine whether it is necessary to wake up the next waiting transaction that needs to perform an operation on the data record. Of course, since the read lock is a shared lock, after the target transaction has completed the read operation on the data record and committed, there may be other transactions holding the read lock that have not finished reading or have not yet committed. In this case, there is no need to wake up the transaction.

[0204] In some embodiments, after the target transaction is committed, the record ID of the data record operated on (i.e. read) by the target transaction is used as an index to query the Key-Value data structure hit by the index in the global read lock information slock_table. Then, the read lock holding queue (hold_que_read) stored in the Value of the Key-Value data structure hit by the index is accessed. Next, it is determined whether the read lock holding queue (hold_que_read) is empty. If the read lock holding queue (hold_que_read) is empty, proceed to step 508-A below. If the read lock holding queue (hold_que_read) is not empty, it is further determined whether the number of elements in the read lock holding queue (hold_que_read) is 1. If the number of elements in the read lock holding queue (hold_que_read) is 1, then it is also necessary to access the Key-Value data structure hit by the index. The `Value` element of the `alue` data structure stores a read lock waiting queue (`wait_que_read`). It checks if the unique element (which must be a transaction ID) in the `hold_que_read` is exactly the first element of the `wait_que_read`. If so, it means the first waiting transaction in the `wait_que_read` holds the only read lock, and thus this transaction can be woken up, proceeding to step 508-B. Otherwise, if none of the above conditions are met—for example, if the number of elements in the `hold_que_read` is greater than 1, or if the number of elements in the `hold_que_read` is 1 but this element is not the first element of the `wait_que_read`—then no waiting transaction needs to be woken up, and proceeding to step 508-C.

[0205] 508-A: If the read lock holding queue is empty, the computing device wakes up the first transaction in the read lock waiting queue of the data record.

[0206] The read lock wait queue is used to record the various transactions that are waiting to hold read locks on the data record.

[0207] In some embodiments, if the read lock holding queue (hold_que_read) of the data record is empty, it means that no transaction currently holds a lock on the data record. Therefore, it is necessary to wake up the first transaction in the read lock waiting queue (wait_que_read) of the data record. That is, access the transaction ID recorded in the first element of the read lock waiting queue (wait_que_read) of the data record, and then wake up the transaction indicated by the transaction ID (i.e., the first transaction in the read lock waiting queue).

[0208] Obviously, since read locks are shared locks, if a transaction is added to the read lock wait queue (wait_que_read) of a data record, then this transaction must be requesting a write lock on that data record. This is because if a read lock is requested and there is no conflict, the request can be successful directly. Therefore, the first transaction in the read lock wait queue (wait_que_read) that is woken up in step 508-A must be a write transaction (i.e., it is requesting a write lock and will definitely perform a write operation on that data record). Therefore, for the transaction woken up by the target transaction (referred to as the woken transaction, which in the case of step 508-A refers to the first transaction in the read lock wait queue), the write lock wait information of the woken transaction needs to add all transactions in the read lock wait queue (wait_que_read) except for the woken transaction to the write lock wait queue (wait_que_write) of that data record.

[0209] In other words, for the first transaction in the read lock wait queue (wait_que_read) awakened by the target transaction, the hash table field (TRX_LOCK_WAIT) in the context information of the first transaction needs to be accessed in memory based on the transaction ID of the first transaction to access the write lock wait information of the first transaction. Next, using the record ID of the operation record corresponding to the read lock wait queue (wait_que_read) as an index, the key-value data structure hit by the index is queried in the write lock wait information. Then, the write lock wait queue (wait_que_write) stored in the value of the hit key-value data structure is accessed, and all remaining transaction IDs in the read lock wait queue (wait_que_read) are attached to the write lock wait queue (wait_que_write). Since the awakened transaction is the first transaction, all remaining transaction IDs refer to the transaction IDs stored in the second and subsequent elements of the read lock wait queue (wait_que_read).

[0210] Furthermore, since the target transaction has already been committed, the object that each transaction newly added to the write lock waiting queue (wait_que_write) is waiting for has changed (i.e., it was originally waiting for the target transaction, but now that the target transaction has committed and woken up the first transaction, it is now waiting for the first transaction). In order to avoid deadlock detection errors and to prevent the blocking transaction parameter (blocking_trx) of each transaction added to the write lock waiting queue (wait_que_write) from recording the transaction ID of the target transaction that has already been committed, the blocking transaction parameter (blocking_trx) of these remaining waiting transactions is also updated.

[0211] Optionally, after all remaining transaction IDs in the read lock wait queue (wait_que_read) are attached to the write lock wait queue (wait_que_write), the computing device sets the blocking transaction parameter (blocking_trx) of any transaction added to the write lock wait queue (wait_que_write) to the transaction identifier of the awakened transaction. The blocking transaction parameter (blocking_trx) is used to characterize the transaction that the transaction is waiting for. That is, it is equivalent to setting the blocking_trx of the transaction to the transaction ID of the first transaction in the awakened read lock wait queue (wait_que_read), indicating that these remaining waiting transactions are now waiting for the awakened first transaction, thereby ensuring the correctness of the database system deadlock detection.

[0212] 508-B. If the read lock holding queue contains only a single transaction, and that transaction happens to be the first transaction in the read lock waiting queue, the computing device wakes up the transaction.

[0213] In some embodiments, if the number of elements in the read lock holding queue (hold_que_read) of the data record is 1, and the unique element in the read lock holding queue (hold_que_read) (which must be a transaction ID) is exactly the first element in the read lock waiting queue (wait_que_read), in other words, the read lock holding queue (hold_que_read) contains only a single transaction, and the first transaction waiting in the read lock waiting queue (wait_que_read) happens to hold this unique read lock, then this transaction can obviously inherit this read lock, and at this time the transaction can be woken up (that is, the unique transaction contained in the read lock holding queue is also equal to the first transaction in the read lock waiting queue).

[0214] The method of waking up the transaction in step 508-B is similar to the method of waking up the transaction in step 508-A above, and will not be described in detail here.

[0215] Similarly, for the transaction that is woken up in step 508-B, it is also necessary to add all transactions other than the one that is woken up to the write lock wait queue of the data record in the write lock wait information of the woken transaction. That is, update the write lock wait information of the woken transaction. The way to add transactions to the write lock wait queue is similar to step 508-A above, and will not be repeated here.

[0216] Similarly, for the transactions added from the read lock waiting queue to the wake-up transactions corresponding to the write lock waiting queue, it is also necessary to set the blocking transaction parameter of any transaction added to the write lock waiting queue to the transaction identifier of the wake-up transaction. The blocking transaction parameter is used to represent the transaction that the transaction is waiting for, that is, to update the blocking transaction parameters of the remaining waiting transactions. The way to update the blocking transaction parameter is similar to step 508-A above, and will not be repeated here.

[0217] 508-C, or otherwise, if 508-A or 508-B is not satisfied, the computing device sets the blocking transaction parameter of each transaction in the read lock waiting queue to the transaction identifier of the first transaction in the read lock holding queue other than the current transaction.

[0218] The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0219] In some embodiments, if the number of elements in the read lock holding queue (hold_que_read) is greater than 1, or if the number of elements in the read lock holding queue (hold_que_read) is 1 but this element is not the first element in the read lock waiting queue (wait_que_read), then neither 508-A nor 508-B is satisfied. In this case, it is not necessary to wake up any waiting transactions. It is only necessary to update the blocking transaction parameters (blocking_trx) of each transaction in the read lock waiting queue (wait_que_read) of this data record in the global read lock information. In other words, it is necessary to ensure that the blocking transaction parameters (blocking_trx) of each transaction in the read lock waiting queue (wait_que_read) are not the transaction identifier of the target transaction that has been committed after the update.

[0220] To illustrate, after the target transaction is committed, if it is determined that neither 508-A nor 508-B is satisfied, the computing device iterates through each transaction in the read lock waiting queue (wait_que_read) and sets the blocking transaction parameter (blocking_trx) of that transaction to the transaction ID of the first transaction in the read lock holding queue (hold_que_read) that is not equal to itself. This ensures that these waiting transactions will no longer wait for the committed target transaction, and also ensures that these waiting transactions will not wait for themselves (e.g., transaction A waiting for transaction A), which could lead to a deadlock. This ensures the correctness of the database system's deadlock detection.

[0221] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0222] The method provided in this application, when a target transaction requests a read lock on a data record, only performs write lock conflict detection on the target transaction. This write lock conflict detection does not rely on the lock manager, nor does it require accessing the mutex every time, which can speed up the lock request process. Furthermore, the corresponding lock information is only requested to be created when a conflict exists and the write lock conflict detection fails. For cases where there is no conflict, there is no need to consume resources to maintain lock information, which can greatly reduce the creation of unnecessary row locks in the system, thereby saving storage overhead and memory usage for concurrency control under the lock mechanism.

[0223] In the previous embodiment, it was introduced that when the target transaction requests a read lock on a data record, only the write lock conflict detection logic is executed, and the lock release logic is introduced that the acquired read lock is released after the target transaction is committed. In this embodiment, it will be described in detail that when the target transaction requests a write lock on a data record, both read lock conflict detection and write lock conflict detection are performed, and the lock release logic that releases the acquired write lock after the target transaction is committed will also be described. The following is an explanation.

[0224] Figure 6 This is a flowchart of a transaction processing method provided in an embodiment of this application, such as... Figure 6 As shown, this embodiment is executed by an electronic device, which can be a computing device (i.e., a computing device, SQL engine) or a storage device (i.e., a storage node, i.e., a storage engine) in a database system. Here, we take the electronic device as a computing device as an example for illustration. This embodiment includes the following steps:

[0225] 601. The computing device determines the latest transaction that modifies the data record based on the data record operated on by the target transaction.

[0226] Step 601 is similar to step 501 above, and will not be described in detail here.

[0227] 602. The computing device determines the lock type to be requested for the target transaction based on the operation type of the operation.

[0228] Step 602 is similar to step 502 above, and will not be described in detail here.

[0229] In this embodiment, only the case where the lock type to be requested by the target transaction for the data record is a write lock is described, the conflict detection process, the lock request process in the case of conflict, and the lock release process after the transaction is committed are described. In this case, the computing device needs to perform read lock conflict detection and write lock conflict detection on the target transaction.

[0230] 603. When the lock type is a write lock, the computing device performs read lock conflict detection on the target transaction.

[0231] In some embodiments, when performing read lock conflict detection, a method such as... Figure 3 The global read lock information slock_table in the form of a hash table is used to implement read lock conflict detection. The data structure of the global read lock information slock_table has been introduced in the previous embodiment and will not be repeated here.

[0232] Optionally, during the read lock conflict detection process, the computing device queries the read lock holding queue of the data record in the global read lock information, using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction holding the read lock of the data record. In other words, the computing device queries the key-value data structure that is hit by the index in the global read lock information slock_table, using the record ID of the data record operated by the target transaction as an index, and then accesses the read lock holding queue (hold_que_read) stored in the value of the hit key-value data structure.

[0233] Regarding the read lock holding queue (hold_que_read) of the data record accessed above, if the read lock holding queue (hold_que_read) is empty, that is, the read lock holding queue (hold_que_read) has no elements, proceed to case 1 below; if the read lock holding queue (hold_que_read) is not empty, there are two cases: 2-1 and 2-2. If the read lock holding queue (hold_que_read) contains only one transaction and this transaction is the target transaction itself, proceed to case 2-1; if the read lock holding queue (hold_que_read) contains more than one transaction, or the read lock holding queue (hold_que_read) contains only one transaction but this transaction is not the target transaction itself, proceed to case 2-2. The read lock conflict detection logic for each case will be introduced below.

[0234] Case 1: The read lock holding queue (hold_que_read) is empty.

[0235] That is, there are no elements in the read lock holding queue (hold_que_read). At this time, the read lock waiting queue (wait_que_read) stored in the Value of the Key-Value data structure matched by the record ID of this data record will definitely not have any waiting transactions. The return indicates that there is no read lock conflict, which means that the read lock conflict detection is passed. Proceed to step 605 below to enable write lock conflict detection.

[0236] Case 2-1: The read lock holding queue (hold_que_read) contains only the target transaction.

[0237] This situation 2-1 is equivalent to: the read lock holding queue (hold_que_read) contains only one transaction and this transaction is the target transaction itself. In this case, it is equivalent to the read lock holding queue (hold_que_read) containing only the target transaction. At this time, the computing device needs to continue to query the read lock waiting queue (wait_que_read) stored in the Value of the Key-Value data structure that matches the record ID of this data record. The read lock waiting queue (wait_que_read) is used to record each transaction waiting for the read lock held on this data record.

[0238] Next, if the read lock waiting queue (wait_que_read) is empty, it means that there are no waiting transactions recorded in the read lock waiting queue (wait_que_read). This means that the target transaction has requested a write lock and also holds the only read lock on this data record. Therefore, the target transaction can obviously inherit this read lock, thus returning that there is no read lock conflict, indicating that the read lock conflict detection has passed, and proceeding to step 605 below to enable write lock conflict detection.

[0239] Furthermore, if the read lock waiting queue (wait_que_read) is not empty, it means that there are other transactions waiting for the read lock on this data record. In this case, the target transaction cannot inherit this read lock. The target transaction needs to wait for a transaction in the read lock waiting queue (wait_que_read) to commit or roll back before it can hold the write lock it requested. Therefore, a read lock conflict is returned, indicating that the read lock conflict detection fails, and proceed to step 604 below.

[0240] In the case where the read lock wait queue (wait_que_read) is not empty, since the target transaction needs to wait to enter the lock wait phase, it is also necessary to add the target transaction to the read lock wait queue of the data record. In other words, the transaction ID of the target transaction is inserted into the currently accessed, non-empty read lock wait queue (wait_que_read).

[0241] Furthermore, since the target transaction is requesting a write lock on this data record, indicating that it is a write transaction, it maintains its own write lock wait information in its transaction context information in memory. At this point, the computing device also needs to add all transactions indicating that are waiting for the target transaction, as indicated in the write lock wait information, to the read lock wait queue (wait_que_read). In other words, the computing device accesses the hash table field (TRX_LOCK_WAIT) in the target transaction's own context information to access the target transaction's write lock wait information. Next, using the record ID of the data record operated on by the target transaction as an index, the device queries the key-value data structure that the index hits in the write lock wait information, then accesses the write lock wait queue (wait_que_write) stored in the value of the hit key-value data structure. Finally, the entire write lock wait queue (wait_que_write) is attached to the read lock wait queue (wait_que_read) of this data record in the global read lock information slock_table. The above process is equivalent to determining, based on the write lock wait queue (wait_que_write) of the data record in the write lock wait information of the target transaction, each transaction waiting for the write lock requested by the target transaction on the data record, and then adding each transaction waiting for the write lock requested by the target transaction on the data record to the read lock wait queue (wait_que_read).

[0242] Furthermore, after attaching the target transaction's own transaction ID and the target transaction's entire write lock wait queue (wait_que_write) for that data record to the data record's read lock wait queue (wait_que_read), it is necessary to update the blocking transaction parameter (blocking_trx) of any transaction added to the read lock wait queue (wait_que_read) (including the target transaction and each transaction in the target transaction's write lock wait queue). The blocking transaction parameter (blocking_trx) is used to represent the transaction that the transaction is waiting for.

[0243] The above-mentioned method of updating the blocking transaction parameter (blocking_trx) includes setting the blocking transaction parameter (blocking_trx) of each transaction to the transaction ID of the first transaction in the read lock holding queue (hold_que_read) other than the current transaction. In other words, setting the blocking_trx of the transaction to the transaction ID of the first transaction in the read lock holding queue (hold_que_read) that is not equal to itself indicates that these new transactions attached to the read lock waiting queue (wait_que_read) are all waiting for the read lock that already exists on the data record. It also ensures that these transactions will not wait for themselves (e.g., transaction A waiting for transaction A) and thus cause a deadlock, thereby ensuring the correctness of the database system's deadlock detection.

[0244] Case 2-2: The read lock holding queue (hold_que_read) contains transactions other than the target transaction.

[0245] This situation 2-2 is equivalent to: the read lock holding queue (hold_que_read) contains more than one transaction, or the read lock holding queue (hold_que_read) contains only one transaction but this transaction is not the target transaction itself.

[0246] In scenario 2-2 above, the target transaction also needs to wait for all transactions other than itself in the read lock holding queue (hold_que_read) to release their existing read locks before it can hold the write lock it is applying for (of course, it also needs to be applied for in the order of writing in the read lock waiting queue). Therefore, a read lock conflict is returned, indicating that the read lock conflict detection fails, and the process proceeds to step 604 below.

[0247] For the case where the read lock holding queue (wait_que_read) contains transactions other than the target transaction, it is also necessary to attach the target transaction's own transaction ID and the target transaction's entire write lock wait queue (wait_que_write) for that data record to the read lock wait queue (wait_que_read) of that data record. Similarly, for any transaction added to the read lock wait queue (wait_que_read) (including the target transaction and each transaction in the target transaction's write lock wait queue), the blocking transaction parameter (blocking_trx) of that transaction needs to be updated. The mounting and updating methods are similar to those in case 2-1 above when the read lock wait queue (wait_que_read) is not empty, so they will not be elaborated here.

[0248] 604. If the read lock conflict detection indicates that a read lock conflict exists, the conflict detection result is determined to be a conflict, and proceed to step 607.

[0249] To illustrate, the conflict detection result is a return value indicating whether a conflict exists. For example, the return value could be binary data; a value of 1 indicates a conflict exists and the conflict detection failed, while a value of 0 indicates no conflict exists and the conflict detection passed. Alternatively, the return value could be a boolean value; a value of True indicates a conflict exists and the conflict detection failed, while a value of False indicates no conflict exists and the conflict detection passed.

[0250] In some embodiments, if a read lock conflict detection indicates the existence of a read lock conflict—that is, during the read lock conflict detection process in step 603 above—if condition 2-1 is met and the read lock waiting queue (wait_que_read) of the corresponding data record is not empty, or if condition 2-2 is met, a read lock conflict will be returned, indicating that the read lock conflict detection failed. This means that a conflict has occurred between the write lock that the target transaction intends to request on the data record and the existing read lock on the data record. Therefore, the conflict detection result is determined to be a conflict. Taking this conflict detection result as the return value, the binary data of the return value is configured to 1, or the boolean data of the return value is configured to True. At this time, there is no need to execute the write lock conflict detection process, and the process jumps directly to step 607.

[0251] 605. If the read lock conflict detection indication does not indicate a read lock conflict, perform a write lock conflict detection on the target transaction.

[0252] In some embodiments, if the read lock conflict detection indicates that there is no read lock conflict, that is, during the read lock conflict detection process in step 603 above, when condition 1 is met, or condition 2-1 is met and the read lock waiting queue (wait_que_read) of the corresponding data record is empty, it will return that there is no read lock conflict, indicating that the read lock conflict detection is passed. At this time, it is also necessary to detect whether the write lock that the target transaction wants to apply for on the data record will conflict with the existing write lock of the data record, that is, to start the write lock conflict detection process for the target transaction.

[0253] In some embodiments, the write lock conflict detection process includes: the computing device obtaining the transaction status of the latest transaction, the method of obtaining the transaction status of the latest transaction is similar to step 503 in the previous embodiment, and will not be repeated here; then, based on the transaction status of the latest transaction, determining whether there is a write lock conflict, the method of determining whether there is a write lock conflict is similar to step 504 in the previous embodiment, and will not be repeated here.

[0254] In some embodiments, if the transaction state of the latest transaction is active, i.e., the latest transaction's State = Active, it means that the latest transaction holds a write lock on the data record. This means that there is a conflict between the write lock that the target transaction wants to apply for on the data record and the write lock that the latest transaction is holding on the data record. Therefore, a write lock conflict is returned, and the process proceeds to step 606 below.

[0255] Furthermore, when the transaction state is active (State = Active), a conflict arises between the write lock the target transaction intends to acquire on the data record and the write lock currently held by the latest transaction on the same data record. This indicates that the target transaction needs to wait for the latest transaction to commit before it can acquire the write lock on the data record. Therefore, the write lock wait information of the latest transaction needs to be updated. That is, the target transaction and all transactions waiting for the target transaction to acquire the write lock on the data record need to be added to the write lock wait queue (wait_que_write) corresponding to the data record in the write lock wait information of the latest transaction. The write lock wait information of the latest transaction includes the write lock wait queue for each data record operated by the latest transaction. This write lock wait queue is used to record all transactions waiting for the write lock held by the latest transaction on the data record.

[0256] In other words, the above-mentioned method for updating the write lock wait information includes: the computing device accesses the hash table field (TRX_LOCK_WAIT) in the context information of the latest transaction in memory based on the transaction ID of the latest transaction in order to access the write lock wait information of the latest transaction.

[0257] Next, using the record ID of the data record that the target transaction wants to operate on as an index, the key-value data structure that the index hits is queried in the write lock wait information of the latest transaction. Then, the write lock wait queue (wait_que_write) stored in the value of the hit key-value data structure is accessed. Then, the transaction ID of the target transaction itself is added to the accessed write lock wait queue (wait_que_write), which is equivalent to adding the target transaction to the write lock wait queue (wait_que_write) of the data record.

[0258] Next, in a similar manner to accessing the write lock wait information of the latest transaction, the write lock wait information of the target transaction is accessed. Using the record ID of the data record that the target transaction intends to operate on as an index, the key-value data structure hit by the index is queried in the write lock wait information of the target transaction. Then, the write lock wait queue (wait_que_write) stored in the value of the hit key-value data structure is accessed. This write lock wait queue (wait_que_write) is used to indicate the various transactions waiting for the write lock requested by the target transaction on the data record. Then, in the write lock wait information of the latest transaction, the entire write lock wait queue (wait_que_write) of the target transaction on the data record is mounted to the write lock wait queue (wait_que_write) of the corresponding data record in the latest transaction. This is equivalent to adding the various transactions waiting for the write lock requested by the target transaction on the data record to the write lock wait queue (wait_que_write) of the latest transaction on the data record.

[0259] Furthermore, after attaching the target transaction itself and the write lock wait queue (wait_que_write) of the data record in the target transaction's write lock wait information to the write lock wait queue (wait_que_write) of the same data record in the latest transaction's write lock wait information, it is also necessary to update the blocking transaction parameter (blocking_trx) of each newly added past transaction (including the target transaction and each transaction in the target transaction's write lock wait queue). The blocking transaction parameter (blocking_trx) is used to represent the transaction that the transaction is waiting for.

[0260] The above-mentioned method for updating the blocking transaction parameter (blocking_trx) includes setting the blocking transaction parameter (blocking_trx) of each transaction to the transaction identifier (i.e., transaction ID) of the latest transaction. In other words, since the latest transaction is in an active state, it means that the latest transaction has not yet been committed. Therefore, the target transaction and all transactions waiting for the target transaction need to wait for the latest transaction. Therefore, simply updating the blocking transaction parameter (blocking_trx) to the transaction ID of the latest transaction can ensure the correctness of deadlock detection.

[0261] In some embodiments, if the transaction state of the latest transaction is not active (i.e., the State of the latest transaction is not active), it means that no write lock has been added to the data record. In this case, the target transaction does not need to wait for any transaction to release the lock resource, so it returns that there is no write lock conflict. Since write lock conflict is only enabled when there is no read lock conflict, this means that there is neither read lock conflict nor write lock conflict. That is, both read lock conflict detection and write lock conflict detection have passed. So, the conflict detection result is directly determined to be non-conflict. Taking the conflict detection result as the return value, the binary data of the return value is configured to 0, or the boolean data of the return value is configured to False. Then, the target transaction can be directly executed in step 608.

[0262] Furthermore, if the transaction state is not active (State ≠ Active), the transaction ID recorded in the transaction number (DB_TRX_ID) field needs to be updated on the data record. Previously, the transaction number (DB_TRX_ID) field recorded the transaction ID of the latest transaction; now, the transaction ID of the target transaction is written into the transaction number (DB_TRX_ID) field. This means the original latest transaction is no longer active, indicating it has either committed or rolled back, and the current target transaction has become the latest transaction modifying the data record. In other words, the computing device writes the transaction identifier (transaction ID) of the target transaction into the target hidden field (DB_TRX_ID field) of the data record being operated on by the target transaction. This target hidden field (DB_TRX_ID field) is used to record the transaction identifier of the latest transaction modifying the data record.

[0263] 606. If the write lock conflict detection indicates that a write lock conflict exists, the computing device determines that a conflict exists based on the conflict detection result and proceeds to step 607.

[0264] To illustrate, the conflict detection result is a return value indicating whether a conflict exists. For example, the return value could be binary data; a value of 1 indicates a conflict exists and the conflict detection failed, while a value of 0 indicates no conflict exists and the conflict detection passed. Alternatively, the return value could be a boolean value; a value of True indicates a conflict exists and the conflict detection failed, while a value of False indicates no conflict exists and the conflict detection passed.

[0265] In some embodiments, if a write lock conflict detection indicates that a write lock conflict exists, that is, during the write lock conflict detection process in step 605 above, the latest transaction is found to be active, and a write lock conflict is returned, indicating that the write lock conflict detection fails. This means that the write lock that the target transaction wants to apply for on the data record has a conflict with the existing write lock on the data record. Therefore, the conflict detection result is determined to be a conflict. Taking the conflict detection result as the return value, the binary data of the return value is configured to 1, or the boolean data of the return value is configured to True, and then proceed to step 607.

[0266] 607. If the conflict detection result indicates that a conflict exists, the computing device requests to add a lock, i.e., a write lock, to the data record that corresponds to the operation type of the operation.

[0267] Step 607 is similar to step 505. That is, if the conflict detection result indicates a conflict, although the target transaction attempts to request the lock resource on the data record, the conflict causes the target transaction to enter the lock waiting phase. That is, it needs to wait for the existing lock resource on the data record to be released before the target transaction can queue up to request a new write lock on the data record. After the target transaction is in the queue and the lock request is successful, the target transaction executes and commits (or rolls back), and then releases the write lock it has requested, waking up the next transaction (which may be a read transaction or a write transaction) that requests to perform operations on the data record. The relevant process will be explained in steps 609 to 610A-B below, and will not be repeated here.

[0268] In some embodiments, step 607 above involves the computing device requesting a lock if the conflict detection result indicates a conflict exists, while if the conflict detection result indicates no conflict exists, the computing device does not need to maintain any lock information and can directly proceed to step 608 below to execute the target transaction.

[0269] 608. After the target transaction successfully adds a lock to the data record, the computing device executes the target transaction.

[0270] In this embodiment of the application, a write lock is applied for on the data record. Only after the write lock application for the data record is successful can the target transaction modify the data record, that is, perform a write operation on the data record. For example, modify the value of the C1 field in the data record, generate a new variable version of the data record, and increment the version number by one.

[0271] In some embodiments, since the target transaction may be a sequence of database operations, the target transaction may involve operations on multiple data records. Only after the target transaction has completed the corresponding database operations on each data record can it enter the verification phase of the target transaction, that is, verify whether the target transaction can be committed. If a data anomaly is found, the verification fails and the target transaction needs to be rolled back. If no data anomaly is found, the target transaction can be committed.

[0272] It should be noted that when the target transaction involves operations on multiple data records, and the operation types for different data records are also different, for write operations, the method of this application embodiment is used for conflict detection, and the write operation is performed on the corresponding data record when the lock acquisition is successful (or the lock acquisition is not required through conflict detection). For read operations, the method of the previous embodiment is used for conflict detection, and the read operation is performed on the corresponding data record when the lock acquisition is successful (or the lock acquisition is not required through conflict detection). Only after all data records operated on by the target transaction have completed the corresponding operations can the target transaction enter the verification phase and the commit phase (or rollback phase). This will not be elaborated here.

[0273] 609. After the target transaction is committed, the computing device iterates through the write lock wait queue of each data record in the write lock wait information of the target transaction.

[0274] The write lock wait queue is used to record the various transactions that are waiting for the target transaction to hold a write lock on the data record.

[0275] In some embodiments, the computing device accesses the hash table field (TRX_LOCK_WAIT) in the context information of the target transaction to access the write lock wait information of the target transaction. Since the target transaction may operate on multiple data records, the write lock wait information of the target transaction may contain write lock wait queues (wait_que_write) corresponding to each of the multiple data records. At this time, the computing device traverses the write lock wait queues (wait_que_write) of the corresponding data records stored in the Value of each Key-Value data structure in the write lock wait information of the target transaction. Then, for each write lock wait queue (wait_que_write), since the first transaction in the write lock wait queue (wait_que_write) may request a read lock or a write lock, the number of transactions that need to be woken up is different for read locks and write locks. Therefore, the computing device needs to determine whether the first transaction in the write lock wait queue (wait_que_write) is requesting a read lock or a write lock. If the first transaction in the write lock wait queue (wait_que_write) is requesting a read lock, proceed to step 610-B; if the first transaction in the write lock wait queue (wait_que_write) is requesting a write lock, proceed to step 610-A.

[0276] 610-A. For any data record in the write lock waiting queue, if the computing device wakes up the first transaction in the write lock waiting queue whose lock type is write lock.

[0277] If the first transaction in the write lock wait queue (wait_que_write) requests a write lock, since write locks are exclusive locks, only the first transaction in the write lock wait queue (wait_que_write) can be woken up. For the woken-up first transaction, its write lock wait information and the blocking transaction parameters (blocking_trx) of each transaction waiting for the first transaction also need to be updated.

[0278] In some embodiments, the computing device accesses the hash table field (TRX_LOCK_WAIT) in the context information of the first transaction to access the write lock wait information of the first transaction. Then, using the record ID of the currently traversed data record as an index, it queries the key-value data structure hit by the index in the write lock wait information of the first transaction. Then, it accesses the write lock wait queue (wait_que_write) stored in the value of the hit key-value data structure. Next, it adds all transactions except the first transaction in the write lock wait queue (wait_que_write) currently traversed by the target transaction to the write lock wait queue (wait_que_write) for the data record stored in the value hit by the index. In other words, after waking up the first transaction, it needs to attach all the transactions that were originally waiting for the target transaction to release the write lock on the data record (i.e., the second and all subsequent transactions in the original write lock wait queue) to the write lock wait queue (wait_que_write) corresponding to the woken-up first transaction.

[0279] Furthermore, after attaching all remaining transactions in the original write lock wait queue (i.e., the second and all subsequent transactions) to the write lock wait queue (wait_que_write) corresponding to the first awakened transaction, it is also necessary to update the blocking transaction parameter (blocking_trx) of any transaction newly added to the write lock wait queue (wait_que_write). The blocking transaction parameter (blocking_trx) is used to represent the transaction that the transaction is waiting for.

[0280] Since the target transaction has been committed, the remaining transactions no longer need to wait for it. Instead, they should wait for the first transaction to be awakened. In other words, the computing device sets the blocking transaction parameter (blocking_trx) of the target transaction to the transaction identifier (i.e., transaction ID) of the first transaction. In other words, the blocking transaction parameter (blocking_trx) of each transaction newly added to the write lock wait queue (wait_que_write) is configured to the transaction ID of the first transaction to be awakened.

[0281] 610-B. If the first transaction in the write lock waiting queue requests a read lock, the computing device wakes up all transactions in the write lock waiting queue that have requested read locks.

[0282] If the first transaction in the write lock wait queue (wait_que_write) requests a read lock, since read locks are shared locks, all transactions requesting read locks in the write lock wait queue (wait_que_write) can be woken up at once. At this time, the computing device traverses the write lock wait queue (wait_que_write), determines all transactions requesting read locks, and then wakes up these determined transactions.

[0283] In some embodiments, to maintain the correctness of the global read lock information `slock_table`, it is also necessary to add all transactions requesting read locks in the write lock waiting queue (`wait_que_write`) to the read lock holding queue (`hold_que_read`) of the data record. In other words, using the record ID of the currently traversed data record as an index, the global read lock information `slock_table` queries the key-value data structure matched by that index, then accesses the read lock holding queue (`hold_que_read`) stored in the value of the matched key-value data structure, and then adds the transaction IDs of all transactions requesting read locks in the write lock waiting queue (`wait_que_write`) to the read lock holding queue (`hold_que_read`).

[0284] Furthermore, since all transactions requesting read locks in the write lock wait queue (wait_que_write) are woken up at once, only transactions that have requested write locks remain in the write lock wait queue (wait_que_write). These transactions no longer need to wait for the target transaction (the target transaction has been committed). Therefore, all transactions that have requested write locks in the write lock wait queue (wait_que_write) need to be added to the read lock wait queue (wait_que_read) of the data record in the global read lock information slock_table. In other words, since the previous operation already retrieved the corresponding Key-Value data structure from the global read lock information slock_table using the record ID, the Value of this Key-Value data structure stores two queues: one is the read lock holding queue (hold_que_read) for this data record, and the other is the read lock waiting queue (wait_que_read) for this data record. In the previous operation, the transaction IDs of all transactions requesting read locks in the write lock waiting queue (wait_que_write) have been added to the read lock holding queue (hold_que_read). In this operation, we only need to attach the transaction IDs of all remaining transactions in the write lock waiting queue (wait_que_write) to the read lock waiting queue (wait_que_read).

[0285] Furthermore, for each transaction attached to the read lock waiting queue (wait_que_read), since the waiting transaction has changed from the target transaction to the awakened transaction holding the read lock, it is also necessary to update the blocking transaction parameter (blocking_trx) of any transaction newly added to the read lock waiting queue (wait_que_read). The blocking transaction parameter (blocking_trx) is used to represent the transaction that the transaction is waiting for.

[0286] Since the target transaction has been committed, the transactions that were originally waiting for it no longer need to wait. These transactions should now wait for the awakened transaction holding the read lock. In other words, the computing device sets the blocking transaction parameter (blocking_trx) of this transaction to the transaction ID of the first transaction in the read lock holding queue (hold_que_read) besides this transaction. In other words, the blocking transaction parameter (blocking_trx) of each transaction newly added to the read lock waiting queue (wait_que_read) is configured to the transaction ID of the first transaction in the corresponding read lock holding queue (hold_que_read) that is not equal to itself.

[0287] It should be noted that, in this case, the global read lock information slock_table contains elements in both the read lock holding queue (hold_que_read) and the read lock waiting queue (wait_que_read) corresponding to this data record (all transactions requesting read locks are attached to the read lock holding queue from the write lock waiting queue of the committed target transaction, and all transactions requesting write locks are attached to the read lock waiting queue). Therefore, the read lock for this data record cannot be preempted by the read locks or write locks of other transactions. Thus, there is no possibility of the lock acquisition failing due to preemption.

[0288] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0289] The method provided in this application, when a target transaction requests a write lock on a data record, utilizes global read lock information for read lock conflict detection, utilizes the transaction status of the latest transaction that modified the data record for write lock conflict detection, and maintains write lock waiting information for the latest transaction to promptly wake up the target transaction in the lock waiting stage. This eliminates the need for the overall system's conflict detection to rely on a lock manager or access the mutex every time, thus speeding up the lock request process. Furthermore, the method only requests and creates the corresponding lock information when a conflict exists and the conflict detection fails. For cases where there is no conflict, there is no need to consume resources to maintain the lock information, which greatly reduces the creation of unnecessary row locks in the system, thereby saving storage overhead and memory usage for concurrency control under the lock mechanism.

[0290] In the two embodiments above, the conflict detection process, execution process, and lock release process after execution and commit are respectively described when the target transaction requests a read lock or a write lock. This transaction lock scheme can be applied to various types of transactions such as single-machine transactions, distributed transactions, read transactions, and write transactions. This application embodiment does not specifically limit the type of target transaction.

[0291] In this embodiment of the application, if the target transaction fails verification during the verification phase and is rolled back, it is necessary to release certain lock information to cancel the transaction wait. Optionally, the reasons for the verification failure include, but are not limited to: deadlock, lock wait timeout, application crash, or the execution process or thread of the target transaction crashing.

[0292] After the target transaction is rolled back, firstly, the computing device needs to remove itself from the write lock wait queue of the first transaction that the target transaction is waiting for, indicating that the target transaction is no longer waiting for the write lock of the first transaction (because the target transaction has been rolled back). At this time, based on the target transaction's blocking transaction parameter (blocking_trx), the computing device determines the first transaction that the target transaction is waiting for. This first transaction refers to the transaction pointed to by the transaction ID currently recorded in the target transaction's blocking transaction parameter (blocking_trx). Then, it accesses the hash table field (TRX_LOCK_WAIT) in the context information of the first transaction in memory to access the write lock wait information of the first transaction. Next, it uses the operations involved in the target transaction... Each data record's record ID serves as an index. The write lock wait information of the first transaction is used to query the key-value data structure matched by that index. Then, the write lock wait queue (wait_que_write) stored in the value of the matched key-value data structure is accessed. Next, the transaction ID of the target transaction is removed from the write lock wait queue (wait_que_write). Since the target transaction may operate on multiple data records, the above operation needs to be repeated for each data record to remove the transaction ID of the target transaction from the write lock wait queue (wait_que_write) of each data record operated on by the target transaction in the write lock wait information of the first transaction.

[0293] Secondly, the computing device needs to remove itself from the read lock wait queue (wait_que_read) of each data record operated by the target transaction in the global read lock information slock_table, indicating that the target transaction is no longer waiting for this read lock (because the target transaction has been rolled back). At this time, the computing device uses the record ID of each data record operated by the target transaction as an index to query the key-value data structure hit by the index in the global read lock information slock_table, and then accesses the read lock wait queue (wait_que_read) stored in the value of the hit key-value data structure. Then, it deletes the transaction ID of the target transaction from the read lock wait queue (wait_que_read). Since the target transaction may operate on multiple data records, the above operation needs to be repeated for each data record to delete the transaction ID of the target transaction from the read lock wait queue (wait_que_read) of each data record operated by the target transaction in the global read lock information slock_table.

[0294] Next, after deleting the transaction ID of the target transaction from the read lock wait queue (wait_que_read) of each data record operated by the target transaction, it is possible to determine whether the first waiting transaction in the deleted read lock wait queue (wait_que_read) can be woken up. Only if the first waiting transaction in the read lock wait queue (wait_que_read) is exactly the only transaction in the current data record's read lock holding queue (hold_que_read) can it be considered that the first waiting transaction can be woken up.

[0295] In other words, the computing device queries the read lock holding queue (hold_que_read) of the data record in the global read lock information slock_table, using the record identifier (i.e., record ID) of the current data record as an index. The query method has been described in the previous embodiment and will not be repeated here. Then, it determines whether the read lock holding queue (hold_que_read) contains only a single element. If the read lock holding queue (hold_que_read) contains only a single element, it then determines whether that element is equal to the first element in the read lock waiting queue (wait_que_read). If the read lock holding queue (hold_que_read) contains only a single element and that element is equal to the first element in the read lock waiting queue (wait_que_read), it means that the transaction corresponding to that element can be woken up. In other words, if the read lock holding queue (hold_que_read) contains only a single transaction and that transaction happens to be the first transaction in the read lock waiting queue (wait_que_read), then that transaction is woken up.

[0296] Otherwise, if the above conditions are not met—for example, if the read lock holding queue (hold_que_read) contains two or more elements, or if a single element in the read lock holding queue (hold_que_read) is not equal to the first element in the read lock waiting queue (wait_que_read)—then no transaction can be woken up. It should be noted that at this point, it is not necessary to determine whether to wake up transactions in the write lock waiting queue (wait_que_write) of the target transaction being rolled back. Therefore, if the target transaction itself is in the lock waiting phase, its write lock waiting queue (wait_que_write) will definitely be entirely attached to the write lock waiting information of the first transaction that the target transaction is waiting for. Thus, the target transaction's own write lock waiting queue (wait_que_write) will not contain any waiting transactions.

[0297] The above embodiments provide complete transaction locking schemes that can adapt to any high-concurrency scenario, alleviating the situation where the mutex of the global lock manager in the traditional InnoDB engine becomes the main performance bottleneck. By greatly reducing the storage overhead of locks and reducing the number of locks created, transaction processing performance can be greatly improved. In addition, for transaction loads with low conflict but involving modification of a large amount of data, concurrency control can be achieved by creating only a small amount of lock information without sacrificing concurrency performance, thereby greatly saving server memory usage and optimizing resource utilization.

[0298] Figure 7 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of this application. Please refer to it. Figure 7 The device includes:

[0299] The determination module 701 is used to determine the latest transaction that modified the data record based on the data record operated on by the target transaction.

[0300] The conflict detection module 702 is used to perform lock request conflict detection on the target transaction based on global read lock information and the write lock wait information of the latest transaction. The global read lock information is used to manage read locks in the database system, and the write lock wait information is used to record the various transactions waiting for the write lock held by the latest transaction.

[0301] The lock request module 703 is used to request a lock corresponding to the operation type of the data record when a conflict is detected in the conflict detection indication.

[0302] The apparatus provided in this application records relevant information about read locks in the database system through global read lock information. By modifying the latest transaction of each data record, it can determine whether a write lock exists on that data record and the lock holder of the write lock. Furthermore, the write lock wait information is scattered and stored in the context information of each transaction. This allows the read-write conflict detection of the entire database system to be independent of the lock manager and does not require accessing the mutex every time. After completing the conflict detection using global read lock information and the write lock wait information of the latest transaction corresponding to the data record to be operated on, the corresponding lock information can be requested only for cases where there is a conflict. For cases where there is no conflict, there is no need to consume resources to maintain the lock information. This can greatly reduce the creation of unnecessary row locks in the system, thereby saving the storage overhead and memory usage of concurrency control under the lock mechanism.

[0303] In one possible implementation, based on Figure 7 The device comprises the following components: the collision detection module 702 includes:

[0304] The determining unit is used to determine the type of lock that the target transaction needs to request based on the operation type;

[0305] The first conflict detection unit is used to perform write lock conflict detection only on the target transaction when the lock type is a read lock.

[0306] The second conflict detection unit is used to perform read lock conflict detection and write lock conflict detection on the target transaction when the lock type is write lock.

[0307] In one possible implementation, based on Figure 7 The device comprises the following components: the first collision detection unit includes:

[0308] The sub-unit is used to obtain the transaction status of the latest transaction when the lock type is a read lock;

[0309] The determination sub-unit is used to determine that there is no conflict when the transaction is not in an active state;

[0310] The determining subunit is also used to determine that a conflict exists when the transaction is in an active state.

[0311] In one possible implementation, if the transaction state is not active, based on Figure 7 The device comprises, wherein the first collision detection unit further includes:

[0312] The query sub-unit is used to query the read lock holding queue of the data record in the global read lock information, using the record identifier of the data record as the index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0313] Add a sub-unit to add the target transaction to the read lock holding queue if the target transaction is not already in the read lock holding queue.

[0314] In one possible implementation, the write lock wait information of the latest transaction includes a write lock wait queue for each data record operated by the latest transaction, the write lock wait queue being used to record each transaction waiting for the write lock held by the latest transaction on that data record;

[0315] If the transaction is in an active state, based on Figure 7 The device comprises, wherein the first collision detection unit further includes:

[0316] Add a sub-unit to add the target transaction to the write lock wait queue of the data record in the write lock wait information of the latest transaction;

[0317] The setting sub-unit is used to set the blocking transaction parameter of the target transaction to the transaction identifier of the latest transaction. The blocking transaction parameter is used to characterize the transaction that the target transaction is waiting for.

[0318] In one possible implementation, based on Figure 7 The device comprises, wherein the second collision detection unit includes:

[0319] The read lock conflict detection subunit is used to perform read lock conflict detection on the target transaction when the lock type is a write lock.

[0320] The determination subunit is used to determine that a conflict exists when the read lock conflict detection indication indicates that a read lock conflict exists;

[0321] The write lock conflict detection subunit is used to perform write lock conflict detection on the target transaction when the read lock conflict detection indication indicates that there is no read lock conflict.

[0322] The determining subunit is further configured to determine the conflict detection result as having a conflict if the write lock conflict detection indication indicates that a write lock conflict exists; and to determine the conflict detection result as not having a conflict if the write lock conflict detection indication does not indicate that a write lock conflict exists.

[0323] In one possible implementation, the read lock conflict detection subunit is used for:

[0324] In this global read lock information, the read lock holding queue of the data record is queried using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0325] If the read lock holding queue is empty, return that there is no read lock conflict;

[0326] If the read lock holding queue contains only the target transaction, query the read lock waiting queue for the data record. This read lock waiting queue is used to record each transaction waiting for a read lock held on the data record. If the read lock waiting queue is empty, return that there is no read lock conflict. If the read lock waiting queue is not empty, return that there is a read lock conflict.

[0327] If the read lock holding queue contains transactions other than the target transaction, a read lock conflict is returned.

[0328] In one possible implementation, if the read lock holding queue contains only the target transaction and the read lock waiting queue is not empty, or if the read lock holding queue contains transactions other than the target transaction, based on Figure 7 The device comprises, wherein the second collision detection unit further includes:

[0329] Add a sub-unit to add the target transaction to the read lock wait queue;

[0330] The addition sub-unit is also used to determine, based on the write lock wait information of the target transaction, each transaction waiting for the write lock requested by the target transaction on the data record, and to add each transaction waiting for the write lock requested by the target transaction on the data record to the read lock wait queue.

[0331] In one possible implementation, based on Figure 7 The device comprises, wherein the second collision detection unit further includes:

[0332] The setting sub-unit is used to set the blocking transaction parameter of any transaction added to the read lock waiting queue to the transaction identifier of the first transaction in the read lock holding queue other than the current transaction. The blocking transaction parameter is used to characterize the transaction that the current transaction is waiting for.

[0333] In one possible implementation, the write lock conflict detection subunit is used for:

[0334] Get the transaction status of the latest transaction;

[0335] If the transaction is not in an active state, it returns that there is no write lock conflict.

[0336] If the transaction is in an active state, a write lock conflict is detected.

[0337] In one possible implementation, if the transaction state is not active, based on Figure 7 The device comprises, wherein the second collision detection unit further includes:

[0338] The write sub-unit is used to write the transaction identifier of the target transaction into the target hidden field of the data record, wherein the target hidden field is used to record the transaction identifier of the latest transaction that modified the data record.

[0339] In one possible implementation, the write lock wait information of the latest transaction includes a write lock wait queue for each data record operated by the latest transaction, the write lock wait queue being used to record each transaction waiting for the write lock held by the latest transaction on that data record;

[0340] If the transaction is in an active state, based on Figure 7 The device comprises, wherein the second collision detection unit further includes:

[0341] Add a sub-unit to add the target transaction to the write lock wait queue of the data record in the write lock wait information of the latest transaction;

[0342] The addition sub-unit is also used to determine, based on the write lock wait information of the target transaction, each transaction waiting for the write lock requested by the target transaction on the data record; and to add each transaction waiting for the write lock requested by the target transaction on the data record to the write lock wait queue of the data record in the write lock wait information of the latest transaction.

[0343] In one possible implementation, based on Figure 7 The device comprises, wherein the second collision detection unit further includes:

[0344] The setting sub-unit is used to set the blocking transaction parameter of any transaction added to the write lock wait queue to the transaction identifier of the latest transaction. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0345] In one possible implementation, when the lock type is a read lock, based on Figure 7 The device comprises, and the collision detection module 702 further includes:

[0346] The query unit is used to query the read lock holding queue of the data record in the global read lock information after the target transaction is committed, using the record identifier of the data record as the index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0347] The wake-up unit is used to wake up the first transaction in the read lock waiting queue of the data record when the read lock holding queue is empty. The read lock waiting queue is used to record each transaction waiting for a read lock held on the data record.

[0348] The wake-up unit is also used to wake up a transaction when the read lock holding queue contains only a single transaction and that transaction happens to be the first transaction in the read lock waiting queue.

[0349] The setting unit is used to, otherwise, set the blocking transaction parameter of each transaction in the read lock waiting queue to the transaction identifier of the first transaction in the read lock holding queue other than the current transaction. The blocking transaction parameter is used to characterize the transaction that the current transaction is waiting for.

[0350] In one possible implementation, for the transaction woken up after the target transaction is committed, based on Figure 7 The device comprises, and the collision detection module 702 further includes:

[0351] The addition unit is used to add each transaction other than the awakened transaction in the read lock wait queue to the write lock wait queue of the data record in the write lock wait information of the awakened transaction.

[0352] The setting unit is also used to set the blocking transaction parameter of any transaction added to the write lock wait queue to the transaction identifier of the awakened transaction. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0353] In one possible implementation, when the lock type is a write lock, based on Figure 7 The device comprises, and the collision detection module 702 further includes:

[0354] The traversal unit is used to traverse the write lock wait queue of each data record in the write lock wait information of the target transaction after the target transaction is committed. The write lock wait queue is used to record each transaction waiting for the write lock held by the target transaction on the data record.

[0355] The wake-up unit is used to wake up the first transaction in the write lock waiting queue of any data record if the first transaction in the write lock waiting queue requests a write lock; and wake up all transactions in the write lock waiting queue that request a read lock if the first transaction in the write lock waiting queue requests a read lock.

[0356] In one possible implementation, for any data record's write lock wait queue, if the first transaction in the write lock wait queue requests a write lock, then for that first transaction, based on... Figure 7 The device comprises, and the collision detection module 702 further includes:

[0357] The add unit is used to add each transaction other than the first transaction in the write lock wait queue to the write lock wait queue of the data record in the write lock wait information of the first transaction.

[0358] The setting unit is also used to set the blocking transaction parameter of any transaction added to the write lock wait queue to the transaction identifier of the first transaction, the blocking transaction parameter being used to characterize the transaction that the transaction is waiting for.

[0359] In one possible implementation, for any data record's write lock wait queue, if the first transaction in the write lock wait queue requests a read lock, based on... Figure 7 The device comprises, and the collision detection module 702 further includes:

[0360] The add unit is used to add all transactions that have requested read locks in the write lock waiting queue to the read lock holding queue of the data record in the global read lock information.

[0361] This addition unit is also used to add all transactions that have requested write locks in the write lock wait queue to the read lock wait queue of the data record.

[0362] In one possible implementation, the setting unit is further configured to:

[0363] For any transaction added to the read lock waiting queue, set the blocking transaction parameter of that transaction to the transaction identifier of the first transaction in the read lock holding queue other than that transaction. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

[0364] In one possible implementation, the determining module 701 is further configured to: after the target transaction is rolled back, determine the first transaction that the target transaction is waiting for based on the blocking transaction parameters of the target transaction;

[0365] based on Figure 7 The device comprises:

[0366] The deletion module is used to delete the target transaction from the write lock wait queue of the data records operated by the target transaction in the write lock wait information of the first transaction;

[0367] The deletion module is also used to delete the target transaction from the read lock wait queue of the data records operated by the target transaction in the global read lock information.

[0368] In one possible implementation, based on Figure 7 The device comprises:

[0369] The query module is used to query the read lock holding queue of the data record in the global read lock information, using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record.

[0370] The wake-up module is used to wake up a transaction when the read lock holding queue contains only a single transaction and that transaction happens to be the first transaction in the read lock waiting queue.

[0371] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0372] It should be noted that the transaction processing apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when processing transactions. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the transaction processing apparatus and the transaction processing method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the transaction processing method embodiments, which will not be repeated here.

[0373] Figure 8This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Optionally, the device type of the terminal 800 includes: a smartphone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, or a desktop computer. The terminal 800 may also be referred to as a user device, a portable terminal, a laptop terminal, a desktop terminal, or other names.

[0374] Typically, terminal 800 includes a processor 801 and a memory 802.

[0375] Optionally, the processor 801 includes one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Optionally, the processor 801 is implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). In some embodiments, the processor 801 includes a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 801 integrates a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 801 also includes an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0376] In some embodiments, memory 802 includes one or more computer-readable storage media, optionally non-transitory. Optionally, memory 802 also includes high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in memory 802 is used to store at least one program code, which is executed by processor 801 to implement the transaction processing methods provided in the various embodiments of this application.

[0377] In some embodiments, the terminal 800 may also optionally include a peripheral device interface 803 and at least one peripheral device. The processor 801, memory 802, and peripheral device interface 803 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 803 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 804, a display screen 805, a camera assembly 806, an audio circuit 807, and a power supply 808.

[0378] Peripheral device interface 803 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 801 and memory 802. In some embodiments, processor 801, memory 802 and peripheral device interface 803 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 801, memory 802 and peripheral device interface 803 are implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0379] The radio frequency (RF) circuit 804 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 804 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 804 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 804 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. Optionally, the RF circuit 804 communicates with other terminals via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 804 also includes circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0380] Display screen 805 is used to display a UI (User Interface). Optionally, the UI includes graphics, text, icons, videos, and any combination thereof. When display screen 805 is a touch display screen, display screen 805 also has the ability to collect touch signals on or above the surface of display screen 805. The touch signals can be input to processor 801 for processing as control signals. Optionally, display screen 805 is also used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, there is one display screen 805, which is set on the front panel of terminal 800; in other embodiments, there are at least two display screens 805, which are respectively set on different surfaces of terminal 800 or have a folded design; in still other embodiments, display screen 805 is a flexible display screen, which is set on the curved surface or folded surface of terminal 800. Furthermore, optionally, display screen 805 is set as a non-rectangular irregular shape, that is, an irregularly shaped screen. Optionally, the display screen 805 is made of materials such as LCD (Liquid Crystal Display) or OLED (Organic Light-Emitting Diode).

[0381] The camera assembly 806 is used to acquire images or videos. Optionally, the camera assembly 806 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 806 also includes a flash. Optionally, the flash is a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, used for light compensation at different color temperatures.

[0382] In some embodiments, the audio circuit 807 includes a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals that are input to the processor 801 for processing, or input to the radio frequency circuit 804 to realize voice communication. For stereo acquisition or noise reduction purposes, multiple microphones are used, respectively located at different parts of the terminal 800. Optionally, the microphone is an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert the electrical signals from the processor 801 or the radio frequency circuit 804 into sound waves. Optionally, the speaker is a conventional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert electrical signals into sound waves that humans can hear, but also convert electrical signals into sound waves that humans cannot hear for purposes such as distance measurement. In some embodiments, the audio circuit 807 also includes a headphone jack.

[0383] The power supply 808 is used to power the various components in the terminal 800. Optionally, the power supply 808 is AC power, DC power, a disposable battery, or a rechargeable battery. When the power supply 808 includes a rechargeable battery, the rechargeable battery supports wired or wireless charging. The rechargeable battery also supports fast charging technology.

[0384] In some embodiments, the terminal 800 further includes one or more sensors 810. The one or more sensors 810 include, but are not limited to, an acceleration sensor 811, a gyroscope sensor 812, a pressure sensor 813, an optical sensor 814, and a proximity sensor 815.

[0385] In some embodiments, the accelerometer 811 detects the magnitude of acceleration along three coordinate axes of a coordinate system established with respect to the terminal 800. For example, the accelerometer 811 is used to detect the components of gravitational acceleration along the three coordinate axes. Optionally, the processor 801 controls the display screen 805 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by the accelerometer 811. The accelerometer 811 is also used for acquiring motion data from games or the user.

[0386] In some embodiments, the gyroscope sensor 812 detects the orientation and rotation angle of the terminal 800. The gyroscope sensor 812 and the accelerometer sensor 811 work together to acquire the user's 3D movements on the terminal 800. Based on the data acquired by the gyroscope sensor 812, the processor 801 implements the following functions: motion sensing (e.g., changing the UI based on the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0387] Optionally, the pressure sensor 813 is disposed on the side bezel of the terminal 800 and / or on the lower layer of the display screen 805. When the pressure sensor 813 is disposed on the side bezel of the terminal 800, it can detect the user's grip signal on the terminal 800, and the processor 801 performs left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 813. When the pressure sensor 813 is disposed on the lower layer of the display screen 805, the processor 801 controls the operable controls on the UI interface based on the user's pressure operation on the display screen 805. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0388] An optical sensor 814 is used to collect ambient light intensity. In one embodiment, the processor 801 controls the display brightness of the display screen 805 based on the ambient light intensity collected by the optical sensor 814. Specifically, when the ambient light intensity is high, the display brightness of the display screen 805 is increased; when the ambient light intensity is low, the display brightness of the display screen 805 is decreased. In another embodiment, the processor 801 also dynamically adjusts the shooting parameters of the camera assembly 806 based on the ambient light intensity collected by the optical sensor 814.

[0389] The proximity sensor 815, also known as a distance sensor, is typically located on the front panel of the terminal 800. The proximity sensor 815 is used to detect the distance between the user and the front of the terminal 800. In one embodiment, when the proximity sensor 815 detects that the distance between the user and the front of the terminal 800 is gradually decreasing, the processor 801 controls the display screen 805 to switch from a screen-on state to a screen-off state; when the proximity sensor 815 detects that the distance between the user and the front of the terminal 800 is gradually increasing, the processor 801 controls the display screen 805 to switch from a screen-off state to a screen-on state.

[0390] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on terminal 800, which may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0391] Figure 9This is a schematic diagram of a computer device 900 provided in an embodiment of this application. The computer device 900 can vary significantly due to differences in configuration or performance. The computer device 900 includes one or more Central Processing Units (CPUs) 901 and one or more memories 902. The memories 902 store at least one computer program, which is loaded and executed by the one or more processors 901 to implement the transaction processing methods provided in the various embodiments described above. Optionally, the computer device 900 also includes wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The computer device 900 also includes other components for implementing device functions, which will not be elaborated here.

[0392] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including at least one computer program, which can be executed by a processor in a terminal to perform the transaction processing methods in the various embodiments described above. For example, the computer-readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0393] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more lines of program code stored in a computer-readable storage medium. One or more processors of a computer device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the computer device to perform the transaction processing method described in the above embodiments.

[0394] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. Optionally, the program is stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0395] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A transaction processing method, characterized in that, The method includes: Based on the data records operated by the target transaction, determine the latest transaction that modified the data records; Based on the operation type of the operation, determine the lock type that the target transaction needs to request; When the lock type is a read lock, write lock conflict detection is performed on the target transaction based on global read lock information and the write lock wait information of the latest transaction; when the lock type is a write lock, read lock conflict detection and write lock conflict detection are performed on the target transaction based on the global read lock information and the write lock wait information. The global read lock information is used to manage read locks in the database system, and the write lock wait information is used to record each transaction waiting for the write lock held by the latest transaction. If a conflict is detected in the conflict detection indication, a lock corresponding to the operation type of the operation is requested to be added to the data record; When the lock type is a write lock, after the target transaction is committed, the write lock wait queue for each data record in the write lock wait information of the target transaction is traversed. The write lock wait queue is used to record each transaction waiting for the write lock held by the target transaction for the data record. For any data record's write lock wait queue, if the first transaction in the write lock wait queue requests a write lock, the first transaction is woken up. If the first transaction in the write lock wait queue requests a read lock, all transactions in the write lock wait queue that request read locks are woken up.

2. The method according to claim 1, characterized in that, When the lock type is a read lock, the write lock conflict detection for the target transaction based on global read lock information and the write lock wait information of the latest transaction includes: If the lock type is a read lock, obtain the transaction status of the latest transaction; If the transaction is not in an active state, the conflict detection result will be determined as no conflict exists; If the transaction is in an active state, the conflict detection result is determined to indicate that a conflict exists.

3. The method according to claim 2, characterized in that, If the transaction state is not active, the method further includes: In the global read lock information, the read lock holding queue of the data record is queried using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record. If the target transaction is not present in the read lock holding queue, the target transaction is added to the read lock holding queue.

4. The method according to claim 2, characterized in that, The write lock wait information of the latest transaction includes a write lock wait queue for each data record operated by the latest transaction. The write lock wait queue is used to record each transaction waiting for the write lock held by the latest transaction on the data record. If the transaction state is active, the method further includes: In the write lock wait information of the latest transaction, the target transaction is added to the write lock wait queue of the data record; The blocking transaction parameter of the target transaction is set to the transaction identifier of the latest transaction, and the blocking transaction parameter is used to characterize the transaction that the target transaction is waiting for.

5. The method according to claim 1, characterized in that, When the lock type is a write lock, the read lock conflict detection and write lock conflict detection for the target transaction based on the global read lock information and the write lock wait information includes: When the lock type is a write lock, read lock conflict detection is performed on the target transaction; If the read lock conflict detection indicates that a read lock conflict exists, the conflict detection result will be determined as a conflict. If the read lock conflict detection indicates that there is no read lock conflict, a write lock conflict detection is performed on the target transaction; if the write lock conflict detection indicates that there is a write lock conflict, the conflict detection result is determined to be a conflict; if the write lock conflict detection indicates that there is no write lock conflict, the conflict detection result is determined to be a conflict.

6. The method according to claim 5, characterized in that, The read lock conflict detection for the target transaction includes: In the global read lock information, the read lock holding queue of the data record is queried using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record. If the read lock holding queue is empty, return that there is no read lock conflict; If the read lock holding queue contains only the target transaction, query the read lock waiting queue of the data record. The read lock waiting queue is used to record each transaction waiting for a read lock held on the data record. If the read lock waiting queue is empty, return that there is no read lock conflict. If the read lock waiting queue is not empty, return that there is a read lock conflict. If the read lock holding queue contains transactions other than the target transaction, a read lock conflict is returned.

7. The method according to claim 6, characterized in that, The method further includes the following steps: If the read lock holding queue contains only the target transaction and the read lock waiting queue is not empty, or if the read lock holding queue contains transactions other than the target transaction. Add the target transaction to the read lock wait queue; Based on the write lock wait information of the target transaction, identify the transactions that are waiting for the target transaction to request a write lock on the data record; Add each transaction that is waiting for the target transaction to request a write lock on the data record to the read lock waiting queue; For any transaction added to the read lock waiting queue, the blocking transaction parameter of the transaction is set to the transaction identifier of the first transaction in the read lock holding queue other than the transaction itself. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

8. The method according to claim 5, characterized in that, The write lock conflict detection for the target transaction includes: Obtain the transaction status of the latest transaction; If the transaction is not in an active state, return that there is no write lock conflict; If the transaction is in an active state, a write lock conflict is detected.

9. The method according to claim 8, characterized in that, If the transaction state is not active, the method further includes: The target hidden field of the data record is written with the transaction identifier of the target transaction, wherein the target hidden field is used to record the transaction identifier of the latest transaction that modified the data record.

10. The method according to claim 8, characterized in that, The write lock wait information of the latest transaction includes a write lock wait queue for each data record operated by the latest transaction. The write lock wait queue is used to record each transaction waiting for the write lock held by the latest transaction on the data record. If the transaction state is active, the method further includes: In the write lock wait information of the latest transaction, the target transaction is added to the write lock wait queue of the data record; Based on the write lock wait information of the target transaction, identify the transactions that are waiting for the target transaction to request a write lock on the data record; In the write lock wait information of the latest transaction, each transaction waiting for the target transaction to request a write lock on the data record is added to the write lock wait queue of the data record; For any transaction added to the write lock wait queue, the blocking transaction parameter of the transaction is set to the transaction identifier of the latest transaction, whereby the blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

11. The method according to claim 1, characterized in that, When the lock type is a read lock, the method further includes: After the target transaction is committed, the global read lock information is used to query the read lock holding queue of the data record, with the record identifier of the data record as the index. The read lock holding queue is used to record each transaction that holds the read lock of the data record. If the read lock holding queue is empty, wake up the first transaction in the read lock waiting queue of the data record. The read lock waiting queue is used to record each transaction waiting for a read lock held on the data record. If the read lock holding queue contains only a single transaction, and that transaction happens to be the first transaction in the read lock waiting queue, then the transaction is woken up. Otherwise, for each transaction in the read lock waiting queue, the blocking transaction parameter of the transaction is set to the transaction identifier of the first transaction in the read lock holding queue other than the transaction itself, and the blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

12. The method according to claim 11, characterized in that, For transactions woken up after the target transaction is committed, the method further includes: In the write lock wait information of the awakened transaction, each transaction other than the awakened transaction in the read lock wait queue is added to the write lock wait queue of the data record. For any transaction added to the write lock wait queue, the blocking transaction parameter of the transaction is set to the transaction identifier of the awakened transaction, whereby the blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

13. The method according to claim 1, characterized in that, For any write lock wait queue of a data record, if the first transaction in the write lock wait queue requests a write lock, the method further includes, for the first transaction: In the write lock wait information of the first transaction, each transaction other than the first transaction in the write lock wait queue is added to the write lock wait queue of the data record. For any transaction added to the write lock wait queue, the blocking transaction parameter of the transaction is set to the transaction identifier of the first transaction, whereby the blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

14. The method according to claim 1, characterized in that, For any write lock wait queue of a data record, if the first transaction in the write lock wait queue requests a read lock, the method further includes: In the global read lock information, all transactions that have applied for read locks in the write lock waiting queue are added to the read lock holding queue of the data record; Add all transactions that have requested write locks in the write lock waiting queue to the read lock waiting queue of the data record; For any transaction added to the read lock waiting queue, the blocking transaction parameter of the transaction is set to the transaction identifier of the first transaction in the read lock holding queue other than the transaction itself. The blocking transaction parameter is used to characterize the transaction that the transaction is waiting for.

15. The method according to claim 1, characterized in that, The method further includes: After the target transaction is rolled back, the first transaction that the target transaction is waiting for is determined based on the blocking transaction parameters of the target transaction; In the write lock wait information of the first transaction, the target transaction is removed from the write lock wait queue of the data records operated by the target transaction; In the global read lock information, the target transaction is removed from the read lock waiting queue of the data records operated by the target transaction; In the global read lock information, the read lock holding queue of the data record is queried using the record identifier of the data record as an index. The read lock holding queue is used to record each transaction that holds the read lock of the data record. If the read lock holding queue contains only a single transaction, and that transaction happens to be the first transaction in the read lock waiting queue, then the transaction is woken up.

16. A transaction processing apparatus, characterized in that, The device includes: The determination module is used to determine the latest transaction that modified the data record based on the data record operated on by the target transaction. The conflict detection module is used to determine the lock type to be requested by the target transaction based on the operation type of the operation; if the lock type is a read lock, it performs write lock conflict detection on the target transaction based on global read lock information and the write lock waiting information of the latest transaction; if the lock type is a write lock, it performs read lock conflict detection and write lock conflict detection on the target transaction based on the global read lock information and the write lock waiting information. The global read lock information is used to manage read locks in the database system, and the write lock waiting information is used to record each transaction waiting for the write lock held by the latest transaction. The lock request module is used to request a lock corresponding to the operation type of the operation to be added to the data record when the conflict detection indication shows a conflict. The conflict detection module is further configured to, when the lock type is a write lock, after the target transaction is committed, traverse the write lock wait queue of each data record in the write lock wait information of the target transaction, wherein the write lock wait queue is used to record each transaction waiting for the write lock held by the target transaction for the data record; for any data record's write lock wait queue, if the first transaction in the write lock wait queue requests a write lock, wake up the first transaction; if the first transaction in the write lock wait queue requests a read lock, wake up all transactions in the write lock wait queue that request a read lock.

17. A computer device, characterized in that, The computer device includes one or more processors and one or more memories, wherein at least one computer program is stored in the one or more memories, and the at least one computer program is loaded and executed by the one or more processors to implement the transaction processing method as described in any one of claims 1 to 15.

18. A storage medium, characterized in that, The storage medium stores at least one computer program, which is loaded and executed by a processor to implement the transaction processing method as described in any one of claims 1 to 15.

19. A computer program product, characterized in that, The computer program product includes one or more lines of program code stored in a computer-readable storage medium. One or more processors of the computer device read the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, causing the computer device to perform the transaction processing method as described in any one of claims 1 to 15.

Images