A lightweight distributed process transaction controller and method

Abstract

This invention relates to a lightweight distributed process transaction controller and method, comprising: a process initiator executor, a node method executor, and a retry executor; the process initiator executor: during code execution, when a method marked with the `@ProcessStart` annotation is encountered, the aspect enters the process initiation execution logic, serving as the entry point for starting a global process transaction; the node method executor: intercepts and processes methods marked with the `@ProcessStep` annotation, generating corresponding node records for the process and recording the execution status of each node; the retry executor: if process execution fails, a `Process UnknownException` is thrown, and after a predetermined number of retries in a memory thread pool, the retry executor schedules retries periodically. This invention solves the problems of existing distributed transactions not supporting remote calls and complex coding, adopts a low-intrusion coding method based on annotations, can be combined with native database transactions, meets the data consistency requirements of most scenarios, and does not depend on other middleware.

Description

Technical Field

[0001] This invention relates to the field of distributed process transaction technology, and in particular to a lightweight distributed process transaction controller and method. Background Technology

[0002] Distributed transaction theory supports frameworks such as XA, TCC, SAGA, and MQ transactions. Currently, mature open-source products include Alibaba's Seata and Apache ShardingSphere. Excellent process engine frameworks include Activiti, a framework based on the BPM protocol. Distributed transactions are primarily implemented using databases, which cannot meet the needs of scenarios involving remote calls or NoSQL databases that do not support transactions. Some also require a transaction coordinator, relying on its stability and making them heavyweight components. The XA mode requires database support for the XA protocol, and participants are in a synchronous blocking state during the transaction commit phase, consuming system resources and resulting in poor performance. The TCC mode needs to be bound to specific business scenarios, making it highly intrusive and tightly coupled. MQ transactions are complex to code. Various Seata implementations require all systems to adhere to the same coding standards, along with Seata transactions. Process control: Current process control frameworks focus on process reversal, lacking distributed transaction support, and their configuration files are complex, making them unsuitable for distributed transaction scenarios. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention proposes a lightweight distributed process transaction controller and method. This method can solve problems such as the lack of support for remote calls in existing distributed transactions and the complexity of coding. It adopts a low-intrusion coding method based on annotations, which is simple to implement and can be combined with native database transactions to meet the data consistency requirements of most scenarios without relying on other middleware.

[0004] To achieve the above objectives, the technical solution adopted by the present invention includes:

[0005] A lightweight distributed process transaction controller, characterized in that the distributed process transaction controller includes: a process initiation executor, a node method executor, and a retry executor;

[0006] Process start executor: During code execution, when a method marked with the ProcessStart annotation is encountered, the aspect enters the process start execution logic, which is the entry point to start a global process transaction;

[0007] Node method executor: intercepts and processes methods marked with the ProcessStep annotation, generates corresponding node records for the process, and records the execution status of each node;

[0008] Retry executor: If the process fails, a ProcessUnknownException is thrown. After a predetermined number of retries in the memory thread pool, the retry executor will schedule retries periodically.

[0009] Furthermore, the process initiation executor includes the following steps:

[0010] Retrieve the parameters from the ThreadLocal invokeRetry variable and determine whether the execution needs to be retried on failure. By default, it needs to be retried on failure. If the parameter value is set to false in the retry executor, then it does not need to be retried on failure.

[0011] Get the parameter in the ProcessStart annotation indicating whether it is asynchronous. If it is asynchronous, return null and start a child thread to continue execution.

[0012] The executor starts by retrying the executor execution process. If a ProcessException is caught, it is thrown directly. If an exception is caught, it is wrapped as a ProcessException and thrown outwards in a unified manner.

[0013] The input parameters are obtained from the aspect method. The flow parameters and transaction type parameters are dynamically parsed using SPEL. The flow parameters and transaction type parameters are used to query whether a process record exists. If a process record exists, the status of the process record determines whether to return normally or throw an exception.

[0014] Add a distributed lock, push the input method onto the stack, generate a process record based on the input method parameters and store it in the database, put the process method into the context, determine the execution direction of the process method, execute the process method and catch exceptions; the execution direction of the process method includes: forward sub-methods and reverse sub-methods, and trigger process reversal according to different exceptions encountered during the execution of the process method.

[0015] Furthermore, the process of adding a distributed lock, pushing the input parameter method onto the stack, generating a process record based on the input parameter method and storing it in the database, placing the process method into the context, determining the execution direction of the process method, executing the process method and catching exceptions includes:

[0016] If the execution direction of the process method is a forward sub-method, then the business method annotated with ProcessStart is called. If an unknown exception is caught, then ProcessReverseException is thrown, and the entire process is rolled back.

[0017] If the execution direction of the process method is a reverse sub-method, then query the successfully executed node, generate the corresponding backflush node and execute it, catch any thrown exceptions, and perform state changes based on the exceptions. If the exception is unknown, then throw a ProcessUnknownException and continue to retry.

[0018] Furthermore, the node process executor includes the following steps:

[0019] Get the latest process record parameters in the stack in the context, query the node record in the database based on the process record parameters, and if the node record does not exist, generate the node record and add it to the database.

[0020] Based on the state of the node record, determine whether to skip or execute the business method marked with ProcessStep;

[0021] If a business method annotated with ProcessStep is executed, an exception will be caught.

[0022] If the exception is unknown, check if there is an exception class corresponding to skip in the configuration of ProcessStep; if there is an exception class corresponding to skip in the configuration of ProcessStep, the current step is executed successfully.

[0023] If the configuration in ProcessStep does not contain an exception class corresponding to skip, a ProcessUnknownException will be thrown, and execution will be retried.

[0024] Furthermore, the retry actuator includes the following steps:

[0025] Based on the pre-configured retry days, the sharded query status is a process record in progress;

[0026] Iterate through the process records and obtain the process Method object using reflection based on the method name and parameter list;

[0027] Retrieve the bean instance of the class corresponding to the method based on the Spring context;

[0028] Setting the invokeRetry parameter in ThreadLocal to false enables the execution of the bean instance's Method via reflection, thus restarting the process.

[0029] The present invention also relates to a computer-readable storage medium, characterized in that the storage medium stores a computer program, which, when executed by a processor, implements the above-described lightweight distributed process transaction control method.

[0030] The present invention also relates to an electronic device, characterized in that it includes a processor and a memory;

[0031] The memory is used to store the process start executor, the node method executor, and the retry executor;

[0032] The processor is used to execute the aforementioned lightweight distributed process transaction control method by invoking the process start executor, node method executor, and retry executor.

[0033] The present invention also relates to a computer program product, including a computer program and / or instructions, characterized in that, when the computer program and / or instructions are executed by a processor, they implement the steps of the above-described lightweight distributed process transaction control method.

[0034] The beneficial effects of this invention are as follows:

[0035] This invention proposes a lightweight distributed process transaction controller and method, along with a lightweight, annotation-based, low-intrusion coding approach for process transaction control. This addresses issues such as the lack of remote call support and complex coding in existing distributed transactions. Through a lightweight process control framework and annotation-based low-intrusion coding, it is simple to implement, can be integrated with native database transactions, meets data consistency requirements in most scenarios, and does not depend on other middleware. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of a lightweight distributed process transaction controller structure according to the present invention.

[0037] Figure 2 This is a schematic diagram of a lightweight distributed process transaction control method according to the present invention.

[0038] Figure 3 This is a schematic diagram of an embodiment of a lightweight distributed process transaction control method of the present invention. Detailed Implementation

[0039] To better understand the content of this invention, a detailed description will be provided in conjunction with the accompanying drawings and embodiments.

[0040] process is a lightweight process control framework that provides a solution for distributed service consistency. It achieves eventual consistency but does not guarantee isolation.

[0041] Flow control is implemented using low-intrusion annotations, and the forward flow can branch.

[0042] The status and execution steps are recorded in the database, relying on automatic compensation for duplicate job and thread pool scheduling.

[0043] Based on normal business logic, annotations are added to the method declarations for process start and process steps. Aspect-oriented programming is used to obtain dynamic process parameters from the method annotations at runtime, and process reversal is determined based on the exceptions thrown in the process steps.

[0044] During code execution, when the framework encounters the `@ProcessStart` annotation, it will start a transaction record. If it encounters nested annotations, it will push the previous transaction onto the stack and start a new transaction record. When it encounters `@ProcessStep`, it will mark the current method as a process step. Developers need to ensure its atomicity (using native database transactions) and idempotency. The step can have a corresponding `reverse` method, which will be executed during rollback.

[0045] During rollback, each step is executed in reverse order according to its `reverseMethod`. Steps that do not require rollback (i.e., `reverseMethod` is empty) are left unprocessed. Retry scheduling is triggered asynchronously, first in the thread pool, with a default retry pattern of linearly increasing Fibonacci retries, followed by compensation through job retries.

