Distributed transaction processing method, system, apparatus, and readable storage medium

Abstract

This application relates to the field of software technology, and more specifically, to a distributed transaction processing method, system, apparatus, and readable storage medium. The method includes creating and initializing a history version table, where the history version table is for recording the data content and version information of each version of a target data entity, the initialized version information includes first version information, and the first version information corresponds to the data content of the first version of the target data entity; the service flow processing module sending a first type of operation request for the received target data entity to the insurance securities data management module; and the insurance securities data management module reading the history version table and recording the data content of the second version obtained by performing a first type of operation on the data content of the first version. This application can improve the efficiency of distributed transaction processing and the service rollback ability based on the history version table, which is advantageous for improving the user experience.

Description

Technical Field

[0001] The present invention relates to the field of software technology, and more specifically, to a distributed transaction processing method, system, apparatus, and readable storage medium. (Declaration of Claim of Priority) This application claims the priority of a Chinese patent application filed with the China National Intellectual Property Administration on May 31, 2022, with an application number of 202210611120.X and an application title of "Distributed Transaction Processing Method, System, Apparatus, and Readable Storage Medium", the entire content of which is incorporated herein by reference.

Background Art

[0002] A distributed transaction refers to the situation where participants in a transaction, the servers supporting the transaction, resource servers, and the transaction manager are located on different nodes of different distributed systems. Here, a transaction is an execution unit of a program that operates on certain data in a database.

[0003] In the realm of general distributed transaction solutions, Seata, based on the XA specification, is an open-source distributed transaction solution that aims to provide high-performance, simple, and easy-to-use distributed transaction services under a microservices architecture. Seata offers users four transaction processing models: AT, TCC (Try-Confirm-Cancel), the Long Transaction Model (SAGA), and XA. Of these, AT and XA are models for handling rigid transactions, but rigid transactions have low processing efficiency due to their synchronous block structure and are generally not suitable for distributed scenarios of large sites. TCC and SAGA are models for handling flexible transactions. Flexible transactions allow for intermediate states and support modifications to the service layer, such as applications (APP), and therefore the TCC and SAGA models are widely used in distributed scenarios of several large websites. The TCC model, in particular, provides three service interfaces: primary operation (Try), confirmation operation (Confirm), and cancellation operation (Cancel), which can be called by the main service. Therefore, TCC divides the transaction execution process into Try and Confirm phases and Cancel phases that enable service rollback of transactions processed by Try and Confirm. SAGA achieves service rollback based on inverse compensation operations for a series of operations. Taking insurance services as an example, the aforementioned service rollbacks include, for example, operations to modify the created insurance contract or operations to cancel the generated insurance contract (i.e., insurance cancellation).

[0004] However, in such service rollback processes, it is currently common to complete the rollback by reading the changes before and after data modification in the relevant Structured Query Language (SQL) at the lowest level of the database, or to implement service rollback based on rollback code. Implementing such service rollback cannot be applied to the service layer (e.g., the application program itself), the rollback logic is complex and difficult to implement, and the development, maintenance, and modification costs associated with implementing the corresponding service rollback functionality are relatively high. [Overview of the Initiative]

[0005] Embodiments of this application provide a distributed transaction processing method, system, apparatus, and readable storage medium, the method being able to record version information of corresponding data entities before and after data operations such as new additions, deletions, changes (or modifications), and the content before and after the operations, and when a rollback operation is detected in the service system, or when an anomaly occurs in a data operation corresponding to a data entity called in the service system, the system can quickly retrieve the data content of the historical version before the data operation was performed on the data entity based on relevant information such as the version number recorded in the historical version table, thereby enabling a rollback. This is advantageous for improving the user experience by improving the service rollback capability of the distributed system.

[0006] In a first embodiment, an embodiment of the present application provides a distributed transaction processing method used for a system including a service flow processing module, an insurance policy data management module, and a distributed transaction manager, the method including: The insurance policy data management module creates and initializes a historical version table, which records the data content and version information for each version of the target data entity. The initialized version information includes the first version information, and the first version information corresponds to the data content of the first version of the target data entity. The service flow processing module requests the distributed transaction manager to initiate a global transaction; The service flow processing module receives a Type 1 operation request for the target data entity and sends the Type 1 operation request to the insurance policy data management module, the Type 1 operation request is to request that a Type 1 operation be performed on the first version of the data content of the target data entity, and the Type 1 operation includes at least one of the following operations: add, delete, or modify. The insurance policy data management module, in response to a Type 1 operation request, reads the historical version table, records the second version of the data content obtained by performing a Type 1 operation on the first version of the data content, and registers a transaction branch with the distributed transaction manager, the transaction branch being the associated transaction that performs the Type 1 operation; The distributed transaction manager, in accordance with the first request to commit the global transaction sent from the service flow processing module, notifies the insurance policy data management module to commit the transaction branch.

[0007] In other words, in a system that processes distributed transactions, a historical version table can be created by an insurance policy data management module that manages data entities related to insurance policy data held by the system itself. This makes it easy to control the historical version table created during the creation process so that it is the same as the data table structure of the target data entity, i.e., to achieve isomorphism. Thus, when the system detects an update to the stored contents of the data table of the target data entity, it uses the created historical version table to record the data content before and after the update in a timely manner and write the corresponding version information. As a result, when other services are executed and the historical version table is called, the data content of the corresponding version can be quickly retrieved based on the version information recorded in the historical version table.

[0008] The service flow processing module within the system connects to the distributed service system client to receive service operation requests from users operating on the service system client. It then forwards these requests to the relevant modules within the system for execution, depending on the content and target of the service operation request. For example, it forwards a received first-type operation request to the insurance policy data management module for processing. Furthermore, the program code executed by the service flow processing module can request the distributed transaction manager to initiate a global transaction if it determines that the next operation to be performed requires involvement of multiple different data sources or requires multiple remote calls and data updates. In this way, the system can improve the efficiency of classifying and processing service operation requests. The first-type operation request described above corresponds to a forward operation, as described in a later embodiment. The first-type operation request may, for example, be a trigger-corresponding operation request where an insurance policyholder creates a new insurance policy through an insurance business client operation, entering personal information of the policyholder / insured, insurance amount, address, etc., into the client interface.

[0009] When a distributed transaction manager in the system responds to a first type of operation request forwarded by a service flow processing module, it can call a historical version table created by the insurance policy data management module. The data content of the first version may be, for example, the initial content of the target data entity. Therefore, the distributed transaction manager can retrieve the initial content of the target data entity via the first version information in the historical version table and process the first type of operation request based on the retrieved initial content. As can be understood, if there are updates to the records in the historical version table after the insurance policy data management module has created the historical version table for the target data entity, the insurance policy data management module can quickly retrieve the initial content of the target data entity pointed to by the processing of the corresponding service operation request via the historical version table when responding to the first type of operation request, which is advantageous in improving the service processing efficiency of the distributed transaction manager.

[0010] In a possible embodiment of the first aspect described above, reading the historical version table and recording the second version of the data content obtained by performing a first type of operation on the first version of the data content includes: The insurance policy data management module writes the data content of the second version to the historical version table, and also writes the second version information to the historical version table in response to the data content of the second version; The insurance policy data management module writes the first version information and the second version information to a log to undo the rollback.

[0011] In other words, when the insurance policy data management module processes requests such as new additions, deletions, and modifications, it can read version information using logs for undoing rollbacks in distributed transactions, and further read the data content of the corresponding version based on the historical version table. Here, the log for undoing rollbacks only needs to store the version number as index information, and does not need to store the complete details of the changes. This improves the data manipulation processing efficiency of the insurance policy data management module.

[0012] In a possible embodiment of the first aspect described above, the method further includes: The service flow processing module receives abnormal data within a global transaction, or a second type of operation request for a received target data entity, and sends a second request to the distributed transaction manager to roll back the global transaction. This second request is intended to roll back the global transaction so that the data content of the target data entity is updated from the second version of the data content to the first version of the data content; The distributed transaction manager, in response to the second request, notifies the insurance policy data management module to roll back the transaction branch; The insurance policy data management module, upon receiving a notification to roll back a transaction branch, retrieves the first version of the data content based on the first version information recorded in the historical version table and restores it to the current data content of the target data entity.

