Data processing method, system and apparatus

Abstract

Embodiments of the present specification provide a data processing method, system and device, wherein the method comprises: executing a target transaction by a first coroutine associated with the working thread, obtaining a transaction log of the target transaction; sending a transaction submission task of the target transaction to a log storage thread, and releasing the working thread by suspending the first coroutine, wherein the log storage thread is used to store the transaction log; in the case of receiving storage information returned by the log storage thread, performing a recovery operation on the first coroutine, and continuing to execute the transaction submission task by the first coroutine. The demand of high concurrency transaction request scenario is met, the situation of multi-thread lock competition is avoided, the database throughput is improved, and the thread execution efficiency is also improved, so that the database is in good write performance.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a data processing method, system, and apparatus. Background Technology

[0002] With the continuous development of internet technology, databases have become widely used in various project fields. To ensure the reliability of data operations under high concurrency and system failure conditions, database management systems (DBMS) need to adhere to the ACID principles. Transaction log persistence is a crucial step in ensuring that the database meets the durability requirements of the ACID principles. DBMS writes the transaction log to disk to complete the log persistence operation, thus achieving transaction log persistence. However, the log persistence operation is very time-consuming, so increasing the number of concurrent threads is often used to solve this problem. However, this approach can lead to lock contention and CPU contention, resulting in decreased thread execution efficiency and reduced database write performance. Therefore, in high-concurrency scenarios, how to improve database write throughput while avoiding the increase in thread scheduling overhead is a pressing issue that needs to be addressed. Summary of the Invention

[0003] In view of the above, embodiments of this specification provide a data processing method. One or more embodiments of this specification also relate to a data processing system, a data processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a data processing method is provided, applied to a worker thread in a database management system, comprising:

[0005] The target transaction is executed by the first coroutine associated with the worker thread, and the transaction log of the target transaction is obtained.

[0006] The transaction commit task of the target transaction is sent to the log storage thread, and the worker thread is released by suspending the first coroutine, wherein the log storage thread is used to store the transaction log;

[0007] Upon receiving the storage information returned by the log storage thread, a recovery operation is performed on the first coroutine, and the transaction commit task continues to be executed through the first coroutine.

[0008] According to a second aspect of the embodiments of this specification, a database management system is provided, the system including worker threads and log storage threads, wherein...

[0009] The worker thread is used to execute the target transaction through the first coroutine, obtain the transaction log of the target transaction, send the transaction commit task of the target transaction to the log storage thread, and release the worker thread by suspending the first coroutine.

[0010] The log storage thread is used to store the transaction log, obtain the storage information, and return it to the worker thread;

[0011] The worker thread is used to perform a recovery operation on the first coroutine based on the stored information, and to continue executing the transaction commit task through the first coroutine.

[0012] According to a third aspect of the embodiments of this specification, a data processing apparatus is provided, applied to a worker thread in a database management system, comprising:

[0013] The execution module is configured to execute the target transaction through a first coroutine associated with the worker thread and obtain the transaction log of the target transaction;

[0014] The suspension module is configured to send the transaction commit task of the target transaction to the log storage thread, and to release the worker thread by suspending the first coroutine, wherein the log storage thread is used to store the transaction log;

[0015] The recovery module is configured to perform a recovery operation on the first coroutine upon receiving storage information returned by the log storage thread, and to continue executing the transaction commit task through the first coroutine.

[0016] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising:

[0017] Memory and processor;

[0018] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the above-described data processing method.

[0019] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the data processing method described above.

[0020] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the data processing method described above.

[0021] One embodiment of this specification, based on worker threads in a database management system, implements transaction request scheduling by executing the target transaction through a first coroutine associated with the worker thread during transaction request scheduling. This reduces the operating system's overhead on thread scheduling. During transaction log write-to-disk operations, the transaction commit task of the target transaction is sent to the log storage thread, and the first coroutine is suspended to release the worker thread. This allows the released worker thread to be scheduled and switched to other connections or transactions for processing while the log storage thread performs the log write-to-disk operation. This meets the needs of high-concurrency transaction request scenarios, avoids multi-threaded lock contention, improves database throughput, and enhances thread execution efficiency, resulting in good database write performance. Attached Figure Description

[0022] Figure 1 This diagram illustrates the execution framework of a database management system in a data processing method according to an embodiment of this specification.

[0023] Figure 2 A flowchart of a data processing method provided in one embodiment of this specification is shown;

[0024] Figure 3 A flowchart illustrating the processing procedure of a data processing method provided in one embodiment of this specification is shown.

[0025] Figure 4 This specification shows a schematic diagram of the structure of a data processing system according to one embodiment.

[0026] Figure 5 This specification shows a schematic diagram of the structure of a data processing apparatus according to one embodiment;

[0027] Figure 6 A structural block diagram of a computing device provided in one embodiment of this specification is shown. Detailed Implementation

[0028] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0029] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0030] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0031] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0032] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0033] PolarDB MySQL: PolarDB MySQL is a relational database management system independently developed based on MySQL. It not only optimizes and enhances upon MySQL but also introduces many innovative technologies to improve performance, scalability, and availability. In the embodiments described in this specification, PolarDB MySQL is selected as the database management system.

[0034] InnoDB: InnoDB is the default storage engine for MySQL databases. As one of the core components of modern databases, it plays a vital role in numerous application scenarios due to its rich features and powerful functionality. InnoDB is a transaction-safe (ACID-compliant) storage engine that supports row-level locking and foreign key constraints, making it particularly suitable for applications requiring high reliability, transaction support, and concurrency performance. In the embodiments described in this specification, transaction operations are performed based on the transaction support provided by the InnoDB transactional storage engine to ensure the consistency, integrity, and reliability of database data.