[0046] The first aspect of this invention relates to a lightweight distributed process transaction controller, such as... Figure 1 As shown, it includes:

[0047] The distributed process transaction controller includes: a process initiation executor, a node method executor, and a retry executor;

[0048] Process start executor: During code execution, when a method marked with the ProcessStart annotation is encountered, the aspect enters the process start execution logic, which is the entry point to start a global process transaction;

[0049] Node method executor: intercepts and processes methods marked with the ProcessStep annotation, generates corresponding node records for the process, and records the execution status of each node;

[0050] Retry executor: If the process fails, a ProcessUnknownException is thrown. After a predetermined number of retries in the memory thread pool, the retry executor will schedule retries periodically.

[0051] Another aspect of this invention relates to a lightweight distributed process transaction control method, such as... Figure 2 As shown, this is a schematic diagram of an embodiment of a lightweight distributed process transaction control method of the present invention. Figure 3 As shown. Includes:

[0052] Process start executor: During code execution, methods marked with the ProcessStart annotation will enter the process start execution logic, which is the entry point to start a global process transaction.

[0053] The process retrieves parameters from the `ThreadLocal invokeRetry` variable, checks whether a retry is needed for this execution, and then executes the corresponding method. By default, a new process should start with a retry; only when this value is set to false each time the retry executor is restarted will automatic retries not be required.

[0054] Get parameters such as whether it is asynchronous from the ProcessStart annotation. If it is asynchronous, return null and start a child thread to continue execution; otherwise, execute synchronously.

[0055] The executor uses a retry mechanism to start the execution process. This ensures that if execution fails, it will automatically retries the specified number of times in memory, without relying on the retry mechanism. If a ProcessException is caught, it is thrown directly. Other exceptions are also wrapped into ProcessExceptions and thrown externally for consistent handling.

[0056] The process flow and transaction type are dynamically parsed from the input parameters using SPALE. These two parameters are then used to check if a process record already exists. If so, its status is assessed to determine whether to return normally or throw an exception.

[0057] A distributed lock is acquired, and the current method is pushed onto the stack to accommodate nested flow scenarios. Then, based on the input method parameters, a flow record is generated and stored in the database, placed in the context, and its execution direction is determined. The corresponding forward or reverse sub-method is executed. This step catches exceptions, and determining the flow reversal direction based on various exceptions is crucial for flow control. Different exceptions encountered during the execution of the flow method trigger flow reversals, categorized as follows:

[0058] ProcessOverException: The process has stopped and will not be retried.

[0059] ProcessReverseException: Process rollback and retry;

[0060] ProcessUnknownException: Asynchronous process retry;

[0061] Other exceptions: Asynchronous process retry;

[0062] The forward sub-method will actually call the business method annotated with ProcessStart. If an unknown exception is caught, a ProcessReverseException will be thrown, and the entire process will roll back.

[0063] The reverse sub-method will query all successfully executed nodes in the current process, generate the corresponding rollback nodes in sequence and execute them. At the same time, it will catch the thrown exceptions and change the state according to different exceptions. If there is an unknown exception, it will throw a ProcessUnknownException and continue to retry instead of rolling back.

[0064] Node method executor: intercepts and processes each process node, generates its corresponding node record, and ensures its state consistency.

[0065] Find the latest process record parameter in the context stack, query the process record node record from the database based on the parameter, and if not found, generate the node record and add it to the database.

[0066] Based on the status recorded in the node, the system selects to skip or execute the business method annotated with ProcessStep. When executing the business method, various exceptions will be caught. If it is an unknown exception, the system checks whether there is an exception class corresponding to skip in the ProcessStep configuration. If there is, the current step is executed successfully; otherwise, a ProcessUnknownException is thrown, and the execution is retried.

[0067] Retry executor: When a process fails and throws a ProcessUnknownException, it will be retried. After a predetermined number of relatively frequent retries in the memory thread pool, the retry executor will schedule retries periodically.

[0068] Based on the configured retry days, query all process records in the "processing" state in shards.

[0069] Iterate through the process records and use reflection to obtain the process Method object based on the method name and parameter list.

[0070] Get the bean instance of the class corresponding to this method from the Spring context.

[0071] The invokeRetry parameter in ThreadLocal is set to false because this is task scheduling rather than a new process, so there is no need for repeated scheduling in memory. Then, reflection is used to execute the Method of the corresponding bean instance and start the corresponding process.

[0072] It should be noted that:

[0073] Methods marked with @ProcessStart are called process methods, while those marked with @ProcessStep are node methods.

[0074] Node methods must be idempotent. Transactions cannot be added at the @ProcessStart (process method) level, but can be added at the @ProcessStep node method.

[0075] The process methods and methods at each node need to be callable; otherwise, the process start or steps become ordinary methods, and consistency is no longer supported.

[0076] The input parameters of the reverseMethod method should be consistent with those of the forward node method. They can be in different classes, but the reverseMethodClass needs to be specified.

[0077] In process methods, unknown exceptions will cause the entire business to fail and roll back by default, while in node methods, unknown exceptions will be retried.

[0078] If a normal step in a process method needs to be idempotent or should not be executed repeatedly, it needs to be added to the node method, because a forward process retry will execute the code that has already succeeded, while a normal method will not.

[0079] Description of parameters in annotations:

[0080] ProcessStart:transId requires a global serial number and can be obtained using SPEL expressions; async: whether the first call is asynchronous; maxRetries: the maximum number of retries, default is 40; lockWaitTime: the lock acquisition timeout; lockLeaseTime: the default lock release timeout.

[0081] ProcessStep:noRetryFor: Which exceptions will not be retried; noRetrySkip: Whether this step succeeds or fails to roll back completely when these exceptions are encountered.

[0082] Embodiments of the present invention also provide a computer-readable storage medium capable of implementing all the steps of the methods in the above embodiments, wherein the computer-readable storage medium stores a computer program that, when executed by a processor, implements all the steps of the methods in the above embodiments.

[0083] Embodiments of the present invention also provide an electronic device for executing the above-described method. As an implementation device for the method, the electronic device has at least a processor and a memory. In particular, the memory stores data and related computer programs required for executing the method, such as a process start executor, a node method executor, a retry executor, etc. The processor calls the data and programs in the memory to execute all the steps of the method and obtain the corresponding technical effect.

[0084] Preferably, the electronic device may include a bus architecture, which may include any number of interconnected buses and bridges. The bus will include various circuits linked together by one or more processors and memories. The bus may also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface between the bus and the receiver and transmitter. The receiver and transmitter may be the same element, i.e., a transceiver, providing a unit for communicating with various other systems over a transmission medium. The processor is responsible for managing the bus and general processing, while the memory may be used to store data used by the processor during operation.

[0085] Additionally, the electronic device may further include components such as a communication module, an input unit, an audio processor, a display, and a power supply. The processor (or controller, operating control) used may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device; the memory may be one or more of a buffer, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices, which can store the aforementioned data information, and may also store programs for executing the information, and the processor can execute the program stored in the memory to achieve information storage or processing, etc.; the input unit is used to provide input to the processor, for example, it can be a button or touch input device; the power supply is used to provide power to the electronic device; the display is used to display images and text, for example, it can be an LCD display. The communication module is a transmitter / receiver that transmits and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor to provide input signals and receive output signals, which can be the same as in conventional mobile communication terminals. Based on different communication technologies, multiple communication modules can be incorporated into the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) is also coupled to a speaker and microphone via an audio processor to provide audio output through the speaker and receive audio input from the microphone, thereby enabling typical telecommunications functions. The audio processor can include any suitable buffer, decoder, amplifier, etc. Furthermore, the audio processor is coupled to a central processing unit, enabling on-device recording via the microphone and on-device playback of stored sound via the speaker.

[0086] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0087] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0088] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction set implemented in a process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0089] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the functions specified in one or more boxes. Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0090] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited.

[0091] Therefore, any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this invention should be included within the protection scope of this invention. Thus, the protection scope of this invention should be determined by the scope of the claims.

Claims

