Database double-write synchronization method and device, storage medium and program product

Abstract

The invention discloses a database double-write synchronization method and device, a storage medium and a program product, and relates to the technical field of data processing.The database double-write synchronization method comprises the steps that before transaction ending operation, whether an asynchronous thread executor completes a future task in a blocking queue or not is judged, and if yes, the asynchronous thread executor completes the future task in the blocking queue; if yes, the transaction ending task is added into the blocking queue, so that an asynchronous thread executor performs the same transaction ending operation as the main thread when receiving the transaction ending task, and the main thread executes the transaction ending operation when obtaining the member variable value of the asynchronous thread. According to the method, multiple SQL statements can be executed in the same transaction through the future tasks and the blocking queues, the current transaction is ended only after the asynchronous thread executor completes all the future tasks by adding the transaction ending tasks, and the transaction is synchronously ended by the main thread when the transaction of the asynchronous thread executor is ended by obtaining the member variable value, so that the transaction is synchronously ended, and the transaction efficiency is improved. And the data submitted or rolled back by the transaction is consistent.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to database dual-write synchronization methods, devices, storage media, and program products. Background Technology

[0002] Database dual-write is a method that uses an asynchronous thread executor to synchronously write data to an additionally configured database, based on the original program's single data source.

[0003] In the current dual-write database method, for the asynchronous thread executor that writes data to an additional database, each execution is a new and separate transaction. If an error occurs inside the program and the main data source rolls back the data, the asynchronous thread executor has already committed the previous transaction, resulting in inconsistency between the data committed and rolled back during the dual-write database process. Summary of the Invention

[0004] The main purpose of this application is to provide a database dual-write synchronization method, device, storage medium, and program product, which aims to solve the technical problem of data inconsistency between transaction commit and transaction rollback.

[0005] To achieve the above objectives, this application proposes a database dual-write synchronization method applied to the main thread of a database dual-write system. The database dual-write system further includes an asynchronous thread executor, wherein the main thread and the asynchronous thread execute the same SQL statement. The method includes:

[0006] Before starting the transaction termination operation for the main thread transaction locally, it is determined whether the asynchronous thread executor has completed all future tasks in the blocking queue. The transaction termination operation includes transaction commit and transaction rollback. The asynchronous thread executor continuously receives tasks in the blocking queue based on a preset loop function. The future tasks are obtained locally by encapsulating the SQL statement through a preset task addition function. The execution result of the future tasks is obtained locally based on a preset result retrieval function.

[0007] If all tasks are completed, the transaction completion task is added to the blocking queue so that the asynchronous thread executor can receive tasks from the blocking queue. If the transaction completion task is received, the asynchronous thread transaction of the asynchronous thread executor is terminated based on the transaction completion operation of the main thread.

[0008] Based on the result retrieval function, a variable value retrieval operation is performed on the member variables of the asynchronous thread executor, wherein the asynchronous thread executor is created locally and encapsulated as the future task, the member variable is the future task in the blocking queue, and the variable value retrieval operation is in a blocked state before the asynchronous thread transaction is completed;

[0009] When the value of the member variable is obtained, the transaction termination operation for the main thread transaction is executed.

[0010] In one embodiment, the database dual-write system further includes an interceptor for intercepting the SQL statements. The main thread transaction includes a transaction ID and multiple SQL statements. Before the step of determining whether the asynchronous thread executor has completed all future tasks in the blocking queue before starting the transaction termination operation for the main thread transaction locally, the system further includes:

[0011] When the SQL statement enters the interceptor, the transaction ID of the main thread transaction is obtained;

[0012] Based on the transaction status tag of the target transaction corresponding to the transaction ID, determine whether the target transaction is in an active state;

[0013] If it is active, it iterates through all transaction managers to determine if a custom transaction listener exists.

[0014] If it exists, then based on the transaction ID, determine whether the asynchronous thread executor corresponding to the target transaction exists in the cache;

[0015] If it exists, then based on the transaction listener, perform a dual-write operation on the database using both the local database and the asynchronous thread executor.

[0016] In one embodiment, if present, the steps of performing a dual database write operation based on the transaction listener and the asynchronous thread executor include:

[0017] The SQL statement is encapsulated into a future task by a preset task addition function and added to the blocking queue so that the asynchronous thread executor can perform the database double write operation based on the transaction listener.

[0018] Based on the result retrieval function, the execution result of the asynchronous thread executor for the SQL statement is obtained, thus obtaining the asynchronous execution result;

[0019] Execute the SQL statement to obtain the main execution result;

[0020] Determine whether the main execution result and the asynchronous execution result are consistent. If they are inconsistent, issue an alarm.

[0021] In one embodiment, the step of encapsulating the SQL statement into the future task and adding it to the blocking queue using a preset task addition function includes:

[0022] Based on the SQL statement, determine the corresponding mapping statement, pagination parameters, result executor, and input parameters, and determine the mapping ID corresponding to the mapping statement;

[0023] Perform a deep copy on the input parameters to obtain the deep copy input parameters;

[0024] Based on the mapping ID, the deep copy input parameters, the pagination parameters, and the result executor, the SQL statement is encapsulated into the future task through the task addition function and added to the blocking queue.

[0025] To achieve the above objectives, this application also proposes a database dual-write synchronization method, applied to the asynchronous thread executor of a database dual-write system. The database dual-write system further includes a main thread, and the main thread and the asynchronous thread execute the same SQL statements. The method includes:

[0026] Based on a preset loop function, tasks in the blocking queue are continuously received. The tasks in the blocking queue include future tasks and transaction end tasks. The future tasks are obtained by the main thread after encapsulating the SQL statement through a preset task addition function. The execution result of the future tasks is obtained locally based on a preset result retrieval function. The transaction end tasks are added to the blocking queue by the main thread after all the future tasks in the blocking queue have been completed locally.