[0013] The second type of operation described above may be, for example, a rollback operation request initiated by a distributed service system client, and the abnormal data in the global transaction obtained by the service flow processing module may be, for example, abnormal data reported on the service system when an abnormality occurs in the corresponding data operation on the called data entity, such as a database write failure or a network anomaly. When the service flow processing module receives a rollback operation request or obtains abnormal data in the global transaction, it can send a second request to roll back the global transaction, i.e., a request to roll back the global transaction, to the distributed transaction manager. In response to this request, the distributed transaction manager can notify the insurance policy data management module to roll back the transaction branch. Furthermore, the insurance policy data management module can read and retrieve the updated historical version table and quickly obtain the data content of the historical version before the data operation was performed on the data entity to realize the rollback. In this way, the efficiency of response processing to rollback transactions in the distributed service system can be improved, which is advantageous in improving the system's rollback capability. It is understood that the version information and the contents of the target data entity recorded in this historical version table are updated when the distributed transaction manager in the steps described above processes the first type of operation request.

[0014] In a possible embodiment of the first aspect described above, the log for undoing a rollback includes a rollback log, and retrieving the data content of the first version based on the first version information recorded in the historical version table includes: The insurance policy data management module retrieves the first version information recorded in the rollback log; The insurance policy data management module retrieves the data content of the first version based on the correspondence between the first version information recorded in the historical version table and the data content of the first version.

[0015] In other words, when the insurance policy data management module processes a rollback operation request or an abnormal rollback transaction, it can use the rollback log (undo log) to read version information and further read the data content of the corresponding version from the history version table. The undo log only needs to store the version number as index information; it does not need to store the complete changes. This improves the data manipulation processing efficiency of the insurance policy data management module.

[0016] In a possible embodiment of the first aspect described above, the historical version table is created by creating a historical version table identical to the first data table structure from the first data table structure corresponding to the target data entity.

[0017] In other words, the historical version table created by the insurance policy data management module is isomorphic to the data table structure of the target data entity. The first data table structure described above is the structure of any data table or any type of data table corresponding to the target data entity.

[0018] In a possible embodiment of the first aspect described above, the parameter list of the history version table includes a primary key, type, initial version, and service fields awaiting recording, and the version information includes a version number recorded in the initial version field of the history version table.

[0019] The primary key and the service fields awaiting recording correspond to the data content recorded in the history version table. The primary key is, for example, the ID of the insurance policy data, and the service fields awaiting recording are, for example, fields such as the insurance amount and address. The type of the history version table can record, for example, the type of operation corresponding to the first type of operation described above, such as adding, deleting, or modifying. The initial version of the history version table is, for example, an identification code written according to a pre-set version number setting rule corresponding to the version information of the recorded data. The version number of the initial version recorded in the history version table (simply the initial version number) corresponds one-to-one with the data content before and after the update each time the data content is updated. That is, in the history version table, each version of the data content corresponds to one initial version number. The initial version number can be used as identification information to retrieve the corresponding version of the data content when the insurance policy data management module performs a first type of operation in response to a first type of operation request, or when it rolls back a transaction branch based on a notification to roll back a transaction branch of the distributed transaction manager, in order to enable rapid retrieval of data content.

[0020] To make it easier to understand, version information such as the initial version number recorded in the historical version table can be used to retrieve the data content of the corresponding version, replacing the complex call process that the original distributed transaction performed by retrieving the target data entity and its modification logs from the database. This improves the efficiency of retrieving the corresponding data content and further improves the processing efficiency of distributed transactions.

[0021] In a possible embodiment of the first aspect, each parameter in the parameter list of the history version table is associated with each parameter in the first data table structure. This association is created by the insurance security data management module adding first annotation information to the first data table structure via a preset annotation tool. The first annotation information is used to update each parameter in the history version table in response to changes in each parameter in the first data table structure when analyzed by the storage management engine. The preset annotation tool is @Audit provided by Hibernate Envers, and the storage management engine is Hibernate.

[0022] Since the insurance security data management module has the advantage of calling with respect to the content and structure of the target data entity to be managed, after creating the history version table, the insurance security data management module can add an annotation to the Java class of the data table structure of the target data entity via the Java class annotation @Audit provided by Hibernate Envers. In this way, after the engine Hibernate responsible for database storage analyzes this annotation in the code, when the content of the corresponding data table of the data entity is updated, it can record the data content and version information before and after the corresponding update in the history version table at the same time. The method of recording the update changes of the data entity by such a history version table is simple in logic, convenient in operation, has a small impact on the original database and the distributed transaction processing flow, and is advantageous for improving the efficiency of distributed transaction processing.

[0023] In a possible embodiment of the first aspect, the first version information is the first version number recorded in the initial version field of the history version table.

[0024] That is, the first version information is the initial version number corresponding to the data content of the first version recorded in the history version table.

[0025] In a possible embodiment of the first aspect, obtaining the history version table by the insurance security data management module includes the following: When the insurance security data management module reads the history version table in response to the first type of operation request, it includes the following: The insurance security data management module reads the history version table based on a preset SQL. Here, the preset SQL includes at least the name of the history version table, the primary key, and the correspondingly recorded version number in the initial version field. That is, when the insurance security data management module responds to the first type of operation request, it can complete the query and acquisition response of the history table and the data content of the corresponding version by a simple SQL statement. The execution statement of the query process is simple and efficient, and the efficiency of obtaining the corresponding data content can also be improved.

[0026] In a possible embodiment of the first aspect, the first type of operation request is a distributed transaction operation request written in the bin log event or update log event of MYSQL (registered trademark). When the service flow processing module receives the first type of operation request for the target data entity and transfers the first type of operation request to the insurance security data management module, it includes the following: The service flow processing module determines that the first type of operation request is a distributed transaction operation request written in the bin log event or update log event of MYSQL; The service flow processing module analyzes the received bin log event to obtain bin log data, or analyzes the received update log event to obtain update log data; The service flow processing module identifies distributed transaction operation requests corresponding to add, delete, or modify operations based on bin log data or update log data; The service flow processing module forwards the identified distributed transaction operation request as a first-type operation request to the insurance policy data management module.

[0027] By parsing MySQL bin log events or update log events to identify the type of distributed transaction operation request, changes in data recorded at the bottom of the database can be obtained by a Java program running in the application layer. This data retrieval method is simple, direct, and highly timely. Furthermore, this method of obtaining operation request data avoids the need to modify the code on servers supporting the distributed service system, which is advantageous in reducing the development workload required to handle server or system modifications.

[0028] In a possible embodiment of the first aspect described above, the second type of operation request is a distributed transaction operation request written to the MySQL bin log event, and the service flow processing module receives the second type of operation request for the target data entity and sends a second request to the distributed transaction manager to roll back the global transaction, which includes: The service flow processing module parses the received bin log event and retrieves the bin log data; The service flow processing module identifies rollback operation requests based on bin log data, which request to update the returned second version of the data content with the first version of the data content; Based on the identified rollback operation request, the service flow processing module sends a second request to the distributed transaction manager to roll back the global transaction.

[0029] As described above, by analyzing MySQL bin log events to identify rollback operation requests or abnormal operation data for distributed transactions, it is possible to determine whether or not a rollback process needs to be performed on the data content of the target data entity in the database, and to retrieve the data changes or abnormal data recorded at the bottom of the database for a Java program executed in the application layer. This is advantageous because the data retrieval process is simple, direct, and timely, and reduces the development workload required to respond to server or system modifications.

[0030] In a possible embodiment of the first aspect described above, a second type of operation request includes canceling a request for a first type of operation, or retrieving the first version of the data content to perform the first type of operation again.

[0031] A request to undo the first type of operation described above is, for example, a distributed transaction rollback request initiated in response to a user performing a rollback operation via a client of the distributed service system. This could include triggering a rollback operation request from the client when a user returns to the previously filled-in insurance policy information page for confirmation while paying an insurance amount. In other embodiments, a request to undo the first type of operation described above may be a restore request initiated in response to a service system client failure, requesting a restoration to the initial data content. There are no limitations here.