1. A lightweight distributed process transaction controller, characterized in that, The distributed process transaction controller includes: a process initiation executor, a node method executor, and a retry executor; Process start executor: During code execution, when a method marked with the ProcessStart annotation is encountered, the aspect enters the process start execution logic, which is the entry point to start a global process transaction; Node method executor: intercepts and processes methods marked with the ProcessStep annotation, generates corresponding node records for the process, and records the execution status of each node; Retry executor: If the process fails to execute, a ProcessUnknownException is thrown. After retrying a predetermined number of times in the memory thread pool, the retry executor will schedule the retry periodically. The process initiator includes: Retrieve the parameters from the ThreadLocal invokeRetry variable and determine whether the execution needs to be retried on failure. By default, it needs to be retried on failure. If the parameter value is set to false in the retry executor, then it does not need to be retried on failure. Get the parameter in the ProcessStart annotation indicating whether it is asynchronous. If it is asynchronous, return null and start a child thread to continue execution. The executor starts by retrying the executor execution process. If a ProcessException is caught, it is thrown directly. If an exception is caught, it is wrapped as a ProcessException and thrown outwards in a unified manner. The input parameters are obtained from the aspect method. The flow parameters and transaction type parameters are dynamically parsed using SPEL. The flow parameters and transaction type parameters are used to query whether a process record exists. If a process record exists, the status of the process record determines whether to return normally or throw an exception. Add a distributed lock, push the input method onto the stack, generate a process record based on the input method parameters and store it in the database, put the process method into the context, determine the execution direction of the process method, execute the process method and catch exceptions; the execution direction of the process method includes: forward sub-methods and reverse sub-methods, and trigger process reversal according to different exceptions encountered during the execution of the process method.

2. A lightweight distributed process transaction control method, applied to the distributed process transaction controller as described in claim 1, characterized in that, The process initiation executor includes the following steps: Retrieve the parameters from the ThreadLocal invokeRetry variable and determine whether the execution needs to be retried on failure. By default, it needs to be retried on failure. If the parameter value is set to false in the retry executor, then it does not need to be retried on failure. Get the parameter in the ProcessStart annotation indicating whether it is asynchronous. If it is asynchronous, return null and start a child thread to continue execution. The executor starts by retrying the executor execution process. If a ProcessException is caught, it is thrown directly. If an exception is caught, it is wrapped as a ProcessException and thrown outwards in a unified manner. The input parameters are obtained from the aspect method. The flow parameters and transaction type parameters are dynamically parsed using SPEL. The flow parameters and transaction type parameters are used to query whether a process record exists. If a process record exists, the status of the process record determines whether to return normally or throw an exception. Add a distributed lock, push the input method onto the stack, generate a process record based on the input method and store it in the database, put the process method into the context, and determine the execution direction of the process method; Execute the flow method and catch exceptions; The execution direction of the process method includes: forward sub-methods and reverse sub-methods. Depending on the different exceptions encountered during the execution of the process method, the process is reversed.

3. The method as described in claim 2, characterized in that, The process involves adding a distributed lock, pushing the input parameter method onto the stack, generating a process record based on the input parameter method and storing it in the database, placing the process method into the context, and determining the execution direction of the process method. Execute the flow method and catch exceptions, including: If the execution direction of the process method is a forward sub-method, then the business method annotated with ProcessStart is called. If an unknown exception is caught, then ProcessReverseException is thrown, and the entire process is rolled back. If the execution direction of the process method is a reverse sub-method, then query the successfully executed node, generate the corresponding backflush node and execute it, catch any thrown exceptions, and perform state changes based on the exceptions. If the exception is unknown, then throw a ProcessUnknownException and continue to retry.

4. The method as described in claim 3, characterized in that, The node method executor includes the following steps: Get the latest process record parameters in the stack in the context, query the node record in the database based on the process record parameters, and if the node record does not exist, generate the node record and add it to the database. Based on the state of the node record, determine whether to skip or execute the business method marked with ProcessStep; If a business method annotated with ProcessStep is executed, an exception will be caught. If the exception is unknown, check if there is an exception class corresponding to skip in the configuration of ProcessStep; if there is an exception class corresponding to skip in the configuration of ProcessStep, the current step is executed successfully. If the configuration in ProcessStep does not contain an exception class corresponding to skip, a ProcessUnknownException will be thrown, and execution will be retried.

5. The method as described in claim 4, characterized in that, The retry actuator includes the following steps: Based on the pre-configured retry days, the sharded query status is a process record in progress; Iterate through the process records and obtain the process Method object using reflection based on the method name and parameter list; Retrieve the bean instance of the class corresponding to the method based on the Spring context; Setting the invokeRetry parameter in ThreadLocal to false enables the execution of the bean instance's Method via reflection, thus restarting the process.

6. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the lightweight distributed process transaction control method according to any one of claims 1 to 5.

7. An electronic device, characterized in that, Including processor and memory; The memory is used to store the process start executor, the node method executor, and the retry executor; The processor is configured to execute the lightweight distributed process transaction control method according to any one of claims 1 to 5 by invoking the process start executor, the node method executor, and the retry executor.

8. A computer program product, comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by a processor, they implement the steps of the lightweight distributed process transaction control method according to any one of claims 1 to 5.

Images