[0035] Thread: A thread in a database management system is used to perform internal tasks such as logging to disk or external user requests such as foreground user threads. In the embodiments of this specification, a thread may include worker threads, log storage threads, listening threads, etc.

[0036] Thread Pool: ThreadPool is a thread pool module in database management systems that can manage multiple threads simultaneously to concurrently execute user requests. Thread pools are an optimization technique designed to improve server performance and resource utilization, especially in high-concurrency environments. Instead of creating a new thread for each new connection, thread pools manage a pre-created set of threads to handle client requests, thus reducing the overhead of thread creation and destruction and improving system responsiveness and throughput.

[0037] Coroutine: A coroutine is a lightweight unit of execution that allows concurrent operations to be performed within a single thread. Compared to traditional threads, coroutines have lower switching overhead and can share resources more efficiently between different parts of a program. In the embodiments described in this specification, coroutines are used for transaction management, such as transaction execution, commit, and rollback.

[0038] Connection: In a database management system, a Connection refers to a communication connection established between a client application and the database. Through this connection, the client can send SQL query commands to the database and receive the execution results. In the embodiments of this specification, the connection is the connection between the client application and the database. Through the connection, the application can send SQL statements to the database, thereby executing corresponding transactions to complete data operations.

[0039] Transactions: Transactions are data operations performed on a database. In a database management system, a transaction is an execution unit consisting of one or more SQL statements. These statements are processed as a whole; either all execute successfully, or none execute at all. Transactions are typically used to ensure data consistency and integrity. Transactions can contain various operations performed on the database, such as data reading or data writing.

[0040] ACID Principles: The ACID principles refer to the four fundamental principles that transactions in a database management system must satisfy to ensure the reliability of data operations.

[0041] Atomicity: All operations within a transaction either complete entirely or are not executed at all; there is no state of partial completion. If an error occurs during the execution of a transaction, the entire transaction will be rolled back, as if it had never started.

[0042] Consistency: A transaction must transform the database from one consistent state to another. That is, the database's integrity constraints must not be violated before and after the transaction is executed; all rules must be applied to the transaction's modifications to maintain the database's consistent state.

[0043] Isolation: Multiple concurrently executed transactions are isolated from each other and do not affect each other. That is, the operations and data used within a transaction are isolated from other concurrent transactions, and the concurrently executed transactions cannot interfere with each other.

[0044] Durability: Once a transaction is committed, its changes to the data in the database are permanent and should not be affected even if the system fails. Even if the system crashes or encounters hardware problems, the committed data will not be lost.

[0045] Currently, based on the ACID properties of transactions, the transaction log must be persisted to disk when a transaction is committed. However, the log writing operation is very time-consuming. In order to improve the database write throughput, the problem is often solved by increasing the number of concurrent write threads. However, increasing the number of concurrent threads can bring other side effects, such as lock contention in non-IO scenarios like lock sys and trx sys, CPU contention under high concurrency, and frequent context switching, which leads to a decrease in thread execution efficiency and makes it impossible to obtain good database write performance.

[0046] Therefore, this specification provides a data processing method, and also relates to a data processing system, a data processing device, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0047] See Figure 1 , Figure 1 This diagram illustrates the execution framework of a database management system in a data processing method according to an embodiment of this specification. The execution framework of the database management system includes several core components, such as Groups and Timer threads. A Group represents a thread group, which includes a low-priority queue, a high-priority queue, and an asynchronous preparation queue. These queues are used to store connections. Worker threads are scheduled for execution according to the priority of the queues, with the priority of the three queues in descending order as the asynchronous preparation queue, the high-priority queue, and the low-priority queue. A worker thread represents a worker thread that executes user requests. In this embodiment, worker threads are used to handle transaction operations corresponding to connections. A thread group can include multiple worker threads, and each worker thread can concurrently execute transaction operations for multiple connections according to the execution strategy. A coroutine cache pool is used to pre-allocate coroutine objects to execute asynchronous requests. A listener thread is used to listen for I / O events, such as new requests or log write-to-disk completion events. A timer thread is used to execute background scheduled tasks, such as detecting connection timeouts, checking if the current thread count meets expectations, waking up or creating additional threads, etc. By employing the execution framework of the database management system mentioned above, and executing the data processing methods provided in this manual, the target transaction is executed through a first coroutine associated with the worker thread during transaction request scheduling. This achieves transaction request scheduling via coroutines, reducing the operating system's overhead on thread scheduling. During transaction log write-to-disk operations, the transaction commit task of the target transaction is sent to the log storage thread, and the first coroutine is suspended to release the worker thread. This allows the released worker thread to be scheduled and switched to other connections or transactions for processing while the log storage thread performs the log write-to-disk operation. This meets the needs of high-concurrency transaction request scenarios, avoids multi-threaded lock contention, improves database throughput, and enhances thread execution efficiency, resulting in good database write performance.

[0048] See Figure 2 , Figure 2 A flowchart of a data processing method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0049] Step 202: Execute the target transaction through the first coroutine associated with the worker thread to obtain the transaction log of the target transaction.

[0050] In this context, a worker thread can be understood as a specific worker thread within a thread group. Worker threads execute transaction requests sent by the application to the database. To handle high concurrency scenarios, worker threads can execute transaction requests via coroutines. Specifically, a corresponding coroutine is created for each connection. Therefore, after determining the target transaction for a connection, the target transaction can be executed through the first coroutine associated with the worker thread. The first coroutine is the coroutine corresponding to that connection, and the target transaction is the transaction for that connection. After executing the target transaction through the first coroutine associated with the worker thread, the transaction log corresponding to the target transaction can be obtained. The transaction log can be understood as the redo long of the target transaction. Under the transaction mechanism provided by the InnoDB storage engine, to ensure the ACID principles of transactions, the transaction log of the target transaction needs to be written to the storage system, i.e., log persistence to disk.