[0032] If other users need to retrieve the first version of the data content of a data entity via other clients to perform corresponding service operations, the insurance policy data management module can also quickly retrieve and process the first version of the data content via the first version information recorded in the historical version table.

[0033] In a possible embodiment of the first aspect described above, the target data entities are stored in a database for distributed transactions, and the method includes: In the process of performing a Type 1 operation, the data content of the target data entity stored in the database is matched with the real-time data content of the target data entity manipulated by the insurance policy data management module in the following manner: The distributed transaction manager retrieves the active transaction list for the current time, of which the active transaction list marks the progress of the Type 1 operation performed on each data entity in the database, and each data entity in the database contains the target data entity; The distributed transaction manager generates and sends consistency compensation statements and compensation orders to the database based on the active transaction list and log data corresponding to the target data entities generated by the current database. The compensation orders are used to instruct the database to execute the consistency compensation statements, updating the real-time data content corresponding to the progress of the execution of the first type of operation with the data content of the target data entities in the database.

[0034] In other words, when a distributed transaction manager derives target data entities from the database and performs operations such as adding, deleting, or modifying them, it generates a data consistency compensation statement based on the active transaction list and the log corresponding to the target data entity recorded in the database. It then instructs the database to execute this statement, thereby updating the data content of the target data entity in the database. In this way, it is possible to guarantee that the data content stored in the database and the manipulated data content will match in a timely manner during the distributed transaction processing. Therefore, when other distributed systems call the corresponding data content in the database, they can output the updated data content in real time. On the other hand, the data content before the corresponding operation can be recorded in a history version table. If it is necessary to roll back to a subsequent distributed transaction operation process, the corresponding data content can be retrieved and processed based on the corresponding version information, eliminating the need to retrieve the history data content from the corresponding log recorded in the database. This effectively improves the efficiency of distributed transactions and the timeliness of updating database data content.

[0035] In a second embodiment, the embodiment of the present application provides a system comprising a service flow processing module, an insurance policy data management module, and a distributed transaction manager, wherein the insurance policy data management module is for creating and initializing a historical version table, the historical version table for recording data content and version information for each version of a target data entity, the initialized version information includes first version information, the first version information corresponds to the data content of the first version of the target data entity; and in response to a first type of operation request, it reads the historical version table, records the data content of a second version obtained by performing a first type of operation on the data content of the first version, and registers a transaction branch in the distributed transaction manager, the transaction branch being an associated transaction that performs a first type of operation; The service flow processing module receives a first type of operation request for the target data entity and sends the first type of operation request to the insurance policy data management module, the first type of operation request being to perform a first type of operation on the first version of the data content of the target data entity, the first type of operation including at least one of add, delete, or modify operations; and retrieves abnormal data in the global transaction or a received second type of operation request for the target data entity and sends a second request to the distributed transaction manager to roll back the global transaction, the second request being to roll back the global transaction to update the data content of the target data entity from the second version of the data content to the first version of the data content; The distributed transaction manager receives a notification sent by the service flow processing module to initiate a global transaction, and receives a request from the insurance policy data management module to register a transaction branch and stores the registration information for the transaction branch; and receives a notification from the service flow processing module to commit the global transaction and notifies the insurance policy data management module to commit the transaction branch.

[0036] In a third aspect, an embodiment of the present application provides an apparatus including one or more processors and one or more memories, the one or more memories storing one or more programs, which, when executed by one or more processors, cause the apparatus to execute the distributed transaction processing method provided in the first aspect.

[0037] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium that, when executed by a computer, stores instructions causing the computer to execute the distributed transaction processing method according to the first aspect. [Brief explanation of the drawing]

[0038] [Figure 1] Figure 1 shows an application scenario of the distributed service system according to the embodiment of this application. [Figure 2] Figure 2 is a schematic diagram showing the implementation flow of the distributed transaction processing method according to the embodiment of this application. [Figure 3] Figure 3 is a schematic diagram of a historical version added to some data entities in an insurance policy database according to an embodiment of this application. [Figure 4] Figure 4 is a schematic block diagram showing the software configuration of the server 200 according to the embodiment of this application. [Figure 5]Figure 5 is a schematic diagram showing the communication flow between some structures within the server 200 when implementing the distributed transaction processing method according to the embodiment of this application. [Figure 6] Figure 6 shows the hardware configuration of the server 200 according to the embodiment of this application. [Modes for carrying out the invention]

[0039] To facilitate understanding of the solutions of this invention, some technical concepts related to the embodiments of this invention are described below. (1) A database stores a large amount of data entities. Database design is the process of planning and structuring the data entities in the database and the relationships between those data entities. (2) In the case of a database, a data entity refers to an individual dataset corresponding to a particular type of data object. Each data entity may use a data table structure to record the individual data corresponding to a data object and the relationships between the individual data. Thus, the data table structure of each data entity includes one or more related data tables, and the primary keys of each data table may be related to each other, for example, the primary key of one data table may be a foreign key of another data table. (3) A data table consists of three parts: the table name, the table fields, and the table records. Designing a data table structure (hereinafter simply referred to as the table structure) involves defining the data table file name, determining which fields the data table will contain, the field name, field type, and width of each field, and entering this data into the computer. (4) A primary key refers to a combination of one or more columns in a data table, and its value can uniquely identify each row in the table. The primary key of one data table can be associated with a foreign key of another data table, allowing for the addition, deletion, modification / correction of field text, etc., in the other data table. (5) ACID properties refer to the four properties necessary for a database management system (DBMS) to ensure that transactions are accurate and reliable in the process of writing or updating data: atomicity, consistency, isolation, and durability.

[0040] Figure 1 shows a schematic diagram of an application scenario for a distributed service system according to the embodiment of this application. As shown in Figure 1, in this scenario, communication takes place between terminal devices 100a and 100b and server 200. Here, server 200 may include multiple databases and a transaction manager that processes distributed transactions in order to provide distributed data services to each terminal device.

[0041] A user or the platform operator of the corresponding service system can execute a service system application or a web-based service system application via the terminal device 100a. This service system may be, for example, an insurance service system, and a user who wishes to purchase insurance can register a system account with the insurance service system on which the terminal device 100a operates, and perform tasks such as selecting insured items, entering personal information, creating an insurance policy, and paying premiums. In the process of a user performing a series of operations on the terminal device 100a, the corresponding operation data is accessed in the corresponding database on the server 200. If the user needs to correct an operation they have completed, for example, by correcting personal information in an insurance policy, or if the user wants to return to a previous page or perform an operation in a previous step from the currently displayed page on the terminal device 100a, the service system operating on the terminal device 100a will perform a rollback of the corresponding service to support the user's rollback or correction operation.

[0042] Similarly, another user or platform operator of the corresponding service system can also connect to the service system via another terminal device 100b. For example, an insurance service representative can log in to the insurance service system via terminal device 100b and view or approve insurance policy details. At this time, terminal device 100b can retrieve the relevant insurance policy data from the insurance policy database on server 200 and display it on the terminal device 100b's screen. The insurance service representative can also modify or cancel an already generated insurance policy at the user's request. The service system running on terminal device 100b at this time also needs to have a service rollback function to support the insurance service representative's modification or cancellation operations.

[0043] In current distributed transaction solutions, whether the service rollback function is implemented by reading the changes before and after data modification in SQL statements corresponding to the underlying database, or by implementing it based on rollback code, the implementation logic is relatively complex and requires relatively significant modifications to the distributed service system, resulting in relatively high development and maintenance costs.

[0044] To solve the above technical problems, this application provides a distributed transaction processing method. Specifically, in the database design, a history version table identical in type to the data table structure of the target data entity is added to record version information before and after data operations such as the addition, deletion, modification (or correction) of the target data entity, as well as the content before and after the operation. Note that this history version table can be made identical in type to the data table structure of the target data entity by, for example, adding fields such as version number and version type to the basic data table structure corresponding to the target data entity, and there are no limitations here.