[0027] If the transaction completion task is received, the asynchronous thread executor transaction of the asynchronous thread executor is terminated based on the transaction completion operation of the main thread, so that the main thread can perform variable value retrieval operation for the member variables of the asynchronous thread executor based on the result retrieval function. When the variable value of the member variable is obtained, the transaction completion operation for the main thread transaction is executed. The transaction completion operation includes transaction commit and transaction rollback. The asynchronous thread executor is created by the main thread and encapsulated as the future task. The member variable is the future task in the blocking queue. The variable value retrieval operation is in a blocked state before the asynchronous thread executor transaction is completed.

[0028] In one embodiment, the step of continuously receiving tasks from the blocking queue based on a preset loop function includes:

[0029] The task in the blocking queue is retrieved using a preset task retrieval function;

[0030] Determine whether the current task is the task that ends with the transaction;

[0031] If the transaction is not terminated, the current task is executed, and the step of retrieving the task in the blocking queue through the preset task retrieval function is returned until the transaction termination task is received.

[0032] In one embodiment, the asynchronous thread executor has a corresponding asynchronous database, which is connected to the asynchronous thread executor when it is created. The step of executing the current task if the transaction is not terminated includes:

[0033] Obtain the SQL session factory and database interface of the asynchronous database;

[0034] Based on the mapping ID, deep copy input parameters, pagination parameters, and result executor in the future task, the corresponding mapping SQL statement is determined through the SQL session factory;

[0035] Based on the aforementioned database interface, an SQL statement executor is created;

[0036] Based on the SQL statement executor, the mapped SQL statement is executed to obtain asynchronous execution results.

[0037] In addition, to achieve the above objectives, this application also proposes a database dual-write synchronization device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the database dual-write synchronization method as described above.

[0038] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the database dual-write synchronization method described above.

[0039] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the database dual-write synchronization method described above.

[0040] One or more technical solutions proposed in this application have at least the following technical effects:

[0041] Before performing the transaction termination operation for the main thread transaction locally, this application determines whether the asynchronous thread executor has completed all future tasks in the blocking queue. If all tasks are completed, the transaction termination task is added to the blocking queue so that the asynchronous thread executor can receive tasks from the blocking queue. If the transaction termination task is received, the asynchronous thread transaction of the asynchronous thread executor is terminated based on the transaction termination operation of the main thread. Based on the result retrieval function, the variable value retrieval operation for the member variables of the asynchronous thread executor is performed. When the variable value of the member variable is obtained, the transaction termination operation for the main thread transaction is executed.

[0042] Compared to current dual-write database methods, where each execution is a new, separate transaction, and errors occur within the program leading to data rollback by the main data source, the asynchronous thread executor has already committed the previous transaction, causing data inconsistency issues. This application encapsulates the SQL statements to be executed as future tasks and adds them to a blocking queue. A loop function allows the asynchronous thread executor to continuously receive these future tasks. Since the execution results of future tasks are obtained by the main thread through a predefined function, the asynchronous thread executor only needs to continuously loop to obtain and execute future tasks, thus executing multiple SQL statements within a single transaction within an asynchronous thread executor. Furthermore, since the asynchronous thread executor is created by the main thread and encapsulated as a future task, and its member variables are the future tasks in the blocking queue, the main thread's operation to retrieve the values ​​of these member variables is blocked until the asynchronous thread executor's transaction is complete. Therefore, if the main thread obtains the values ​​of the asynchronous thread executor's member variables, it indicates that the asynchronous thread transaction corresponding to the asynchronous thread executor has been fully processed, and the main thread can then synchronously perform a transaction commit or rollback operation for its own transaction.

[0043] This application enables multiple SQL queries to be executed in the main thread and asynchronous thread executors to run in a single thread through the above operations. Transaction commit and rollback operations are performed synchronously, preventing data consistency issues caused by the main thread rolling back while the asynchronous thread executor has already committed. This improves data consistency during database dual-write processes, particularly in the context of transaction commit and rollback. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating an embodiment of the database dual-write synchronization method of this application.

[0047] Figure 2 This is a schematic diagram of the first scenario provided in Embodiment 1 of the database dual-write synchronization method of this application;

[0048] Figure 3 This is a schematic diagram of the second scenario provided in Embodiment 1 of the database dual-write synchronization method of this application;

[0049] Figure 4 This is a schematic diagram of the third scenario provided in Embodiment 1 of the database dual-write synchronization method of this application;

[0050] Figure 5 This is a schematic diagram of the fourth scenario provided in Embodiment 1 of the database dual-write synchronization method of this application;

[0051] Figure 6 This is a schematic diagram of the fifth scenario provided in Embodiment 1 of the database dual-write synchronization method of this application;

[0052] Figure 7 This is a schematic diagram of the sixth scenario provided in Embodiment 1 of the database dual-write synchronization method of this application;

[0053] Figure 8 This is a schematic diagram of the seventh scenario provided in Embodiment 1 of the database dual-write synchronization method of this application;

[0054] Figure 9 This is a flowchart illustrating Embodiment 2 of the database dual-write synchronization method of this application.

[0055] Figure 10 This is a schematic diagram of the first scenario provided in Embodiment 2 of the database dual-write synchronization method of this application;

[0056] Figure 11 This is a schematic diagram of the device structure of the hardware operating environment involved in the database dual-write synchronization method in the embodiments of this application;

[0057] Figure 12 This is a schematic diagram illustrating the data acquisition consent process involved in the database dual-write synchronization method in this application embodiment.

[0058] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0059] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0060] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0061] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or database dual-write synchronization device capable of performing the above functions. The following description uses a database dual-write synchronization device as an example to illustrate this embodiment and the subsequent embodiments.

[0062] Database dual-write is a method that uses an asynchronous thread executor to synchronously write data to an additionally configured database, based on the original program's single data source.

[0063] In the dual-write mechanism of traditional Spring (Spring Boot, a Java framework) projects, each execution of the asynchronous thread executor that writes data to an additional database is a new and separate transaction. If an error occurs inside the program and the main data source rolls back the data, the asynchronous thread executor has already committed the previous transaction, resulting in inconsistency between the data committed and rolled back during the dual-write process.