[0051] In practical applications, when a client application performs data operations on a database, it sends a connection request to the database management system. Through the connection between the client application and the database, the application can send SQL statements to perform corresponding operations on the data stored in the database.

[0052] After a connection is established, existing database processing models typically allocate a corresponding thread to the connection to handle all operations on that connection. In this model, if an operation blocks, such as waiting for I / O to complete, the entire thread is blocked until that operation is finished before it can continue processing other tasks. This model has several significant limitations: high resource consumption, high context switching overhead, and significant blocking impact. High resource consumption means that allocating a separate worker thread for each client connection leads to a large amount of memory and CPU resources being consumed, especially when facing a large number of concurrent connections; the system may exhaust its resources due to creating too many threads. High context switching overhead means that when a large number of threads are running simultaneously, the operating system needs to frequently switch contexts between threads, which incurs additional performance overhead and reduces the overall efficiency of the system. Significant blocking impact means that because threads cannot process other tasks when encountering blocking operations, even if there are available CPU resources in the system, these resources cannot be used to improve throughput or response speed.

[0053] Based on this, in the embodiments of this specification, when a worker thread processes a transaction request corresponding to a connection, it chooses to allocate a coroutine to handle the transaction request. In contrast, the worker thread model using coroutines can significantly overcome the aforementioned problems. Coroutines are lightweight, allowing multiple coroutines to run concurrently within a single worker thread, and the overhead of creating and destroying them is far less than that of threads. When a coroutine needs to wait, it can proactively relinquish execution to other coroutines, allowing the same worker thread to continue processing other tasks, thereby improving resource utilization and the system's concurrent processing capabilities. Coroutines provide a more intuitive way to write asynchronous code; developers can implement complex control flows by suspending and resuming coroutines without relying on complex mechanisms such as callback functions. In this way, the system can significantly improve its ability to handle large-scale concurrent connections while reducing resource consumption.

[0054] Furthermore, in order to call the coroutine to execute the transaction request corresponding to the connection, it is necessary to allocate and associate a coroutine. Specifically, before executing the target transaction through the first coroutine associated with the worker thread, the method further includes: obtaining the first connection and determining the target transaction corresponding to the first connection; creating an initial coroutine and associating the initial coroutine with the first connection to obtain the first coroutine.

[0055] The first connection can be understood as a connection sent by the client application to the database. This connection enables communication between the client and the database, allowing the application to send SQL statements corresponding to subsequent transactions. Once the database management system obtains the first connection, it can determine the transaction corresponding to that connection—the target transaction. The first connection can include multiple transactions to perform different data operations. To handle tasks in high-concurrency scenarios, the database management system's asynchronous processing architecture can allocate corresponding coroutines to process the first connection, thus avoiding thread blocking caused by transaction operations waiting.

[0056] In practical applications, the database management system (DBMS) allocates connection requests to one of multiple thread groups according to a scheduling strategy. This thread group then calls one of its worker threads to respond. The worker thread can obtain a connection ready to execute SQL statements using the `get_even` function, and subsequently selects a coroutine from the coroutine cache pool to associate with it. The associated coroutine then executes the transaction operations contained in that connection. It's worth noting that the DBMS also involves timer threads to execute background scheduled tasks, such as checking connection timeouts, verifying the current thread count against expectations, waking up or creating additional threads, etc. This timer thread, combined with the scheduling strategy, enables connection scheduling and allocation, improving database throughput.

[0057] In a specific embodiment of this specification, the worker thread obtains a connection (the first connection) ready to execute an SQL statement using the `get_even` function. An initial coroutine is created by calling the `tp_handle_request_wrapper` function, and this initial coroutine is then associated and bound to the first connection using the `conn_task_prepare` function. This associated coroutine becomes the first coroutine corresponding to the first connection. It should be noted that the entry function of the first coroutine can be determined during the binding process. The entry function is the first function executed when the first coroutine performs its subsequent logic, such as a query, insert, or update SQL statement. The worker thread can then begin executing the coroutine logic using the `conn_task_run` function to complete the corresponding transaction operations.

[0058] Based on this, by assigning and binding a coroutine to the connection, subsequent transaction operations contained in the connection can be executed through this coroutine, avoiding the blocking of worker threads when transaction operations are waiting, thus improving thread execution efficiency.

[0059] Furthermore, in order to use the asynchronous processing function normally, it is also necessary to determine the global variables corresponding to the connection. The specific method also includes: determining the asynchronous execution variable corresponding to the first connection; if the asynchronous execution variable is enabled, continuing to execute the step of creating the initial coroutine; if the asynchronous execution variable is disabled, executing the target transaction according to the synchronous strategy.

[0060] The asynchronous execution variable can be understood as a global variable corresponding to the asynchronous commit function. By dynamically exposing the function as a toggle switch, users can dynamically enable or disable the asynchronous commit function of transactions using SQL commands. The asynchronous execution variable can be a global variable set in the database using `set global polar_async_commit`. By changing the value of the asynchronous execution variable, the asynchronous commit function of transactions can be dynamically enabled or disabled. Accordingly, after obtaining a connection, the asynchronous execution variable can be used to determine how the current worker thread should handle the transaction of the connection. If the asynchronous execution variable determines that the asynchronous commit function is enabled, then the transaction execution needs to be performed through coroutines; if the asynchronous execution variable determines that the asynchronous commit function is disabled, then the worker thread is directly responsible for executing and processing the transaction operations on that connection.