[0045] Thus, in the communication scenario between the server and terminal device shown in Figure 1 above, if the server 200 detects that a rollback operation has occurred in the service system running on terminal device 100a or 100b, or if an anomaly occurs in the corresponding data operation for a data entity called on the service system, the server 200 can quickly retrieve the data content of the historical version of the data entity before the data operation was performed, based on relevant information such as the version number recorded in the history version table, and roll it back. Furthermore, based on this history version table, the server 200 can quickly restore the version of the operated data even if the user performs a forward operation again on the service system running terminal device 100a or 100b. In other words, the solution of this application can support high-speed rollback operations of distributed transactions on a distributed service system, and can quickly restore recorded history operation data when a forward operation is performed again on the user's corresponding service system.

[0046] The distributed transaction processing method according to this application enables the recording of version information and data content of data entities before and after the application layer performs a corresponding data operation by adding a history version table of the same type to the data table structure of the target data entity in the server's database. Here, the application layer is, for example, a Java program layer that communicates with terminal devices executed on server 200, but there are no limitations. Furthermore, server 200 can apply the history version table, which records version information and data content of data entities before and after the execution of the corresponding operation, to the data rollback function of the distributed transaction.

[0047] Furthermore, the above-mentioned historical version table can be adaptively designed for various distributed service systems to which the application layer is connected. For example, the data table structure corresponding to the data entities of the corresponding distributed service system is designed to be isomorphic in order to read the table information during subsequent calls. Moreover, the implementation process of the distributed transaction processing method according to the embodiment of this application can support various types of databases regardless of the type of database at the bottom of the server 200 system, is highly scene-adaptive, and does not cause additional performance loss to the server.

[0048] The distributed transaction processing method according to the embodiment of this application is applicable to devices including, but is not limited to, the server 200 described above, as well as mobile phones, tablets, desktops, laptops, handheld computers, netbooks, and wearable devices such as augmented reality (AR) / virtual reality (VR) devices, smart TVs, and smartwatches, mobile email devices, in-car devices, portable game consoles, portable music players, reader devices, televisions incorporating or coupled with one or more processors, or other devices that can access a network.

[0049] The specific implementation procedure of the distributed transaction processing method provided by the embodiment of the present invention will be described in detail below, using the server 200 in the scenario shown in Figure 1 as an example, with reference to the drawings. Based on the scenario shown in Figure 1 above, Figure 2 is a schematic diagram of the implementation flow of the distributed transaction processing method according to the embodiment of this application. Note that the entity executing each step shown in Figure 2 may be the server 200 in the scenario shown in Figure 1. Specifically, it includes the following steps: 201: Create an identical historical version table based on the table structure of the data entities in the database.

[0050] For example, when creating a database required for a distributed service system on server 100, a history version table can be added to the database structure during the database design phase. Here, the table structure of the added history version table may be the same as the table structure of the target data entity in the database, that is, it may be "isomorphic" as described above. Similarly, for a database created on server 200, the database interface may be called, and an isomorphic history version table may be added to each data entity in the database, and the original version in the corresponding database may be initialized by data migration. Note that the data items recorded in the history version table may include the primary key of the target data entity table, version information before and after modification, and content before and after modification, and the type of operation (new addition, deletion, modification) can be identified based on the content before and after modification.

[0051] Here, an example of the format of the historical version table can be found in Table 1 below.

[0052] [Table 1]

[0053] As shown in Table 1, the "primary key" in the history version table may be the primary key of each data table corresponding to the data entity, or it may be an identification string such as an ID. The "field 1" and "field 2" in the history version table may be service fields etc. recorded in each data table corresponding to the data entity. For example, "field 1" may record name, address, insurance amount etc., and "field 2" may record version type, modification type etc. The "initial version" in the history version table is the version number corresponding to the data content before a certain data operation of the target data entity, and the "end version" is the version number of the data content generated after that data operation. For example, in the first row of the record shown in Table 1 above, initial version "1" is the version number of the data content before a certain data operation, and end version "2" is the version number of the data content generated after a certain data operation. After a certain data operation, the primary key, field 1, initial version, end version, field 2 etc. corresponding to the data entity after the operation may be recorded in a different row of the history version table. For example, in the second row of the record shown in Table 1 above, the initial version of the second row is "2".

[0054] If no data operations have been performed on the target data entity, the version number in the "End Version" column of the historical version table shown in Table 1 above may be a null value such as "NULL" as shown in Table 1 above.

[0055] Taking a database corresponding to insurance services as an example, Figure 3 is a schematic diagram showing historical versions added to some data entities of an insurance policy database according to an embodiment of this application.

[0056] As shown in Figure 3, some of the original table structures of the corresponding data entities in the database can refer to, for example, the "Policy" table and the "Address" table. Referring to Figure 3, the primary key of the "Policy" table is ID, and the field of the record is the specific amount of "guarantee amount". For example, the initial version with ID 100 is "1", and the corresponding "guarantee amount" data is 1000. The primary key of the "Address" table is also ID, and the field of the record is the specific content of "address". For example, the "address" data for ID 101 is "SH", and the "address" data for ID 102 is "BJ".

[0057] Continuing to refer to Figure 3, the same type of historical version table created based on the table structure of the data entities described above can refer to the "Policy Log" table and the "Address Log" table shown in Figure 3. Here, the "Policy Log" table has the addition of a version number field (for example, the initial version shown in Figure 3) and a "Version Type" field compared to the "Policy" table described above. The "Type" field in the "Policy Log" table is, for example, "Field 1" in Table 1 above, and the "Version Type" field is, for example, "Field 2" in Table 1 above, and is not limited here. Similarly, the "Address Log" table also has the addition of an "Initial Version" field and a "Version Type" field compared to the "Address" table described above.

[0058] A similar history version table can store the complete history of data changes and facilitates reading and writing via SQL when the recorded history version is invoked in subsequent steps. The specific role that the version number field added to the history version table described above plays in rollback transactions initiated by subsequent rollback operations will be explained in detail in step 203 below, so it will not be explained here.

[0059] 202: For data entities that need to be recorded in the historical version table, add annotations to support record modification and initialize the historical version table information. For example, server 200 adds annotations to data entities that need to be recorded in the history version table to support recording the modification process of the content of the target data entity, that is, to support the modification of records. For example, annotations can be added to the Java class of the data structure of the target data entity via "@Audit" provided by the Hibernate Envers tool. Then, when the engine responsible for database storage (Hibernate) parses the code to find this annotation, it can record the change history in the history version table when the data table of the target data entity is updated. Specifically, the procedure for adding annotations to the Java class of the target data entity using @Audit is as follows.

[0060] TIFF0007830703000002.tif125166

[0061] As shown in Figure 3, the historical version data recorded by the @Audit annotation and the data table of the data entity are isomorphic, such as the historical version table "Policy Log" and the data table "Policy". Therefore, the parameter list annotated by @Audit may include several service fields such as "ID", "Operation Type", and "Insurance Amount". In addition to ID and Type, each service field may exist, but it does not include program parameters or user information at the time of the call. Once the annotation is complete, the server 200 can initialize the data content of the target data entity in the generated historical version table and record the corresponding initial version number.

[0062] Hibernate Envers is typically a framework for auditing entities, and @Audit is one of the annotation components used by the Hibernate Envers tool, and is a Java annotation. @Audit is commonly used to annotate an entity class or a Java class that calls an attribute to support modification of data records. In embodiments of this application, the Hibernate Envers tool can be used to record version number information for each data entity in a database and store data changes resulting from data operations in a corresponding isomorphic historical version table.

[0063] In other embodiments, other tools may be used to add “Support for Record Modification” annotations to data entities, but this is not limited to them.

[0064] 203: When a forward operation request for a data entity is detected, the data content of the target data entity is recorded in the history version table, and version information before and after the operation is written. For example, the server 200 can receive a call to a data entity initiated by a service system on which a terminal device is operating, and an operation request generated in response to an operation such as adding, deleting, or modifying the called data entity, i.e., the forward operation request described above. In response to this forward operation request, the server 200 can record the data content and version information of the target data entity in the database before and after the operation, based on the operation details, in the corresponding history version table.

[0065] In some embodiments, this forward operation request may be a distributed transaction operation request written to, for example, a relational database management system (MYSQL) binary log (bin log) event or update log event. Here, the bin log can store all actions that modify table data in the database and may include all updated data or all statements for data that may be updated. In some embodiments, the bin log type can be started using the -log -bin[=file_name] option, and MYSQL writes a log file of SQL commands containing all updated data.