[0064] Currently, MyBatis (a persistence layer code framework) is typically implemented within an ORM (Object-Relational Mapping) framework module. This involves intercepting SQL (Structured Query Language) queries at the aspect layer to achieve dual writes to the mapper persistence layer. However, when using MyBatisPlu (another persistence layer code framework), intercepting queries at the aspect layer and implementing dual writes to the mapper persistence layer via aspect-based technology can lead to compatibility issues related to transaction management and SQL execution control.

[0065] Based on this, this application provides a database dual-write synchronization method applied to the main thread of a database dual-write system. The database dual-write system further includes an asynchronous thread executor, wherein the main thread and the asynchronous thread execute the same SQL statement, as described above. Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the database dual-write synchronization method of this application.

[0066] In this embodiment, the database dual-write synchronization method includes steps S10 to S40:

[0067] Step S10: Before starting the transaction end operation for the main thread transaction locally, determine whether the asynchronous thread executor has completed all future tasks in the blocking queue. The transaction end operation includes transaction commit and transaction rollback. The asynchronous thread executor continuously receives tasks in the blocking queue based on a preset loop function. The future tasks are obtained locally by encapsulating the SQL statement through a preset task addition function. The execution result of the future tasks is obtained locally based on a preset result retrieval function.

[0068] It should be noted that the main thread transaction refers to the database transaction initiated by the main business logic thread in application frameworks such as Spring. Its lifecycle is controlled by Spring's transaction manager, including transaction initiation, commit, and rollback. Transaction completion operations refer to the actions that the main thread transaction is about to complete, including transaction commit and rollback. The asynchronous thread executor is an executor independent of the main thread, used to asynchronously execute database dual-write tasks. The persistence sequence of database dual-write in this embodiment can be found in [reference needed]. Figure 2 For specific operations of each persistence sequence during database dual-write, please refer to... Figure 3 .

[0069] A blocking queue is a thread-safe queue used to pass tasks between the main thread and asynchronous thread executors. When the queue is full, the main thread is blocked; when the queue is empty, the asynchronous thread is blocked, thus ensuring that tasks are processed in an orderly manner. A future task is an asynchronous task encapsulated by the main thread, representing a computation result that has not yet been completed. The main thread can later retrieve the execution result or status using the `get` method. The default task addition function is a method defined in the code used to encapsulate SQL operations into future tasks and submit them to the blocking queue.

[0070] The preset result retrieval function is used to obtain the execution result or status of the asynchronous task from the future task object. In this embodiment, the result retrieval function is the get method. The get method has a blocking waiting characteristic and will continue to wait until the task is completed.

[0071] Understandably, in the current dual-write process, each execution of the asynchronous thread database is a new and separate transaction. This can lead to the asynchronous operation being committed independently when the main transaction is rolled back, resulting in data inconsistency in the dual-write database.

[0072] In this embodiment, the main thread must wait for all asynchronous tasks to complete before ending its own transaction. This ensures that the main transaction's commit or rollback operation occurs after all asynchronous threads have finished their operations. If any asynchronous thread has SQL syntax errors or connection interruptions, the main thread will not commit its transaction directly. This ensures that the main thread's transaction and the asynchronous thread's transaction continue synchronously, thus avoiding data inconsistency in the dual-write database caused by asynchronous operations potentially committing independently when the main transaction rolls back.

[0073] Step S20: If all tasks are completed, the transaction completion task is added to the blocking queue so that the asynchronous thread executor can receive tasks in the blocking queue. If the transaction completion task is received, the asynchronous thread transaction of the asynchronous thread executor is terminated based on the transaction completion operation of the main thread.

[0074] It's important to note that the transaction termination task is a future task encapsulated with a special tag. This task is added to the blocking queue and serves as a trigger signal for the asynchronous thread executor to perform the transaction termination operation. An asynchronous thread transaction refers to a database transaction started in an asynchronous thread to perform double-write operations. This transaction must maintain state synchronization with the main thread transaction to ensure data consistency.

[0075] Understandably, after confirming that all SQL write tasks in the asynchronous thread executor have been completed, a transaction completion task with a special identifier is added to the blocking queue to ensure that the asynchronous thread processes the transaction completion task in order. Due to the characteristics of the blocking queue, this transaction completion task will be consumed after all preceding SQL tasks have been executed, thus avoiding the problem of incomplete data writing caused by premature transaction termination.

[0076] Upon receiving the task, the asynchronous thread can accurately obtain the main thread's transaction decision by monitoring the main thread's transactions, and then perform the corresponding transaction commit or rollback operations. Therefore, this embodiment achieves precise synchronization of the master and slave transaction states by injecting the transaction completion task as a control signal into the blocking queue, which is then received and executed by the asynchronous thread executor.

[0077] Step S30: Based on the result acquisition function, perform variable value acquisition operation for the member variable of the asynchronous thread executor, wherein the asynchronous thread executor is created locally and encapsulated as the future task, the member variable is the future task in the blocking queue, and the variable value acquisition operation is in a blocked state before the asynchronous thread transaction is completed.

[0078] It should be noted that member variables refer to instance variables defined in the asynchronous thread executor or its encapsulated task, used to store critical states or task references. In this embodiment, member variables are references or aggregations of other tasks in the blocking queue within future tasks, used to determine the overall execution state of the asynchronous thread transaction. The variable value retrieval operation refers to the process of accessing the internal member variables of the asynchronous thread executor through the `get` method. While the asynchronous task is not yet complete, this variable value retrieval operation will be in a blocked state, unable to obtain the result of the member variable, until the asynchronous thread executor completes all future tasks in the blocking queue. The blocked state means that the main thread is suspended when the `get` method is called, not consuming CPU (Central Processing Unit) resources, until the asynchronous task completes and wakes up the waiting threads.

[0079] It should also be noted that the asynchronous thread executor created by the main thread implements Callable, meaning it creates a task that can be executed by a thread, returns a result, and may throw exceptions. When the main thread creates the asynchronous thread executor, it needs to pass the thread pool to the current constructor. During instantiation, the asynchronous thread executor records a transaction ID, which is a unique identifier for a transaction. In this embodiment, the asynchronous thread executor can determine the transaction to be executed by recording the transaction ID. Simultaneously, the asynchronous thread executor also uses the thread pool's submit method to execute itself and assigns the return value futureTask to its member property. Subsequently, the get method of this property can be used to determine whether the current thread has ended.