[0061] In practice, for existing connections, before executing the next request, it checks whether global variables have changed. If they haven't changed, the original strategy continues; if they have changed, the new settings are saved in the connection object. With asynchronous commit enabled, if the existing connection's strategy is synchronous, a coroutine object is requested, and the worker thread changes the strategy to asynchronous to execute transaction requests for that connection, i.e., it continues executing the steps to create the initial coroutine. With asynchronous commit disabled, if the existing connection's strategy is asynchronous, the coroutine object is released, and the worker thread changes the strategy to synchronous. Synchronous strategy means the worker thread is directly responsible for executing and processing transaction operations on that connection. Dynamically enabling or disabling asynchronous commit has no impact on new connections. However, it should be noted that during dynamic disabling, suspended coroutine objects are actively woken up and restored, and the log write-to-disk process is checked. If not, the worker thread continues synchronous log write-to-disk waiting.

[0062] In a specific embodiment of this specification, after obtaining a connection, the worker thread will determine the asynchronous execution variable corresponding to the current connection. If the current asynchronous execution variable is set global polar_async_commit=on, it means that the asynchronous commit function is enabled. The worker thread will execute the steps of creating an initial coroutine, associating and binding the coroutine to the connection, and processing the transaction requests of the connection asynchronously through the coroutine.

[0063] Based on this, by changing the asynchronous execution variable, the asynchronous commit function can be dynamically enabled and disabled, allowing users to choose to execute connection transaction requests synchronously or asynchronously according to the actual situation. This makes it easier for users to adjust the database execution strategy according to the actual situation.

[0064] Furthermore, in order to execute the target transaction according to the first coroutine, it is necessary to determine the execution logic function of the first coroutine. Specifically, the target transaction is executed through the first coroutine associated with the worker thread to obtain the transaction log of the target transaction, including: determining the execution information of the first coroutine associated with the worker thread; and executing the target transaction through the first coroutine according to the execution information to obtain the transaction log of the target transaction.

[0065] The execution information of the first coroutine can be understood as the first function, i.e. the entry function, of the first coroutine when executing the target transaction. By determining the execution information of the first coroutine, the target transaction is then executed according to the execution information.

[0066] In practical applications, after associating a connection with a coroutine, the coroutine may involve creating a new connection during execution, or it may already be created and ready to execute SQL statements. Therefore, it's necessary to determine the coroutine's entry function. The coroutine then executes the target transaction according to this entry function, thus obtaining the transaction log. The transaction log can be understood as the log of operations generated by the coroutine after executing SQL statements. Under the transaction mechanism provided by the InnoDB storage engine, once a transaction is committed, its changes are permanent and will not be lost even if the system fails. To ensure this, the database system typically writes the transaction log (redo log) to disk, which is a combination of log entries for the data operations corresponding to each SQL statement within a transaction.

[0067] In summary, the first coroutine executes the target transaction using the determined execution information, i.e., the entry function, and generates corresponding transaction logs. This facilitates subsequent rollback or recovery operations based on the transaction logs, thereby ensuring the integrity and consistency of data in the database.

[0068] Furthermore, obtaining the transaction log of the target transaction by executing the target transaction according to the execution information through the first coroutine includes: executing the target transaction according to the execution information through the first coroutine to obtain the execution record corresponding to the execution information; and generating the transaction log of the target transaction based on the execution record.

[0069] Among them, the execution record corresponding to the execution information can be understood as the execution record of the operation of the coroutine during the execution of the target transaction. It can be the execution record of the SQL statement. The transaction log of the target transaction can be generated through the execution record.

[0070] In practical applications, the transaction log is also known as the redo log. The main purpose of the transaction log is to recover incomplete transactions after a system crash or abnormal shutdown, ensuring data consistency and integrity. The redo log records all physical changes made to the database (such as insert, update, or delete operations). These log entries are used to reapply (i.e., "redo") changes that have not yet been permanently saved to the data files when the database restarts, thus ensuring transaction durability. When a transaction is executed, the relevant redo log records are written to the redo log buffer before the transaction is committed and flushed from the buffer to the redo log file on disk when appropriate.

[0071] In a specific embodiment of this specification, the first coroutine executes the target transaction according to the execution information. When executing the first update statement, a corresponding redo log record is generated and written to the redo log buffer. When executing the second update statement, a redo log record is similarly generated and written to the buffer. Subsequently, during transaction commit, the log record corresponding to the transaction in the redo log buffer is stored to disk, thus completing the log write-to-disk operation.

[0072] Based on this, by generating a transaction log for the target transaction according to the execution record, the database can recover incomplete transactions in the event of a crash or anomaly, ensuring data consistency and integrity.

[0073] Step 204: Send the transaction commit task of the target transaction to the log storage thread, and release the worker thread by suspending the first coroutine, wherein the log storage thread is used to store the transaction log.

[0074] The transaction commit task for the target transaction can be understood as the task of committing the target transaction. After the target transaction is completed, it needs to be committed, which requires writing the transaction log to disk. The worker thread sends the transaction commit task to the log storage thread, which can be understood as the thread that stores the transaction log.

[0075] In practical applications, when a transaction is committed, it is necessary to ensure that the transaction log is written to the storage system. At this time, the worker thread will notify the background log writer thread that there is a transaction log that needs to be written to disk. Therefore, the worker thread will send the transaction commit task to the log storage thread, which will execute the log write operation in the transaction commit task. Through the transaction commit task, the log storage thread can determine the target transaction and the corresponding transaction log that needs to be stored.