[0066] Update logs can provide query information, but only queries that modify the contents of the database. In some embodiments, update logs can be enabled using the -log-update server option. When the log type is enabled, MySQL creates a file named HOSTNAME.nnn under the data directory. Based on the bin log data obtained through bin log event analysis, it is possible to analyze the specific type of operation request received, for example, whether it is an operation such as adding, deleting, or modifying the initial data content of the target data entity.

[0067] Taking the TCC model for handling distributed transactions as an example, the forward operations that a service system performs by calling data entities include new additions, deletions, and modifications, which involve two stages in TCC mode: an initial operation (Try) and a confirmation operation (Confirm). Taking the SAGA model for handling distributed transactions as an example, the forward operations that a service system performs by calling data entities are the same as new additions, deletions, and modifications in this model. There are no restrictions here.

[0068] As an example, as shown in Figure 3 above, the "Policy Log" table has a "Insurance Amount" field with ID (i.e., primary key) = 100, and the version number under the "Initial Version" field of the first row of records is "1", which corresponds to the "Initial Version" of "1" in the "Policy Log" table and the amount in the "Insurance Amount" field being "1000".

[0069] When a forward operation is detected as a data addition operation for a data entity whose "Primary Key" = 100 (i.e., ID = 100) in the "Policy Log" table and whose "Initial Version" is "1", the type "Newly Added" is recorded under the "Version Type" field of the first row of the historical version table "Policy Log", the version number "2" is written to the "Initial Version" field of the second row of the record, and the data entity-related information after the data addition, with a "Guarantee Amount" of "1500", is written to the second row of the record, as shown in Figure 3. In other embodiments, the historical version table created pursuant to this application may further include, but are not limited to, a "Ending Version" field which may be recorded to indicate the basis of the data content on which the data entity was modified when the version number under the "Initial Version" field was updated.

[0070] Similarly, if other types of data operations are performed, such as modifying data after the data addition operation described above, the "Policy Log" table shown in Figure 3 is referenced, and the data where the "Initial Version" of the first row record is "1" is retrieved and recorded as the initial data in the third row of the "Policy Log" table. The "Modification" type is written under "Version Type" and the version number "3" under "Initial Version" of the third row record, and the "Guarantee Amount" is updated to "1000".

[0071] Once the data correction operation is complete, the fourth record in the "Policy Log" table will have information about the corrected data entity, such as "Correction" type written under the "Version Type" field of the fourth record, version number "5" written under the "Initial Version" field, and the corrected "Insurance Amount" written as "2000".

[0072] 204: When a rollback operation request is detected for the target data entity, retrieve the history version information from the history version table and update the data content with the corresponding history version.

[0073] For example, the server 200 can receive an operation request from a terminal device to roll back the data content of one or more data entities, and in response to the request, query the corresponding history version table using a pre-configured query statement to obtain version number information of the target data entity recorded in the history version table, such as the version number of the "initial version" recorded in the corresponding history version table. Furthermore, based on the obtained version number information, the server 200 can update the data content of the corresponding version in the target data entity. For example, by restoring the data content whose initial version is "1" to the target data entity, the service system can display the corresponding page after the service rollback, such as the updated initial version data content on the page, and is not limited to this. The service system may also generate the rollback operation request to send to the server 200 based on a rollback operation performed by a user on the service system interface. In other embodiments, the server 200 can also roll back a global transaction when it detects abnormal data reported by the global transaction. As an example, when the server 200 queries data with primary key = 100 and history version 1, it can query using SQL such as the following:

[0074] Select * from XXX _ LOG where "Primary Key" = 100 "Initial Version" <= 1 Here, "XXX_LOG" is the name of the historical version table of the target data entity, and could be, for example, the "Policy Log" table or the "Address Log" table shown in Figure 3 above. The "Primary Key" could be, for example, the ID of the "Policy Log" table or the "Address Log" table shown in Figure 3 above. Therefore, the SQL in the example above can retrieve the data from the "Insurance Amount" field of the "Policy Log" table where the initial version number is "1", i.e., "1000", by querying the "Policy Log" table shown in Figure 3 using the "Primary Key" = 101.

[0075] In other words, based on the initial version number "1" queried in the SQL example above, the "Insurance Amount" data on the service system interface can be quickly updated to the insurance amount "1000" corresponding to the initial version number "1" in the "Policy Log".

[0076] Similarly, in a distributed insurance system, if a user manipulates and modifies information such as "address," "insured," and "insured information" of an insurance policy generated by the service system interface, and the service system generates a corresponding rollback operation request in response to the user's operation and sends it to the server 200, the server 200 can execute step 204 to quickly obtain the corresponding initial version data entity to be rolled back based on information such as the version number recorded in the history version table corresponding to the target data entity, and update the data content to the initial version in response to the rollback operation request from the service system.

[0077] Based on the distributed transaction processing method shown in Figure 2 above, the content and changes of data entities before and after operations are recorded in identical history version tables created corresponding to data entities. By adding a small amount of code, such as SQL-related code that calls the history version table, to the data access layer of a program module that supports the rollback function of the service system of terminal devices on the server 200, the rollback capability of the distributed service system, or data compensation capability corresponding to operations such as modification and cancellation, can be realized. Furthermore, since the distributed transaction processing method according to the embodiment of this application is an improvement implemented in the server 200 connected to each terminal device, it can be applied to rollback operations of distributed service systems of various complexities. In other words, the same data rollback logic corresponding to the flow shown in Figure 2 above can be adopted for various distributed service systems, and therefore, the workload for development and maintenance of related service systems is simplified to some extent, and no limitations are imposed here.

[0078] Figure 4 is a schematic block diagram showing the software configuration of a server 200 according to an embodiment of the present invention. As shown in Figure 4, taking as an example a server to which an insurance service system is connected, the server 200 includes a service flow processing module 201, an insurance policy data management module 202, a distributed transaction manager 203, and a database 204.

[0079] Here, the service flow processing module 201 responds to calls from the service system on which the terminal device is running to data entities in the database 204, and receives operation requests such as forward operation requests and rollback operations from the service system on which the terminal device is running. The service flow processing module 201 sends the received operation requests to the insurance policy data management module 202 for the corresponding processing. The service flow processing module 201 may also be responsible for requesting the distributed transaction manager 203 to initiate a global transaction if it determines that the next operation to be performed requires either multiple different data sources or multiple remote calls and data updates.

[0080] The insurance policy data management module 202 is used to call and manage insurance policy data entities in the database 204. Based on the data table structure of the corresponding insurance policy data entities in the database 204, it creates a corresponding historical version table for the insurance policy data entities and is used to record version information before and after operations such as adding, deleting, and modifying insurance policy data, and is also used to record data content that has changed as a result of such data operations. In other embodiments, for non-insurance policy data, the server 200 may also include, but is not limited to, a non-insurance policy data management module 202 for managing non-insurance policy data in the database 204. The historical version table created by the insurance policy data management module 202 is synchronized with the distributed transaction manager 203 so that data operations detected by the distributed transaction manager 203 can be recorded. For specific generation procedures, please refer to the relevant description in step 201 above, and the explanation will be omitted here.

[0081] Furthermore, the insurance policy data management module 202 responds to data manipulation requests transferred by the service flow processing module 201 by executing forward operation requests, such as adding, deleting, or modifying the requested target data entity. It also retrieves the requested target data entity from the database 204 and executes the corresponding operation on that data entity. Simultaneously, the insurance policy data management module 202 can record version information of the data entity before and after the corresponding operation, the specific data content before and after the data entity is manipulated, etc., based on the created history version table. Then, based on the version information recorded in the history version table during the forward operation of the target data entity, it reads the data content corresponding to the initial version and restores it to the target data entity, etc.

[0082] The distributed transaction manager 203 processes information about open global transactions and registered transaction branches, and is responsible for scheduling between the service flow processing module 201 and the insurance policy data management module 202. For example, in response to a global transaction commit notification sent from the service flow processing module 201, it notifies the insurance policy data management module 202 to commit the transaction branch, and in response to a global transaction rollback notification sent from the service flow processing module 201, it coordinates and notifies the insurance policy data management module 202 to roll back the transaction branch.