[0080] When the asynchronous thread executor is instantiated, it simultaneously initializes the DataSource, creates a transaction, and obtains a connection. It uses ServiceSelectUtil (service layer selection query), which implements the ApplicationContextAware method. Its function is to obtain beans (objects or components in software development) from the IoC (Inversion of Control) container, obtain the secondary data source connection pool, create a new transaction through the DataSource, and obtain a connection to execute subsequent SQL.

[0081] It is understood that in this embodiment, an asynchronous thread executor is created by the main thread and encapsulated as a future task. When the asynchronous thread executor is a future task, it internally holds references to all related SQL tasks in the blocking queue. When the main thread retrieves the value of this member variable by calling the `get` method, this operation automatically blocks the main thread until the asynchronous thread completes all processing, including transaction commit or rollback.

[0082] The steps described in this embodiment enable the asynchronous thread executor to independently execute dual-write tasks without blocking the main thread's business logic. Before the transaction is finally committed, the main thread obtains the result in a blocking manner, ensuring that it does not prematurely commit or rollback the transaction until it is confirmed that the asynchronous thread executor has completed the corresponding operation. By utilizing the blocking characteristic of the main thread calling the `get` method to retrieve the member variables of the asynchronous thread executor, precise synchronous waiting for the completion status of the asynchronous transaction by the main thread is achieved. Furthermore, the steps described in this embodiment do not require the introduction of a complex external transaction coordinator; efficient and reliable transaction synchronization can be achieved solely through native concurrency tools, significantly improving the data consistency guarantee capability and system maintainability of the dual-write system.

[0083] Step S40: When the value of the member variable is obtained, execute the transaction termination operation for the main thread transaction.

[0084] It should be noted that the value of the member variable refers to the specific result value returned by the member variable in the future task after the asynchronous thread task has been completed. The value of the member variable can be the execution result of the future task or specific exception information. The main thread can use the value of this member variable to determine whether there is an exception in the execution of the SQL statement of the asynchronous thread executor. The execution flow of each part of the data dual-write in this embodiment can be referred to Figure 4 , Figure 4 This includes the transaction commit or rollback process of the main thread in this embodiment, the process of the main thread creating or calling the asynchronous thread executor through the transaction manager, and the process of the asynchronous thread executor executing the asynchronous thread transaction.

[0085] Understandably, since the result retrieval operation called by the main thread is in a blocked state, it must wait for the asynchronous thread to complete all the double-write logic, including transaction commit or transaction rollback, and return a clear execution result before the main thread can complete the transaction commit or transaction rollback.

[0086] When the main thread receives the value of the member variable, if it receives a normal execution result value, it indicates that the asynchronous thread executor's double-write operation is normal, and the main thread can simultaneously perform transaction commit or rollback operations for its own transaction. If it receives a double-write exception message encapsulated by the asynchronous thread executor, it indicates that the asynchronous thread executor's double-write operation has encountered an exception, and the main thread can perform transaction rollback or issue an alert based on the exception result.

[0087] In this embodiment, the final commit or rollback operation of the main thread transaction is only executed after the asynchronous thread transaction execution result is successfully obtained. The main thread performs corresponding processing operations based on the execution result of the asynchronous thread executor, thereby ensuring data consistency during the dual-write process of the database.

[0088] In one feasible implementation, the database dual-write system further includes an interceptor for intercepting the SQL statements. The main thread transaction includes a transaction ID and multiple SQL statements. The step of determining whether the asynchronous thread executor has completed all future tasks in the blocking queue before starting the transaction termination operation for the main thread transaction locally can also be:

[0089] When the SQL statement enters the interceptor, the transaction ID of the main thread transaction is obtained. Based on the transaction status tag of the target transaction corresponding to the transaction ID, it is determined whether the target transaction is in an active state. If it is in an active state, all transaction managers are traversed to determine whether a custom transaction listener exists. If it exists, based on the transaction ID, it is determined whether the asynchronous thread executor corresponding to the target transaction exists in the cache. If it exists, based on the transaction listener, a dual-write operation is performed on the local database and the database of the asynchronous thread executor.

[0090] It should be noted that an interceptor refers to the Interceptor interface component implemented in the MyBatis or MyBatis-Plus framework, used to insert custom logic before and after SQL execution. In this embodiment, the interceptor is used to intercept all persistent layer SQL requests. A transaction ID is an identifier that uniquely identifies a transaction. In this embodiment, the custom transaction manager constructs a transaction ID using the transaction name, thread ID, and counter, thus giving each transaction a unique identifier. The transaction manager is a Spring component that manages the transaction lifecycle, responsible for operations such as starting, committing, and rolling back transactions. Transaction status labels are markers used to indicate the current state of a transaction. A custom transaction listener is used to monitor key lifecycle events of a transaction. In this embodiment, the asynchronous thread executor uses the transaction listener to monitor the transaction completion operation of the main thread transaction to determine whether the main thread transaction is performing a transaction commit or rollback operation.

[0091] If the `TransactionSynchronizationManager.isActualTransactionActive` flag (whether the transaction synchronization manager is actually active) is true, it means the transaction is active. The overall execution flow of the main thread in this embodiment can be referenced... Figure 5 , Figure 5 This includes the entire process from intercepting SQL to committing the transaction in the main thread.

[0092] It should also be noted that the database dual-write synchronization method in this embodiment is applied to a non-distributed framework. Distributed frameworks can perform cross-thread transaction execution through global and local transactions. However, in the non-distributed framework of this embodiment, different threads only execute the transactions they need to execute, and cross-thread transaction execution is not possible.