[0076] In practice, after notifying the log storage thread, the worker thread does not enter a sleep state. Instead, it suspends the first coroutine using the `conn_task_suspend` function. After suspending the current coroutine, the worker thread can immediately return to the `get_event` logic to continue acquiring and processing other client connections that need to execute SQL statements. The advantage of this approach is that even while waiting for log writing to complete, the worker thread is not idle but can better utilize resources, improving the overall throughput of the database.

[0077] Furthermore, before sending the transaction commit task of the target transaction to the log storage thread, the method further includes: obtaining a transaction commit command through the first connection corresponding to the target transaction; and generating a transaction commit task in response to the transaction commit command.

[0078] The transaction commit command can be understood as a command sent by the application to commit the target transaction. The transaction commit command can be a commit command. After the worker thread receives the transaction commit command, it will trigger the transaction commit process, generate the transaction commit command, and notify the coroutine or other threads such as the log storage thread and the listening thread to cooperate in the processing.

[0079] In practical applications, the client application can determine whether an operation has been successfully completed based on the return result of each SQL statement's transaction operation. If an operation fails, the application can choose to immediately terminate the transaction and roll back all changes made (by sending a rollback command). If all SQL operations are successfully completed, the application sends a transaction commit command to the database. The worker thread can receive the transaction commit command through the first connection, generate a transaction commit task, and thus initiate the transaction commit process.

[0080] Based on this, the transaction commit process can be triggered by the transaction commit task, which makes it easier to store the transaction log of the target transaction when the transaction is committed, so that the database system can guarantee data consistency and durability.

[0081] Furthermore, before releasing the worker thread by suspending the first coroutine, the method further includes: determining the log sequence information of the transaction log; adding the first connection to the connection wait list according to the log sequence information, wherein the log storage thread stores logs of the connections in the connection wait list according to the log sequence information; and detecting the connections in the connection wait list based on the stored information by the log notification thread, and obtaining the detection results returned by the log notification thread by the listening thread.

[0082] The log sequence information can be understood as the log sequence number, which is a unique identifier used by the database system to identify the order of redo log entries. Each time a new redo log entry is generated, a new, incrementing LSN value is assigned. The log sequence number is crucial for ensuring the order of log entries and the correctness of the recovery process. The connection wait list can be understood as a list of connections waiting for redo log writes to complete. When a transaction needs to wait for its redo log to be written to disk before it can continue (e.g., commit), it is added to this list. The connection wait list aims to ensure that these connections can continue execution in the correct order. Arranging these connections according to their LSN order ensures that all operations are executed in the correct order, thereby maintaining data consistency and transaction isolation.

[0083] In practical applications, when a transaction is committed, the transaction log of the target transaction needs to be written to disk. At this time, the worker thread will determine the log sequence information of the transaction log and add the connection to the connection wait list according to the log sequence information. Subsequently, the log storage thread will store the transaction log corresponding to each connection in the connection wait list according to the log sequence information.

[0084] In practice, worker threads also register the file descriptor (eventfd) objects in the connection with the epoll instance in the thread pool. The listener thread then monitors whether the transaction logs have been written to disk. Specifically, the log notification thread checks the connections in the connection wait list according to the stored information. It determines whether the corresponding transaction logs have been written to disk based on the stored information, generates a write-to-disk completion result, and sends this result to the listener thread via the eventfd object. The listener thread receives the result and proceeds with further processing of the connection based on the result.

[0085] In a specific embodiment of this specification, while waiting for the redo log to complete, the worker thread suspends the first coroutine using the `conn_task_suspend` function to avoid blocking the worker thread. The worker thread registers the `eventfd` object in the connection with the `epoll` instance of the thread pool. `eventfd` is a special file descriptor used for event notification between processes or threads. After registration with the `epoll` instance, the listener thread can listen to these `eventfd`s through the `epoll` mechanism to receive notifications after the redo log is written. The background log writing thread is responsible for writing the redo log from the memory buffer to disk. After the log is written, the log notifier thread checks the waiter list to find all coroutines that are suspended and whose corresponding redo logs have been written to disk. For each coroutine that meets the conditions, the log notifier thread sends a write completion message through its associated `eventfd`. The listener thread listens to all registered `eventfd`s using `epoll_wait`. When an event occurs on a certain `eventfd` (i.e., a write completion message is received), the listener thread processes the event.

[0086] In summary, by employing efficient I / O multiplexing mechanisms (such as epoll) combined with eventfd for event notification, an efficient asynchronous log writing and transaction commit process is achieved. This not only improves the system's concurrent processing capabilities but also ensures data consistency and reliability.

[0087] Furthermore, if the detection result is log writing, the method further includes: selecting the first connection from the connection waiting list through a listening thread and adding the first connection to the asynchronous preparation queue; obtaining the first connection based on the asynchronous preparation queue, determining the first coroutine corresponding to the first connection, continuing to perform a recovery operation on the first coroutine, and continuing to execute the transaction commit task through the first coroutine.

[0088] After the listening thread receives the write completion message, it selects the first connection from the connection waiting list and adds it to the asynchronous preparation queue. The asynchronous preparation queue stores asynchronous tasks that are ready but not yet executed. Therefore, the worker thread needs to perform further scheduling processing on the first connection in the asynchronous preparation queue. Specifically, the worker thread obtains the first connection based on the asynchronous preparation queue, determines the corresponding first coroutine, resumes the suspended first coroutine, and continues executing the transaction commit task corresponding to the target transaction under that connection.

[0089] In practical applications, when it detects that the redo log of a client connection has been written to disk, it places that connection in the asynchronous ready queue of the thread pool, ensuring that transactions waiting for the redo log to be written can be processed as quickly as possible. Worker threads retrieve connections marked as completed from the asynchronous ready queue, use the `conn_task_resume` function to restore the coroutine context corresponding to that connection, allowing it to continue executing other logic after the transaction commit, such as cleaning up and releasing memory resources occupied by the transaction.