[0083] Database 204 is used to store and manage a large number of data entities. Each data entity can be created in database 204 to correspond to the data retrieval requirements of a distributed service system. For example, in the case of an insurance service system, the data table structure can be created as shown in Figure 3 above to correspond to the insurance amount and address data in the insurance policy. Note that the data table structures corresponding to each data entity may be the same or different.

[0084] Figure 5 is a schematic diagram showing the communication flow between substructures within a server 200 during the implementation of a distributed transaction processing method according to an embodiment of this application. As shown in Figure 5, this communication flow includes the following steps.

[0085] 501: The insurance policy data management module 202 creates an isomorphic historical version table for the data entity. Here, isomorphic means that the created historical version table is identical or similar to the data table structure of the target data entity. For the specific generation procedure, please refer to the relevant description in step 201 above, and the explanation will be omitted here.

[0086] 502: The insurance policy data management module 202 adds annotations to insurance policy data entities that need to be recorded in the historical version table to support record modification, and initializes the historical version table information. The process of adding annotations to insurance policy data entities to support record modification, and the process of initializing the historical version table, can be found in the related description in step 202 above, so the explanation is omitted here.

[0087] The process by which the insurance policy data management module 202 creates and initializes the historical version table may be synchronized, meaning that what is done by steps 501 and 502 described above may be done in a single step, without limitation.

[0088] 503: The service flow processing module 201 requests the distributed transaction manager 203 to start a global transaction.

[0089] For example, program code executed by the service flow processing module 201 can determine the next operation that needs to be performed, whether it requires the involvement of multiple different data sources, or whether it requires multiple remote calls and data updates, and if so, it requests the distributed transaction manager 203 to initiate a global transaction.

[0090] 504: The service flow processing module 201 receives forward operation requests from the distributed service system, such as new additions, deletions, and modifications. Forward operations are operations performed on the initial version of the target data entity, such as new additions, deletions, and modifications. For details, please refer to the relevant description in step 203 above, so the explanation will be omitted here.

[0091] In some embodiments, forward operation requests such as new additions, deletions, and modifications sent by the distributed service system may be distributed transaction operation requests written to MySQL bin log events or update log events. In response, the service flow processing module 201 can analyze the received bin log events to obtain bin log data, or analyze the received update log events to obtain update log data, and from the analyzed update log data, it can recognize forward operation requests such as additions, deletions, or modifications.

[0092] 505: The service flow processing module 201 sends the received forward operation request to the insurance policy data management module 202.

[0093] For example, in step 503 above, after receiving an operation request for a forward operation such as adding, deleting, or modifying, the service flow processing module 201 can call an Application Programming Interface (API) interface of the insurance policy data management module 202, such as a network API interface based on a Restful interface, and send the received forward operation request and the complete insurance policy data of the requested operation to the insurance policy data management module 202. The insurance policy data management module 202 is responsible for executing the operation request and performing update operations on the target data entity in the database.

[0094] 506: The insurance policy data management module 202 performs operations such as adding, deleting, and modifying target data entities.

[0095] For example, the insurance policy data management module 202 can respond to received forward operation requests by calling a database interface to perform operations such as adding, deleting, or modifying the data content of the target data entity.

[0096] Of these, the insurance policy data management module 202, when processing requests such as new additions, deletions, and modifications, mirrors (i.e. copies) the data of the target data entity before and after the corresponding operation update and organizes it into an undo log. By utilizing the ACID properties of local transactions, it can commit the service data update and the writing of the rollback log to the same local transaction, thereby ensuring that a rollback log corresponding to the committed service data update exists. Furthermore, since a history version table is created, the undo log only needs to store the version number as index information and does not need to store the complete details of the changes. When the insurance policy data management module 202 performs a forward operation or a subsequent rollback operation on the data content of the target data entity, the undo log can read the data content of the corresponding version based on the version information provided by the history version table. This improves the data manipulation processing efficiency of the insurance policy data management module 202.

[0097] In this way, when the service flow processing module 201 decides to commit a global transaction in the subsequent step 509, the insurance policy data management module 202 notifies the distributed transaction manager 203 to commit the transaction branch. When the transaction branch commit is complete, synchronous coordination processing is not required; only the rollback log needs to be cleaned asynchronously, thus enabling the commit to be completed quickly.

[0098] In other embodiments, a Hibernate Interceptor can be used to intercept all database update operations, such as modifying or deleting target data entities. Hibernate stores the mirrored data content before and after the data entity's change in memory, and the Interceptor reads this mirrored data content and writes it to a local undo log table, thereby achieving data mirroring in the undo log. However, this is not limited to this. In this way, the operation of reading the mirrored data before and after the change in SQL can be omitted, improving usability.

[0099] 507: The insurance policy data management module 202 records version information before and after the operation, as well as the operation type, content, etc., in the corresponding history version table. Specifically, the process of recording version information in the history version table can be found in the related explanation in step 203 above, so the explanation is omitted here.

[0100] In some embodiments, the service flow processing module 201 may send the parsed bin log data or update log data to the distributed transaction manager 203 when executing step 503 described above. Based on the received bin log data or update log data, the distributed transaction manager 203 can update the data content and corresponding version information of the corresponding versions of the target data entities in the retrieved historical version table.

[0101] 508: The insurance policy data management module 202 registers the transaction branch with the distributed transaction manager 203. For example, after the insurance policy data management module 202 has completed recording the relevant fields and version information in the history version table by performing step 507 described above, it can trigger the registration of a transaction branch to the distributed transaction manager 203. By registering the transaction branch, the insurance policy data management module 202 can temporarily store some call information in the distributed transaction manager 203 so that when a global transaction is committed or rolled back, the distributed transaction manager 203 can make a callback based on this temporarily stored call information.

[0102] 509: Once the service flow processing module 201 confirms that there are no abnormalities in the global transaction, it sends a request to the distributed transaction manager 203 to commit the global transaction. For example, the service flow processing module 201 can retrieve anomalies reported on each interface or proxy node during the processing of a global transaction, such as database write failures or network anomalies. If no anomalies are found, the service flow processing module 201 can call the commit interface of the distributed transaction manager 203 to request the commit of the global transaction.

[0103] 510: The distributed transaction manager 203 notifies the insurance policy data management module 202 of the commit of the transaction branch. For example, in response to a request to commit an received global transaction, the distributed transaction manager 203 can notify the insurance policy data management module 202 of the commit by committing the transaction branch. Based on the commit notification, the insurance policy data management module 202 can delete the local undo log record.

[0104] After the service flow processing module 201 decides to commit a global transaction, the insurance policy data management module 202 can notify the distributed transaction manager 203 to commit the transaction branch, and at the same time, it does not require synchronous coordination processing and only requires asynchronous cleanup of the rollback log, meaning that the process of committing the transaction branch can be completed quickly.

[0105] In some embodiments, the distributed transaction manager 203 can obtain a list of currently active transactions in order to achieve data content consistency of data entities to be imported and exported in the corresponding database. Of these, the active transaction list is used to mark the completion status of import and export operations on the data tables of each data entity in the current database, and the execution of import and export operations on the data tables of the target data entities is for the purpose of realizing operations such as adding, deleting, and modifying the corresponding data tables. Furthermore, when the distributed transaction manager 203 derives target data entities from the database and performs operations such as adding, deleting, and modifying them, it may generate a data consistency compensation statement based on the active transaction list and the database log, and instruct the database to execute the statement so that the data content of the target data entities imported and exported from the database is consistent during the process of performing operations such as adding, deleting, and modifying the target data entities. The database log may be, for example, log data obtained by the service flow processing module 201 in step 503 by analyzing bin log events and update log events.

[0106] In other embodiments, the distributed transaction manager 203 may, in other ways, ensure that the data content is consistent when the data entities under operation are imported and exported from the corresponding database.