[0093] Understandably, when an SQL statement enters the interceptor, the system first obtains the transaction ID of the current main thread transaction and checks whether the transaction is active by querying the transaction status label. If active, it means the current transaction is a database double-write transaction that needs to process multiple SQL statements, and the currently intercepted SQL statement is one of those multiple SQL statements. Therefore, the transaction ID can be used to determine whether a corresponding transaction listener and asynchronous thread executor exist for the current transaction. If they exist, the transaction listener and asynchronous thread executor retrieved from the cache can be directly called to execute the database double-write. This allows the same transaction to be processed by the same transaction listener and asynchronous thread executor, while avoiding the repeated creation of transaction listeners and asynchronous thread executors, thus reducing CPU resource consumption.

[0094] In one embodiment, if the current transaction is not active, the Task is run in a non-transactional manner, that is, a single Task is run as a transaction. If, after determining that the current transaction is active, no custom transaction listener is detected after iterating through all transaction managers, a custom transaction listener is created for the current transaction.

[0095] The specific steps to create a transaction listener include: registering a custom transaction manager in the main thread's TransactionSynchronization and implementing its afterCompletion (interceptor or callback method after transaction completion) method. This custom transaction manager can then be used as a custom transaction listener to monitor the transaction commit or rollback operations performed by the main thread.

[0096] In one feasible implementation, the specific implementation of performing dual database write operations on the local machine and the asynchronous thread executor based on the transaction listener, if such operations exist, can also be:

[0097] The SQL statement is encapsulated into a future task by a preset task addition function and added to the blocking queue so that the asynchronous thread executor can perform the database double write operation based on the transaction listener. Based on the result acquisition function, the execution result of the asynchronous thread executor for the SQL statement is obtained to get the asynchronous execution result. The SQL statement is then executed to get the main execution result. It is then determined whether the main execution result and the asynchronous execution result are consistent. If they are inconsistent, an alarm is issued.

[0098] It should be noted that the interceptor in this embodiment intercepts SQL statements at the persistence layer. The preset task addition function refers to the function used to encapsulate the SQL statement and submit it to the asynchronous execution queue. In this embodiment, the task addition function is the addTask function executed by the main thread. The asynchronous execution result refers to the result returned after the secondary data source executes the SQL, including the number of rows affected and the result set. The main execution result refers to the result returned by the main thread after executing the SQL on the main data source. The specific steps for executing the SQL query statement during the dual database write process of the main thread and the asynchronous thread executor can be found in [reference needed]. Figure 6 For detailed steps on executing the SQL upload statement, please refer to [link / reference]. Figure 7 .

[0099] Understandably, the interceptor intercepts SQL statements at the persistence layer, encapsulates them as future tasks through a task-adding function, and submits them to the blocking queue. This embodiment, by directly intercepting SQL at the persistence layer, allows for modification, filtering, or copying of the SQL before execution, thus meeting the requirements of dual writes. Furthermore, by intercepting SQL at the persistence layer, all database operations can be incorporated into unified transaction management, avoiding transaction management conflicts caused by aspect-level enhancements.

[0100] Furthermore, by comparing the asynchronous execution result with the main execution result, the system can accurately identify the execution deviation during the dual-write process. If the execution results on both sides are inconsistent, it indicates that there is a deviation in the data written by the main database and the secondary database. At this time, an alarm is issued to avoid data inconsistency problems during dual-write of the database.

[0101] In one feasible implementation, the specific method of encapsulating the SQL statement into the future task and adding it to the blocking queue using a preset task addition function can also be:

[0102] Based on the SQL statement, the corresponding mapping statement, pagination parameters, result executor, and input parameters are determined, and the mapping ID corresponding to the mapping statement is determined. The input parameters are deep copied to obtain deep copy input parameters. Based on the mapping ID, the deep copy input parameters, the pagination parameters, and the result executor, the SQL statement is encapsulated into the future task through the task addition function and added to the blocking queue.

[0103] It's important to note that the mapping statement is the core object `MappedStatement` in the MyBatis framework. It encapsulates the execution configuration of SQL statements, and each SQL operation corresponds to a unique mapping statement. The pagination parameters (RowBounds) refer to the parameter object used to implement paginated queries, containing information such as the current page number and page size. The result executor refers to the object (ResultHandler) used to process the SQL execution results. Some write operations may involve returning the primary key, affecting the number of rows, or complex result mappings, requiring the same processing logic to be reproduced during asynchronous execution.

[0104] Input parameters refer to the parameter objects passed to the SQL statement. Mapped Statement ID (MSID) is a string in MyBatis that uniquely identifies a mapped statement, used to find and execute the corresponding SQL at runtime. Deep copy refers to creating a completely independent new object, copying all its fields and nested objects, ensuring that modifications to the copy do not affect the original object. Deep copy input parameters refer to the copies obtained after performing a deep copy of the original input parameters, used for executing SQL in an asynchronous thread.

[0105] Understandably, this embodiment, when intercepting SQL, not only obtains its text content but also extracts the corresponding mapping statement to determine its mapping ID, parameter type, execution mode, and other metadata. Simultaneously, it obtains pagination parameters and the result executor, ensuring that the execution environment in the asynchronous thread is completely consistent with that of the main thread. Furthermore, this embodiment performs a deep copy of the input parameters, generating independent deep copy input parameters. This prevents data corruption caused by subsequent modifications to the original parameters by the main thread during asynchronous thread execution. The system encapsulates the mapping ID, deep copy parameters, pagination configuration, and result processor into a future task, ensuring that the asynchronous thread can accurately load the corresponding SQL statement and execute it safely using independent parameters. This guarantees the data integrity and semantic consistency of the dual-write operation and enhances the robustness of the database dual-write system.

[0106] In one embodiment, before the step of determining whether the asynchronous thread executor has completed all future tasks in the blocking queue, a dual-write hot-switch determination step is further included, specifically including:

[0107] Based on the preset personalized configuration, determine whether there is a personalized configuration for dual database writing; if there is, determine whether dual database writing is required; if not, disable dual database writing, determine the target database to be written to, and perform the write operation on the target database.

[0108] The above-described dual-write hot-switching steps allow for flexible changes between dual-write and single-write operations on the database, increasing the flexibility of database write operations. The dual-write hot-switching process in this embodiment can be referred to... Figure 8 .