[0090] Based on this, after the listening thread receives the message that the write is complete, it adds the first connection to the asynchronous preparation queue, so that the first connection can be resumed and processed by the worker thread as soon as possible. The worker thread resumes the coroutine corresponding to the connection that has been written, thereby improving the system's concurrency processing capability and efficiency.

[0091] Furthermore, in order to improve the system's concurrent processing capability and efficiency, while suspending the first coroutine, the worker thread can be allowed to handle transactions under other connections. Specifically, after releasing the worker thread by suspending the first coroutine, the method further includes: determining the second connection associated with the second coroutine; and executing the transaction corresponding to the second connection based on the second coroutine.

[0092] Here, the second connection can be understood as any connection other than the first connection, and the second coroutine can be understood as a coroutine associated with the second connection. Through the second coroutine, the transactions contained under the second connection can be executed.

[0093] In practical applications, after a worker thread suspends the first coroutine associated with the first connection, to avoid wasting time waiting for logs to be written to disk, while the first coroutine is suspended to write the transaction log of the target transaction to disk, the worker thread can execute transactions for other connections. Specifically, the worker thread can use the `get_event` logic to obtain other client connections that need to execute SQL and continue execution, allowing a single worker thread to handle multiple transaction requests concurrently, thus improving thread processing efficiency.

[0094] Step 206: Upon receiving the storage information returned by the log storage thread, perform a recovery operation on the first coroutine and continue executing the transaction commit task through the first coroutine.

[0095] As described above, once the worker thread confirms that the transaction log of the connection has been written, it will reply to the first coroutine, and the first coroutine will continue to execute the transaction commit task.

[0096] In practical applications, the log notification thread checks the connections in the connection waiting queue based on the storage information returned by the log storage thread. When it detects that a connection has completed log writing based on the storage information, it notifies the listening thread, which then removes the connection from the connection waiting queue and adds it to the asynchronous preparation queue. The worker thread then performs the next scheduling process on the connections in the asynchronous preparation queue.

[0097] This specification provides a data processing method applied to worker threads in a database management system. The method includes executing a target transaction through a first coroutine associated with the worker thread to obtain the transaction log of the target transaction; sending the transaction commit task of the target transaction to a log storage thread; and releasing the worker thread by suspending the first coroutine, wherein the log storage thread is used to store the transaction log. Upon receiving storage information returned by the log storage thread, the first coroutine is resumed, and the transaction commit task continues to be executed through the first coroutine. Based on worker threads in a database management system, the target transaction is executed through a first coroutine associated with the worker thread during transaction request scheduling, thus reducing the operating system's overhead on thread scheduling. During the transaction log write-to-disk operation, the transaction commit task of the target transaction is sent to the log storage thread, and the first coroutine is suspended to release the worker thread. This allows the released worker thread to be scheduled and switched to other connections or transactions for processing while the log storage thread performs the log write-to-disk operation, meeting the needs of high-concurrency transaction request scenarios, avoiding multi-threaded lock contention, improving database throughput while also improving thread execution efficiency, and ensuring good database write performance.

[0098] The above is combined with the appendix Figure 3 Taking the application of the data processing method provided in this specification to an order database as an example, the data processing method will be further explained. Figure 3 A flowchart illustrating the processing procedure of a data processing method according to an embodiment of this specification is shown, specifically including the following steps.

[0099] Step 302: Obtain the first connection and determine the target transaction corresponding to the first connection.

[0100] In one feasible approach, the client application is a shopping application through which users can place orders. The backend service receives the order requests and persists the order information to a database. The application establishes a first connection with the database provided by the backend service and determines the target transaction corresponding to the first connection. The target transaction may include data operations for inserting orders.

[0101] Step 304: Create an initial coroutine and associate it with the first connection to obtain the first coroutine.

[0102] In one feasible approach, the asynchronous execution variable corresponding to the first connection is determined. Based on the asynchronous execution variable, if the asynchronous transaction commit function is enabled, an initial coroutine is created, and the initial coroutine is associated with the first connection to obtain the first coroutine.

[0103] Step 306: Determine the execution information of the first coroutine associated with the worker thread, execute the target transaction according to the execution information through the first coroutine, obtain the execution record corresponding to the execution information, and generate the transaction log of the target transaction based on the execution record.

[0104] In one feasible approach, the execution information of the first coroutine, i.e. the entry function, is determined, the target transaction is executed according to the entry function, the operation execution record corresponding to the SQL statement is obtained, and a transaction log (redo log) is generated based on the execution record.

[0105] Step 308: Obtain the transaction commit command through the first connection corresponding to the target transaction, and generate a transaction commit task in response to the transaction commit command.

[0106] In one feasible approach, after the application confirms that the SQL statement returns a normal result, it sends a transaction commit command to the database. Once the worker thread receives the transaction commit command, it generates a transaction commit task.

[0107] Step 310: Send the transaction commit task of the target transaction to the log storage thread.

[0108] In one possible approach, the worker thread sends the transaction commit task to the log storage thread, notifying the log storage thread to perform the redo log write operation.

[0109] Step 312: Determine the log sequence information of the transaction log, and add the first connection to the connection wait list according to the log sequence information.

[0110] In one possible implementation, the worker thread determines the Log Sequence Number (LSN) of the transaction log and adds the first connection to the connection wait list according to the LSN.

[0111] Step 314: Release the worker thread by suspending the first coroutine, determine the association of the second connection with the second coroutine, and execute the transaction corresponding to the second connection based on the second coroutine.