[0107] 511: When the service flow processing module 201 detects an anomaly in a global transaction, it sends a request to the distributed transaction manager 203 to roll back the global transaction. For example, if the service flow processing module 201 receives a rollback operation request from a distributed service system, or obtains abnormal data such as a database write failure or network anomaly, it can confirm that there is an anomaly in the global transaction and call the rollback interface of the distributed transaction manager 203 to request a rollback of the global transaction.

[0108] If the service flow processing module 201 detects a rollback of a global transaction, the rollback may be coordinated by a distributed transaction manager, for example, the distributed transaction manager 203 may perform step 512 to notify the insurance policy data management module 202 to roll back the transaction branch.

[0109] In other embodiments, the service flow processing module 201 may also receive rollback operation requests sent by the distributed service system in response to user operations, generate rollback requests for global transactions, and enable fast rollback of service data. There are no limitations here.

[0110] Here, a rollback operation request from a distributed service system may be, for example, a distributed transaction operation request recorded in a MySQL bin log event. In response, the service flow processing module 201 can parse the received bin log event to obtain bin log data, such as a rollback operation request. Furthermore, the service flow processing module 201 can identify the rollback operation request based on the bin log data obtained through the parsing.

[0111] 512: The distributed transaction manager 203 notifies the insurance policy data management module 202 to roll back the transaction branch. For example, the distributed transaction manager 203 can respond to a request to roll back an received global transaction by notifying the insurance policy data management module 202 of the rollback of the transaction branch. Based on the rollback notification, the insurance policy data management module 202 can perform a data restoration operation based on the version information recorded in the history version table. Performing data recovery operations based on version information recorded in the historical version table is more efficient, faster, and more direct.

[0112] 513: The insurance policy data management module 202 reads the data content of the corresponding version from the database based on the historical version information before the change and restores it to the called target data entity. The historical version information is, for example, the initial version number. Specifically, the process for obtaining the historical version information can be found in the related description in step 204 above, but is not limited thereto.

[0113] When the insurance policy data management module 202 receives a rollback notification from the distributed transaction manager 203, it can locate the corresponding rollback log record via the global transaction ID (i.e., XID) and transaction branch ID (i.e., Branch ID), read the corresponding data content in the historical version table based on the historical version information in the rollback log record, and further generate and execute reverse update SQL to complete the rollback of the transaction branch.

[0114] Therefore, the distributed transaction processing technology based on the historical version table of this application enables the insurance policy data management module 202 to implement shortcut operations and rollback functions based on historical versions, and can be implemented simply by reading or recording the historical version ID corresponding to the corresponding insurance policy data (i.e., the target data entity), without the need to reread and store the data content before and after the change.

[0115] When the insurance policy data management module 202 restores data content to the target data entity based on historical version information, the interface display content of the corresponding distributed service system is also updated to the corresponding historical version of the data content. Specifically, refer to the relevant description in step 204 above, but are not limited thereto.

[0116] Figure 6 is a schematic diagram showing the hardware configuration of server 200 according to an embodiment of the present invention. As shown in Figure 6, in some embodiments, the server 200 may include one or more processors 604, a system control logic 608 connected to at least one of the processors 604, a system memory 612 connected to the system control logic 608, a non-volatile memory (NVM) 616 connected to the system control logic 608, and a network interface 620 connected to the system control logic 608.

[0117] In some embodiments, the processor 604 may include one or more single-core or multi-core processors. In some embodiments, the processor 604 may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, baseband processors, etc.). In embodiments in which the server 200 uses an eNB (Evolved Node B) 101 or a RAN (Radio Access Network) controller 102, the processor 604 may be configured to perform various adapted embodiments, such as one or more of the embodiments shown in Figures 2-5.

[0118] In some embodiments, the system control logic 608 may include any suitable interface controller to provide any suitable interface to at least one of the processors 604 and / or any suitable device or component communicating with the system control logic 608.

[0119] In some embodiments, the system control logic 608 may include one or more memory controllers that provide an interface connected to the system memory 612. The system memory 612 can be used to load and store data and / or instructions. In some embodiments, the memory 612 of the server 200 may include any suitable volatile memory, such as suitable dynamic random access memory (DRAM). The NVM / memory 616 may include one or more tangible, non-temporary, computer-readable media for storing data and / or instructions. In some embodiments, the NVM / memory 616 may include any suitable non-volatile memory, such as flash memory, and / or at least one of any suitable non-volatile storage devices, such as a hard disk drive (HDD), a compact disc (CD) drive, or a digital versatile disc (DVD) drive. The NVM / memory 616 may include part of the storage resources on the device on which the server 200 is installed, or the NVM / memory 616 may not necessarily be part of the device but may be accessed by the device. For example, the NVM / storage 616 may be accessed over a network via a network interface 620.

[0120] In particular, system memory 612 and NVM / memory 616 may include temporary and permanent copies of instruction 624, respectively. Instruction 624 may include instructions that, when executed by at least one of the processors 604, cause the server 200 to perform actions as shown in Figures 3-4. In some embodiments, instruction 624, hardware, firmware, and / or its software components may be additionally / alternatively located within the system control logic 608, network interface 620, and / or processor 604.

[0121] The network interface 620 may include transceivers for providing a wireless interface to the server 200 and for communicating with any other suitable devices (e.g., front-end modules, antennas, etc.) over one or more networks. In some embodiments, the network interface 620 may be integrated with other components of the server 200. For example, the network interface 620 may be integrated with at least one of the processor 604, system memory 612, NVM / memory 616, and a firmware device (not shown) having instructions, and the server 200 performs the method shown in Figures 2 to 5 above when at least one of the processors 604 executes instructions. The network interface 620 may further include any suitable hardware and / or firmware to provide a multi-input multi-output wireless interface. For example, the network interface 620 may be a network adapter, a wireless network adapter, a telephone modem, and / or a wireless modem.

[0122] In one embodiment, at least one of the processors 604 may be packaged together with the logic of one or more controllers of the system control logic 608 to form a system package (SiP). In one embodiment, at least one of the processors 604 may be integrated onto the same die as the logic of one or more controllers of the system control logic 608 to form a system-on-a-chip (SoC).

[0123] The server 200 may further include an input / output (I / O) device 632. The I / O device 632 may include a user interface that allows a user to communicate with the server 200, and the design of the peripheral component interface may also allow peripheral components to communicate with the server 200. In some embodiments, the server 200 further includes sensors for determining at least one of environmental conditions and location information related to the server 200.

[0124] In some embodiments, the user interface may include, but is not limited to, a display (e.g., a liquid crystal display, a touchscreen display), a speaker, a microphone, one or more cameras (e.g., a still image camera and / or a video camera), a flashlight (e.g., a light-emitting diode flash), and a keyboard.

[0125] In some embodiments, the peripheral component interface may include, but is not limited to, a non-volatile memory port, an audio jack, and a power interface.

[0126] In some embodiments, the sensors may include, but are not limited to, a gyroscope, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of or communicate with the network interface 620 in order to communicate with components of the positioning network (such as Global Positioning System (GPS) satellites).

[0127] Any reference in this specification to “one embodiment” or “embodiment” means that at least one exemplary embodiment or technique disclosed in accordance with the embodiments of this application includes certain features, structures or characteristics described in relation to the embodiment. The phrase “in one embodiment” appearing in various parts of this specification does not necessarily refer to the same embodiment.

[0128] The disclosure of embodiments of this application also relates to a device for performing operations within text. The device may be constructed for a particularly desired purpose or may include a general-purpose computer that is selectively started or reconfigured by a computer program stored in the computer. Such a computer program may be stored on a computer-readable medium such as a disk, including but not limited to any type of disk suitable for storing electronic instructions, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, application-specific integrated circuits (ASICs), or any other type of medium, each of which may be coupled to a computer system bus. Furthermore, the computer referred to herein may include a single processor or may be an architecture using multiple processors for increased computing power.

[0129] Furthermore, the language used herein has been selected primarily for readability and instructional purposes and may not be chosen to describe or limit the disclosed subject matter. Accordingly, the disclosures of embodiments of this application are intended to illustrate, not limit, the scope of the concepts discussed herein.

Claims