[0109] In summary, before starting the transaction termination operation for the main thread transaction locally, this embodiment determines whether the asynchronous thread executor has completed all future tasks in the blocking queue. If all tasks are completed, the transaction termination task is added to the blocking queue so that the asynchronous thread executor can receive tasks from the blocking queue. If the transaction termination task is received, the asynchronous thread transaction of the asynchronous thread executor is terminated based on the transaction termination operation of the main thread. Based on the result retrieval function, the variable value retrieval operation for the member variables of the asynchronous thread executor is performed. When the variable value of the member variable is obtained, the transaction termination operation for the main thread transaction is executed.

[0110] Compared to current dual-write database methods, where each execution is a new, separate transaction, leading to inconsistencies when errors occur within the program and the main data source rolls back, this embodiment encapsulates the SQL statements to be executed as future tasks and adds them to a blocking queue. A loop function continuously receives these future tasks from the blocking queue. Since the execution results of future tasks are obtained by the main thread using a predefined function, the asynchronous thread executor only needs to continuously loop to obtain and execute these tasks, thus executing multiple SQL statements within a single transaction within a single asynchronous thread executor. Furthermore, because the asynchronous thread executor is created by the main thread and encapsulated as a future task, and its member variables are the future tasks in the blocking queue, the main thread's operation to retrieve the values ​​of these member variables remains blocked until the asynchronous thread executor's transaction is complete. Therefore, if the main thread obtains the values ​​of the asynchronous thread executor's member variables, it indicates that the asynchronous thread transaction corresponding to the asynchronous thread executor has been fully processed, and the main thread can then synchronously perform a transaction commit or rollback operation for its own transaction.

[0111] This embodiment enables multiple SQL statements to be executed in the main thread and asynchronous thread executors to be executed in one thread through the above operations. The transaction commit and transaction rollback operations are performed synchronously, preventing data consistency problems caused by the main thread rolling back while the asynchronous thread executor has already committed. This improves the data consistency of transaction commit and transaction rollback during the dual-write process of the database.

[0112] This application also provides a database dual-write synchronization method, applied to the asynchronous thread executor of a database dual-write system. The database dual-write system further includes a main thread, and the main thread and the asynchronous thread execute the same SQL statement. (Refer to...) Figure 9 , Figure 9 This is a flowchart illustrating the second embodiment of the database dual-write synchronization method of this application.

[0113] In this embodiment, the database dual-write synchronization method includes steps A10 to A20:

[0114] Step A10: Based on a preset loop function, continuously receive tasks from the blocking queue. The tasks in the blocking queue include future tasks and transaction completion tasks. The future tasks are obtained by the main thread after encapsulating the SQL statement through a preset task addition function. The execution result of the future tasks is obtained locally based on a preset result retrieval function. The transaction completion tasks are added to the blocking queue by the main thread after all the future tasks in the blocking queue have been completed locally.

[0115] It should be noted that the loop function refers to the polling logic that runs continuously inside the asynchronous thread executor. It is used to continuously retrieve tasks from the blocking queue and execute them. In this embodiment, the while loop (a type of loop function) and the blocking queue are used to suspend the thread and wake up the thread to execute SQL. Each loop will poll (polling) tasks in the blocking queue. When the polled tasks are empty, it will wait to call the take (get) method. When a new SQL task enters, it will be woken up.

[0116] The poll method waits for a period of time before proceeding to the next step, while the take method only proceeds after retrieving a task from the blocking queue. Therefore, when the poll method is empty, the take method is used to retrieve a task from the blocking queue, preventing the thread from being woken up prematurely and thus saving CPU resources.

[0117] Understandably, after the asynchronous thread executor is created, it continuously retrieves tasks from the blocking queue through a continuously running loop function. Due to the first-in, first-out order of the blocking queue, all future tasks encapsulated and added by the main thread can be executed by the asynchronous thread executor in sequence. By continuously receiving SQL statements packaged as future tasks through the blocking queue and the loop function, multiple SQL statements can be processed within the same transaction, preventing data inconsistencies caused by treating each SQL statement as a separate transaction during execution.

[0118] In one feasible implementation, the specific implementation of continuously receiving tasks from the blocking queue based on a preset loop function can also be:

[0119] The task in the blocking queue is obtained through a preset task retrieval function. It is determined whether the current task is the transaction completion task. If it is not the transaction completion task, the current task is executed and the process of retrieving the task in the blocking queue through the preset task retrieval function is returned until the transaction completion task is received.

[0120] Understandably, this embodiment continuously retrieves tasks from the blocking queue through a task retrieval function, achieving efficient task retrieval and execution while saving CPU resources. When the blocking queue is empty, the asynchronous thread automatically suspends, consuming no CPU resources; once the main thread submits a new task, the queue wakes up the asynchronous thread executor for immediate processing, ensuring low-latency response for dual-write operations. After each task is retrieved, the system first determines whether it is a transaction completion task, thus deciding whether to end the current transaction. If not, the SQL statement is executed to perform dual-write operations on the database. After completion, the system immediately returns and continues to retrieve the next task. These steps ensure that all SQL write tasks are fully executed before the transaction ends, and in the same order as the main thread's submission, avoiding data inconsistencies caused by task omissions or out-of-order execution.

[0121] In one feasible implementation, the asynchronous thread executor has a corresponding asynchronous database, which is connected to the asynchronous thread executor when it is created. The implementation of executing the current task if the transaction is not terminated can also be:

[0122] Obtain the SQL session factory and database interface of the asynchronous database. Based on the mapping ID, deep copy input parameters, pagination parameters, and result executor in the future task, determine the corresponding mapping SQL statement through the SQL session factory. Based on the database interface, create an SQL statement executor. Based on the SQL statement executor, execute the mapping SQL statement to obtain the asynchronous execution result.

[0123] It's important to note that an asynchronous database refers to a database instance on the dual-write target side. While logically consistent with the main database, it is physically independent. This database is dedicated to receiving write operations submitted by asynchronous thread executors, achieving data redundancy or cross-system synchronization. The SQL Session Factory (SqlSessionFactory) is a core component of the MyBatis framework, used to manage database connections, transactions, mapping statements, etc. Each database data source typically corresponds to an independent SqlSessionFactory.