[0112] In one possible approach, the worker thread suspends the first coroutine, determines the second connection and its corresponding second coroutine through an event acquisition function, and then uses the second coroutine to execute the transaction corresponding to the second connection.

[0113] Step 316: The log notification thread checks the connections in the connection wait list based on the stored information, and the listening thread obtains the detection results returned by the log notification thread.

[0114] In one possible implementation, the log notifier thread checks the connections in the wait list based on stored information, and returns the detection result to the listener thread when it determines that the transaction log of the connection has been written.

[0115] Step 318: Select the first connection from the connection waiting list through the listening thread and add the first connection to the asynchronous preparation queue.

[0116] In one possible implementation, the listener thread identifies the first connection in the waiter list and adds it to the asynchronous ready queue, waiting for the worker thread to schedule it.

[0117] Step 320: Obtain the first connection based on the asynchronous preparation queue, determine the first coroutine corresponding to the first connection, continue to perform the recovery operation on the first coroutine, and continue to execute the transaction commit task through the first coroutine.

[0118] In one feasible approach, the worker thread obtains the first connection from the asynchronous ready queue and resumes the first thread corresponding to that connection, thus continuing to execute other operations of the transaction commit task through the first coroutine. After the transaction is committed, the relevant operations on the order data are completed.

[0119] The data processing method provided in this manual implements transaction request scheduling using coroutines, reducing the operating system's overhead on thread scheduling. During transaction log write-to-disk operations, the target transaction's transaction commit task is sent to the log storage thread, and the first coroutine is suspended to release the worker thread. This allows the released worker thread to be scheduled and switched to other connections or transactions for processing while the log storage thread performs the log write-to-disk operation. This meets the needs of high-concurrency transaction request scenarios, avoids multi-threaded lock contention, improves database throughput while also increasing thread execution efficiency, and ensures good database write performance.

[0120] Corresponding to the above method embodiments, this specification also provides data processing system embodiments. Figure 4 A schematic diagram of the structure of a data processing system according to one embodiment of this specification is shown. Figure 4As shown, the system includes worker thread 402 and log storage thread 404, wherein,

[0121] The worker thread 402 is used to execute the target transaction through the first coroutine, obtain the transaction log of the target transaction, send the transaction commit task of the target transaction to the log storage thread, and release the worker thread by suspending the first coroutine.

[0122] The log storage thread 404 is used to store the transaction log, obtain the storage information, and return it to the worker thread;

[0123] The worker thread 402 is used to perform a recovery operation on the first coroutine based on the stored information, and to continue executing the transaction commit task through the first coroutine.

[0124] The processing procedure of the data processing system provided in this manual can be found in the detailed description of the data processing method described above, and will not be repeated here. The data processing system provided in this manual implements transaction request scheduling using coroutines, reducing the operating system's overhead on thread scheduling. When performing transaction log write-to-disk operations, the transaction commit task of the target transaction is sent to the log storage thread, and the first coroutine is suspended to release the worker thread. This allows the released worker thread to be scheduled and switched to other connections or transactions for processing while the log storage thread performs the log write-to-disk operation, meeting the needs of high-concurrency transaction request scenarios, avoiding multi-threaded lock contention, improving database throughput while also improving thread execution efficiency, and ensuring good database write performance.

[0125] Corresponding to the above method embodiments, this specification also provides data processing apparatus embodiments. Figure 5 A schematic diagram of the structure of a data processing apparatus according to one embodiment of this specification is shown. Figure 5 As shown, the device includes:

[0126] The execution module 502 is configured to execute the target transaction through the first coroutine associated with the worker thread and obtain the transaction log of the target transaction;

[0127] The suspension module 504 is configured to send the transaction commit task of the target transaction to the log storage thread, and to release the worker thread by suspending the first coroutine, wherein the log storage thread is used to store the transaction log;

[0128] The recovery module 506 is configured to perform a recovery operation on the first coroutine upon receiving storage information returned by the log storage thread, and to continue executing the transaction commit task through the first coroutine.

[0129] Optionally, the device further includes an association module configured to acquire a first connection and determine the target transaction corresponding to the first connection; create an initial coroutine and associate the initial coroutine with the first connection to obtain the first coroutine.

[0130] Optionally, the association module is further configured to determine the asynchronous execution variable corresponding to the first connection; if the asynchronous execution variable is enabled, continue to execute the step of creating the initial coroutine; if the asynchronous execution variable is disabled, execute the target transaction according to the synchronization strategy.

[0131] Optionally, the execution module 502 is further configured to determine the execution information of the first coroutine associated with the worker thread; and to execute the target transaction through the first coroutine according to the execution information to obtain the transaction log of the target transaction.

[0132] Optionally, the execution module 502 is further configured to execute the target transaction according to the execution information through the first coroutine, obtain the execution record corresponding to the execution information, and generate a transaction log of the target transaction based on the execution record.

[0133] Optionally, the apparatus further includes a generation module configured to obtain a transaction commit command through a first connection corresponding to the target transaction; and generate a transaction commit task in response to the transaction commit command.

[0134] Optionally, the device further includes an adding module configured to determine the log sequence information of the transaction log; add the first connection to the connection wait list according to the log sequence information, wherein the log storage thread stores logs of the connections in the connection wait list according to the log sequence information; and detect the connections in the connection wait list based on the stored information through a log notification thread, and obtain the detection results returned by the log notification thread through a listening thread.

[0135] Optionally, the device further includes a selection module configured to select the first connection from the connection waiting list via a listening thread, add the first connection to an asynchronous preparation queue, obtain the first connection based on the asynchronous preparation queue, determine the first coroutine corresponding to the first connection, continue to perform a recovery operation on the first coroutine, and continue to execute the transaction commit task through the first coroutine.