1. A distributed transaction processing method applicable to a system including a service flow processing module, an insurance policy data management module, and a distributed transaction manager, The insurance policy data management module creates and initializes a historical version table, the historical version table is for recording the data content and version information of each version of the target data entity, the initialized version information includes first version information, and the first version information corresponds to the data content of the first version of the target data entity. The service flow processing module requests the distributed transaction manager to initiate a global transaction, The service flow processing module receives a first type of operation request for the target data entity and transmits the first type of operation request to the insurance policy data management module, wherein the first type of operation request requests that a first type of operation be performed on the first version of the data content of the target data entity, and the first type of operation includes at least one of an add, delete, or modify operation. The insurance policy data management module, in response to the first type of operation request, reads the history version table, records the second version of the data content obtained by performing the first type of operation on the first version of the data content, and registers a transaction branch with the distributed transaction manager, wherein the transaction branch is an associated transaction that performs the first type of operation. The distributed transaction manager notifies the insurance policy data management module to commit a transaction branch in response to a first request to commit a global transaction sent by the service flow processing module, The aforementioned history version table is: It is created by a method that creates a history version table identical to the first data table structure based on the first data table structure corresponding to the target data entity, Each parameter in the parameter list of the historical version table is associated with each parameter in the first data table structure. The aforementioned association is A distributed transaction processing method characterized in that an insurance policy data management module is created by adding first annotation information to the first data table structure using a pre-configured annotation tool, and when the first annotation information is analyzed by a storage management engine, it is used to update each parameter of the history version table in accordance with changes in each parameter of the first data table structure.

2. Reading the historical version table and recording the second version of data content obtained by performing the first type of operation on the first version of data content is: The insurance policy data management module writes the data content of the second version to the historical version table, and writes the second version information to the historical version table in accordance with the data content of the second version. The distributed transaction processing method according to claim 1, characterized in that the insurance policy data management module writes the first version information and the second version information to a log for undoing a rollback.

3. The service flow processing module obtains abnormal data within the global transaction or a second type of operation request for the received target data entity, and sends a second request to the distributed transaction manager to roll back the global transaction, wherein the second request requests that the global transaction be rolled back in order to update the data content of the target data entity from the second version of the data content to the first version of the data content. The distributed transaction manager notifies the insurance policy data management module to roll back the transaction branch in response to the second request, The distributed transaction processing method according to claim 2, further comprising the insurance policy data management module retrieving the data content of the first version based on the first version information recorded in the history version table, based on a notification to roll back the transaction branch, and restoring it to the current data content of the target data entity.

4. The log for undoing the rollback includes a rollback log, and retrieving the data content of the first version based on the first version information recorded in the historical version table is: The insurance policy data management module obtains the first version information recorded in the rollback log, The distributed transaction processing method according to claim 3, characterized in that the insurance policy data management module obtains the data content of the first version based on the correspondence between the first version information recorded in the history version table and the data content of the first version.

5. The parameter list of the aforementioned history version table includes the primary key, type, initial version, and service fields awaiting recording. The distributed transaction processing method according to claim 1, characterized in that the version information includes the version number recorded in the initial version field of the historical version table.

6. The aforementioned pre-configured annotation tool is @Audit, provided by Hibernate Envers. The distributed transaction processing method according to claim 1, characterized in that the storage management engine is Hibernate.

7. The distributed transaction processing method according to claim 1, characterized in that the first version information is the first version number recorded in the initial version field of the history version table.

8. The insurance policy data management module reads the history version table in response to the first type of operation request. The distributed transaction processing method according to claim 1, characterized in that the insurance policy data management module reads the history version table based on a pre-configured SQL that includes at least the name, primary key, and version number correspondingly recorded in the initial version field of the history version table.

9. The first type of operation request is a distributed transaction operation request written to a MySQL bin log event or update log event. The service flow processing module receives a first type of operation request for the target data entity and transmits the first type of operation request to the distributed transaction manager, The service flow processing module determines that the first type of operation request is a distributed transaction operation request written to a MySQL bin log event or update log event, The service flow processing module analyzes the received bin log event to obtain bin log data, or analyzes the received update log event to obtain update log data. The service flow processing module identifies distributed transaction operation requests corresponding to add, delete, or modify operations based on the bin log data or the update log data. The distributed transaction processing method according to any one of claims 1 to 8, characterized in that the service flow processing module transmits the identified distributed transaction operation request as the first type of operation request to the insurance policy data management module.

10. The second type of operation request is a distributed transaction operation request written to a MySQL bin log event. The service flow processing module receives a second type of operation request for the target data entity and sends a second request to the distributed transaction manager to roll back the global transaction, The service flow processing module analyzes the received bin log event to obtain bin log data, The service flow processing module identifies a rollback operation request that requests updating the returned second version of the data content to the first version of the data content, based on the bin log data. The distributed transaction processing method according to claim 3 or 4, characterized in that the service flow processing module sends a second request to the distributed transaction manager to roll back a global transaction based on an identified rollback operation request.

11. The second type of operation request is, A request to cancel the first type of operation, The distributed transaction processing method according to claim 3, comprising a request to retrieve the first version of the data content and perform the first type of operation again.

12. The aforementioned target data entities are stored in a database for distributed transactions. In the process of performing the first type of operation, the distributed transaction manager obtains an active transaction list at the current time, the active transaction list is for marking the progress of the first type of operation performed on each data entity in the database, and each data entity in the database includes the target data entity; and the distributed transaction manager generates consistency compensation statements and compensation orders based on the active transaction list and log data corresponding to the target data entity generated by the current database, and sends these to the database, the compensation orders being for instructing the database to update the real-time data content corresponding to the progress of the first type of operation with the data content of the target data entity in the database by executing the consistency compensation statements. The distributed transaction processing method according to claim 1, characterized in that it includes matching the data content of the target data entity stored in the database with the real-time data content of the target data entity operated by the insurance policy data management module.

13. A distributed transaction processing system including a service flow processing module, an insurance policy data management module, and a distributed transaction manager, The insurance policy data management module is, The process involves creating and initializing a historical version table, wherein the historical version table is for recording the data content and version information of each version of the target data entity, the initialized version information includes first version information, and the first version information corresponds to the data content of the first version of the target data entity. This is used to read the history version table in response to a first type of operation request, record the second version of the data content obtained by performing a first type of operation on the first version of the data content, and register a transaction branch with the distributed transaction manager, wherein the transaction branch is an associated transaction that performs the first type of operation. The service flow processing module is: Receiving a first type of operation request for the target data entity and transmitting the first type of operation request to the insurance policy data management module, wherein the first type of operation request requests to perform a first type of operation on the data content of a first version of the target data entity, and the first type of operation includes at least one of an add, delete, or modify operation. This is used to obtain abnormal data within a global transaction, or a second type of operation request for the received target data entity, and to send a second request to a distributed transaction manager to roll back the global transaction, wherein the second request is for requesting a rollback of the global transaction in order to update the data content of the target data entity from the second version of the data content to the first version of the data content, A distributed transaction manager is The service flow processing module receives a notification sent by the service flow processing module and initiates a global transaction, and the insurance policy data management module receives a request to register a transaction branch and stores the registration information of the transaction branch. Based on a notification to commit a global transaction sent by the service flow processing module, the insurance policy data management module is notified to commit the transaction branch, and is used for the following: The aforementioned history version table is: It is created by a method that creates a history version table identical to the first data table structure based on the first data table structure corresponding to the target data entity, Each parameter in the parameter list of the historical version table is associated with each parameter in the first data table structure. The aforementioned association is A distributed transaction processing system characterized in that the insurance policy data management module is created by adding first annotation information to the first data table structure using a pre-configured annotation tool, and when the first annotation information is analyzed by the storage management engine, it is used to update each parameter of the history version table in accordance with changes in each parameter of the first data table structure.

14. It is a device, Equipped with one or more processors and one or more memory units, The apparatus is characterized in that the one or more memories store one or more programs, and when one or more programs are executed by the one or more processors, the apparatus is made to execute the distributed transaction processing method described in claim 1 or 2.

15. A computer-readable storage medium, A computer-readable storage medium characterized in that, when executed by a computer, it stores instructions that cause the computer to execute the distributed transaction processing method described in claim 1 or 2.

Images