[0124] Mapped SQL statements refer to the actual SQL text and its execution configuration retrieved and parsed from the SqlSessionFactory based on the mapping ID, including meta-information such as parameter binding rules and execution type. The SQL statement executor is a component within MyBatis used to execute SQL.

[0125] It should also be noted that the asynchronous execution result includes normal execution result and abnormal execution result. If the asynchronous execution result is a normal execution result, the asynchronous thread executor returns the normal execution result. If the asynchronous execution result is an abnormal execution result, the asynchronous thread executor encapsulates a double-written exception information class as the return result.

[0126] Understandably, this embodiment first obtains the SqlSessionFactory and database interface corresponding to the asynchronous database bound to the asynchronous thread executor, ensuring the use of the correct data source and connection pool. Subsequently, the system utilizes the mapping ID encapsulated in the future task to find the corresponding mapping statement through the SQL session factory, restoring the original SQL text and its execution configuration, thus avoiding data inconsistency issues caused by inconsistent SQL execution statements. Next, the system creates an SQL statement executor based on the database interface and adds deep copy input parameters, pagination parameters, and result executors to the execution flow, ensuring that parameter binding, result mapping, and other aspects are completely consistent with the main thread.

[0127] Step A20: If the transaction completion task is received, the asynchronous thread executor transaction of the asynchronous thread executor is terminated based on the transaction completion operation of the main thread, so that the main thread can perform variable value retrieval operation for the member variables of the asynchronous thread executor based on the result retrieval function. When the variable value of the member variable is obtained, the transaction completion operation for the main thread transaction is executed. The transaction completion operation includes transaction commit and transaction rollback. The asynchronous thread executor is created by the main thread and encapsulated as the future task. The member variable is the future task in the blocking queue. The variable value retrieval operation is in a blocked state before the asynchronous thread executor transaction is completed.

[0128] It should be noted that the asynchronous thread executor in this embodiment listens for transaction commit or rollback operations of the main thread through a custom transaction listener created by the main thread, and performs the corresponding operations through the asynchronous thread executor. The overall process of this embodiment, from the creation of the asynchronous thread executor to the termination of the current transaction by the asynchronous thread executor, can be referred to... Figure 10 .

[0129] Understandably, when the asynchronous thread receives the transaction completion task from the blocking queue, it indicates that all SQL double-write operations have been successfully executed. At this point, the system immediately executes the corresponding operation based on the transaction completion operation of the main thread's transaction: if the main transaction performs a transaction commit operation, the asynchronous thread executor also performs a transaction commit operation; if the main transaction performs a rollback, the asynchronous thread executor also performs a corresponding rollback. The above steps ensure that the transaction completion operation of the asynchronous thread executor corresponds to that of the main thread, avoiding the risk of data splitting.

[0130] Furthermore, after adding the transaction completion task, the main thread immediately calls the `get` method to retrieve the member variables encapsulated in the asynchronous task. This operation will block until the asynchronous thread completes the transaction commit or rollback and returns the result. Through the above operations of the main thread and the asynchronous thread, bidirectional waiting and state alignment between the master and slave transactions can be achieved—the main thread will not end the transaction prematurely unless it is certain that the asynchronous thread executor has completed all SQL statements, and the asynchronous thread executor will only end the transaction executed by the asynchronous thread after receiving the transaction completion task added by the main thread, thereby ensuring synchronous commit or rollback between the main thread and the asynchronous thread.

[0131] In summary, this embodiment continuously receives tasks from the blocking queue based on a preset loop function. If the transaction completion task is received, the asynchronous thread executor transaction of the asynchronous thread executor is terminated based on the transaction completion operation of the main thread, so that the main thread can perform variable value acquisition operation for the member variables of the asynchronous thread executor based on the result acquisition function. When the variable value of the member variable is obtained, the transaction completion operation for the main thread transaction is executed.

[0132] Because the asynchronous thread executor in this embodiment continuously receives and executes future tasks in the blocking queue through a loop function, multiple SQL statements can be executed within the same transaction through future tasks, the blocking queue, and the loop function. Furthermore, it only terminates its own transaction based on the main thread's commit or rollback decision when it receives a special transaction completion task, thus achieving synchronized commit or rollback between the main thread and the asynchronous thread executor. Moreover, when executing SQL statements, this embodiment uses an SQL session factory and parameters such as the mapping ID and deep copy parameters received from the main thread to ensure that the SQL execution semantics on the target database are completely consistent with those on the main database, avoiding database inconsistencies caused by different executed SQL statements and improving data consistency during dual-write execution.

[0133] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the database dual-write synchronization method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0134] This application provides a database dual-write synchronization device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the database dual-write synchronization method in Embodiment 1 above.

[0135] The following is for reference. Figure 11 The diagram illustrates a structural schematic suitable for implementing a database dual-write synchronization device according to embodiments of this application. The database dual-write synchronization device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The database dual-write synchronization device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0136] like Figure 11As shown, the database dual-write synchronization device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the database dual-write synchronization device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the database dual-write synchronization device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show database dual-write synchronization devices with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems can be implemented alternatively.

[0137] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0138] The database dual-write synchronization device provided in this application, employing the database dual-write synchronization method in the above embodiments, can solve the technical problem of data inconsistency between transaction commit and transaction rollback. Compared with the prior art, the beneficial effects of the database dual-write synchronization device provided in this application are the same as those of the database dual-write synchronization method provided in the above embodiments, and other technical features in this database dual-write synchronization device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0139] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0141] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the database dual-write synchronization method in the above embodiments.

[0142] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0143] The aforementioned computer-readable storage medium may be included in the database dual-write synchronization device; or it may exist independently and not be assembled into the database dual-write synchronization device.

[0144] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the database dual-write synchronization device, cause the database dual-write synchronization device to execute the aforementioned database dual-write synchronization method.

[0145] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0147] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0148] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described database dual-write synchronization method, which can solve the technical problem of data inconsistency between transaction commit and transaction rollback. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the database dual-write synchronization method provided in the above embodiments, and will not be repeated here.