[0136] Optionally, the apparatus further includes a determining module configured to determine a second connection associated with a second coroutine; and to execute a transaction corresponding to the second connection based on the second coroutine.

[0137] This specification provides a data processing device that implements transaction request scheduling using coroutines, reducing the operating system's overhead on thread scheduling. During transaction log write-to-disk operations, the target transaction's transaction commit task is sent to the log storage thread, and the first coroutine is suspended to release the worker thread. This allows the released worker thread to be scheduled and switched to other connections or transactions for processing while the log storage thread performs the log write-to-disk operation. This meets the needs of high-concurrency transaction request scenarios, avoids multi-threaded lock contention, improves database throughput while also increasing thread execution efficiency, and ensures good database write performance.

[0138] The above is an illustrative scheme of a data processing apparatus according to this embodiment. It should be noted that the technical solution of this data processing apparatus and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the data processing apparatus, please refer to the description of the technical solution of the data processing method described above.

[0139] Figure 6 A structural block diagram of a computing device 600 according to one embodiment of this specification is shown. The components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and a database 650 is used to store data.

[0140] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a network interface controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0141] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0142] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0143] The processor 620 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described data processing method.

[0144] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the data processing method described above.

[0145] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described data processing method.

[0146] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the data processing method described above.

[0147] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described data processing method.

[0148] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the data processing method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the data processing method described above.

[0149] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0150] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0151] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0152] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0153] The preferred embodiments disclosed above are merely illustrative of this specification. Optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described in this specification. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification.

Claims

1. A data processing method, applied to a worker thread in a database management system, comprising: The target transaction is executed by the first coroutine associated with the worker thread, and the transaction log of the target transaction is obtained. The transaction commit task of the target transaction is sent to the log storage thread, and the worker thread is released by suspending the first coroutine, wherein the log storage thread is used to store the transaction log; Upon receiving the storage information returned by the log storage thread, a recovery operation is performed on the first coroutine, and the transaction commit task continues to be executed through the first coroutine.

2. The method according to claim 1, before executing the target transaction through the first coroutine associated with the worker thread, the method further includes: Obtain the first connection and determine the target transaction corresponding to the first connection; Create an initial coroutine and associate the initial coroutine with the first connection to obtain a first coroutine.

3. The method according to claim 2, wherein before creating the initial coroutine, the method further comprises: Determine the asynchronous execution variables corresponding to the first connection; If the asynchronous execution variable is enabled, continue executing the steps to create the initial coroutine; When the asynchronous execution variable is turned off, the target transaction is executed according to the synchronous strategy.

4. The method according to claim 1, wherein the target transaction is executed through a first coroutine associated with the worker thread to obtain the transaction log of the target transaction, comprising: Determine the execution information of the first coroutine associated with the worker thread; The first coroutine executes the target transaction according to the execution information to obtain the transaction log of the target transaction.

5. The method according to claim 4, wherein the first coroutine executes the target transaction according to the execution information to obtain the transaction log of the target transaction, comprising: The first coroutine executes the target transaction according to the execution information to obtain the execution record corresponding to the execution information; The transaction log of the target transaction is generated based on the execution records.

6. The method according to claim 1, before sending the transaction commit task of the target transaction to the log storage thread, the method further includes: Obtain the transaction commit command through the first connection corresponding to the target transaction; A transaction commit task is generated in response to the transaction commit command.

7. The method according to claim 6, further comprising, before releasing the worker thread by suspending the first coroutine: Determine the log sequence information of the transaction log; The first connection is added to the connection waiting list according to the log sequence information, wherein the log storage thread stores logs of the connections in the connection waiting list according to the log sequence information; The log notification thread detects connections in the connection wait list based on the stored information, and the listening thread obtains the detection results returned by the log notification thread.

8. The method according to claim 7, wherein if the detection result is a log write, the method further comprises: The listening thread selects the first connection from the connection waiting list and adds the first connection to the asynchronous preparation queue. The steps of obtaining the first connection based on the asynchronous preparation queue, determining the first coroutine corresponding to the first connection, continuing to perform the recovery operation on the first coroutine, and continuing to execute the transaction commit task through the first coroutine.

9. The method according to claim 1, after releasing the worker thread by suspending the first coroutine, the method further includes: Determine the association between the second connection and the second coroutine; The transaction corresponding to the second connection is executed based on the second coroutine.

10. A database management system, the system comprising worker threads and log storage threads, wherein, The worker thread is used to execute the target transaction through the first coroutine, obtain the transaction log of the target transaction, send the transaction commit task of the target transaction to the log storage thread, and release the worker thread by suspending the first coroutine. The log storage thread is used to store the transaction log, obtain the storage information, and return it to the worker thread; The worker thread is used to perform a recovery operation on the first coroutine based on the stored information, and to continue executing the transaction commit task through the first coroutine.

11. A data processing apparatus, applied to a worker thread in a database management system, comprising: The execution module is configured to execute the target transaction through a first coroutine associated with the worker thread and obtain the transaction log of the target transaction; The suspension module is configured to send the transaction commit task of the target transaction to the log storage thread, and to release the worker thread by suspending the first coroutine, wherein the log storage thread is used to store the transaction log; The recovery module is configured to perform a recovery operation on the first coroutine upon receiving storage information returned by the log storage thread, and to continue executing the transaction commit task through the first coroutine.

12. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the data processing method according to any one of claims 1 to 9.

13. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the data processing method according to any one of claims 1 to 9.

14. A computer program product comprising a computer program or instructions which, when executed by a processor, implement the steps of the data processing method according to any one of claims 1 to 9.

Images