[0149] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the database dual-write synchronization method described above.

[0150] The computer program product provided in this application can solve the technical problem of data inconsistency between transaction commit and transaction rollback. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the database dual-write synchronization method provided in the above embodiments, and will not be repeated here.

[0151] The user-related data involved in this application (e.g., user attribute data, user behavior data, and user geolocation) was obtained with the user's permission or consent, as per [reference]. Figure 12 In other words, when this application is applied to a specific product or technology, user permission is required to acquire and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0152] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A database dual-write synchronization method, characterized in that, A main thread used in a database dual-write system, wherein the database dual-write system also includes an asynchronous thread executor, the main thread and the asynchronous thread execute the same SQL statement, the method comprising: Before starting the transaction termination operation for the main thread transaction locally, it is determined whether the asynchronous thread executor has completed all future tasks in the blocking queue. The transaction termination operation includes transaction commit and transaction rollback. The asynchronous thread executor continuously receives tasks in the blocking queue based on a preset loop function. The future tasks are obtained locally by encapsulating the SQL statement through a preset task addition function. The execution result of the future tasks is obtained locally based on a preset result retrieval function. If all tasks are completed, the transaction completion task is added to the blocking queue so that the asynchronous thread executor can receive tasks from the blocking queue. If the transaction completion task is received, the asynchronous thread transaction of the asynchronous thread executor is terminated based on the transaction completion operation of the main thread. Based on the result retrieval function, a variable value retrieval operation is performed on the member variables of the asynchronous thread executor, wherein the asynchronous thread executor is created locally and encapsulated as the future task, the member variable is the future task in the blocking queue, and the variable value retrieval operation is in a blocked state before the asynchronous thread transaction is completed; When the value of the member variable is obtained, the transaction termination operation for the main thread transaction is executed.

2. The method as described in claim 1, characterized in that, The database dual-write system also includes an interceptor used to intercept the SQL statements. The main thread transaction includes a transaction ID and multiple SQL statements. Before the step of determining whether the asynchronous thread executor has completed all future tasks in the blocking queue before starting the transaction termination operation for the main thread transaction locally, the system further includes: When the SQL statement enters the interceptor, the transaction ID of the main thread transaction is obtained; Based on the transaction status tag of the target transaction corresponding to the transaction ID, determine whether the target transaction is in an active state; If it is active, it iterates through all transaction managers to determine if a custom transaction listener exists. If it exists, then based on the transaction ID, determine whether the asynchronous thread executor corresponding to the target transaction exists in the cache; If it exists, then based on the transaction listener, perform a dual-write operation on the database using both the local database and the asynchronous thread executor.

3. The method as described in claim 2, characterized in that, If present, the steps for performing dual database write operations on the local machine and the asynchronous thread executor based on the transaction listener include: The SQL statement is encapsulated into a future task by a preset task addition function and added to the blocking queue so that the asynchronous thread executor can perform the database double write operation based on the transaction listener. Based on the result retrieval function, the execution result of the asynchronous thread executor for the SQL statement is obtained, thus obtaining the asynchronous execution result; Execute the SQL statement to obtain the main execution result; Determine whether the main execution result and the asynchronous execution result are consistent. If they are inconsistent, issue an alarm.

4. The method as described in claim 3, characterized in that, The step of encapsulating the SQL statement into the future task and adding it to the blocking queue using a preset task addition function includes: Based on the SQL statement, determine the corresponding mapping statement, pagination parameters, result executor, and input parameters, and determine the mapping ID corresponding to the mapping statement; Perform a deep copy on the input parameters to obtain the deep copy input parameters; Based on the mapping ID, the deep copy input parameters, the pagination parameters, and the result executor, the SQL statement is encapsulated into the future task through the task addition function and added to the blocking queue.

5. A database dual-write synchronization method, characterized in that, An asynchronous thread executor for a database dual-write system, wherein the database dual-write system also includes a main thread, and the main thread and the asynchronous thread execute the same SQL statement, the method comprising: Based on a preset loop function, tasks in the blocking queue are continuously received. The tasks in the blocking queue include future tasks and transaction end tasks. The future tasks are obtained by the main thread after encapsulating the SQL statement through a preset task addition function. The execution result of the future tasks is obtained locally based on a preset result retrieval function. The transaction end tasks are added to the blocking queue by the main thread after all the future tasks in the blocking queue have been completed locally. If the transaction completion task is received, the asynchronous thread executor transaction of the asynchronous thread executor is terminated based on the transaction completion operation of the main thread, so that the main thread can perform variable value retrieval operation for the member variables of the asynchronous thread executor based on the result retrieval function. When the variable value of the member variable is obtained, the transaction completion operation for the main thread transaction is executed. The transaction completion operation includes transaction commit and transaction rollback. The asynchronous thread executor is created by the main thread and encapsulated as the future task. The member variable is the future task in the blocking queue. The variable value retrieval operation is in a blocked state before the asynchronous thread executor transaction is completed.

6. The method as described in claim 5, characterized in that, The step of continuously receiving tasks from the blocking queue based on a preset loop function includes: The task in the blocking queue is retrieved using a preset task retrieval function; Determine whether the current task is the task that ends with the transaction; If the transaction is not terminated, the current task is executed, and the step of retrieving the task in the blocking queue through the preset task retrieval function is returned until the transaction termination task is received.

7. The method as described in claim 6, characterized in that, The asynchronous thread executor has a corresponding asynchronous database, which is connected to the asynchronous thread executor when it is created. The step of executing the current task if the transaction is not terminated includes: Obtain the SQL session factory and database interface of the asynchronous database; Based on the mapping ID, deep copy input parameters, pagination parameters, and result executor in the future task, the corresponding mapping SQL statement is determined through the SQL session factory; Based on the aforementioned database interface, an SQL statement executor is created; Based on the SQL statement executor, the mapped SQL statement is executed to obtain asynchronous execution results.

8. A database dual-write synchronization device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the database dual-write synchronization method as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the database dual-write synchronization method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the database dual-write synchronization method as described in any one of claims 1 to 7.

Images