Fine-grained transaction control method, system and device, electronic equipment and storage medium

Abstract

The invention discloses a fine-grained transaction control method, system and device, electronic equipment and a storage medium, and belongs to the field of computer software, and the method comprises the steps that a transaction control request is received through a static calling interface; the transaction control request is routed to a corresponding transaction template method, the transaction template method is bound with preset transaction attributes through declarative configuration, and logic of a method body of the transaction template method is fixed to execute a functional interface object transmitted through parameters; and calling the transaction template method to enable the business logic code block to be executed in a transaction context defined by the transaction attribute. According to the method, a developer can independently and flexibly start transactions with specific attributes according to different logic fragments in the same method, and the defects that in the prior art, codes are redundant, the invasiveness is high, and APIs are not visual and unified enough are overcome.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a fine-grained transaction control method, system, device, electronic device, and storage medium. Background Technology

[0002] In modern Java enterprise application development based on the Spring framework, transaction management is a core mechanism for ensuring the atomicity, consistency, isolation, and durability (ACID) of database operations, and is crucial for guaranteeing the integrity and consistency of business data. The Spring framework provides developers with powerful and abstract transaction control capabilities through its two pillars: declarative transaction management and programmatic transaction management. However, both of these mainstream solutions have inherent limitations in achieving fine-grained and flexible transaction control.

[0003] Declarative transaction management allows developers to add the `@Transactional` annotation to Spring-managed beans (usually Service layer classes or methods) and configure propagation behavior, isolation level, and other properties. The Spring framework then automatically manages the transaction lifecycle at runtime through Aspect-Oriented Programming (AOP). However, the `@Transactional` annotation only applies to the entire method level. If a specific code segment (such as a few lines of critical code) within a method needs to be started independently with a specific propagation behavior, developers are typically forced to split this code into a separate new method and add the annotation, which severely disrupts the natural structure, logical cohesion, and readability of the code. Programmatic transaction management, on the other hand, is designed for scenarios requiring finer control over transaction boundaries. Developers explicitly use a `TransactionTemplate` instance programmatically, writing transaction logic in its `execute` method. This approach requires explicit dependency injection of the `TransactionTemplate` instance and writing template code for the `execute` method every time it's used, resulting in cumbersome syntax and strong code intrusion.

[0004] Therefore, there is an urgent need in this field for a new transaction control scheme that can balance the simplicity of declarative transactions with the flexibility of programmatic transactions, and achieve fine-grained control at the code block level. Summary of the Invention

[0005] This application provides a fine-grained transaction control method, system, device, electronic device, and storage medium. It constructs a fine-grained transaction control architecture based on functional interfaces and static utility classes, which solves the contradiction between control granularity and flexibility in existing Spring transaction management solutions. It achieves the technical effect of dynamically and flexibly controlling transaction boundaries and propagation behavior at the code block level with a concise, almost declarative syntax.

[0006] On the one hand, embodiments of this application provide a fine-grained transaction control method, including:

[0007] Transaction control requests are received via static API calls, wherein the requests include business logic code blocks and transaction attribute parameters.

[0008] The transaction control request is routed to the corresponding transaction template method, wherein the transaction template method is bound to a pre-defined transaction attribute through declarative configuration, and the logic of its method body is fixed to execute the functional interface object passed in as a parameter;

[0009] Invoking the transaction template method causes the business logic code block to execute within the transaction context defined by the transaction attribute.

[0010] In one possible embodiment, the step of receiving the transaction control request via a statically invoked interface includes:

[0011] Receive a call request and input parameters from the developer. The call request includes a static utility class to be called, and the input parameters include the business logic code block and the transaction attribute parameters.

[0012] The business logic code block is encapsulated into a functional interface object;

[0013] The transaction execution request is generated based on the functional interface object and the transaction attribute parameters;

[0014] Obtain the static invocation method based on the static utility class, and receive the transaction control request through the static invocation interface.

[0015] In one possible embodiment, the step of routing the transaction control request to the corresponding transaction template method includes:

[0016] Based on the propagation behavior parameters in the transaction control request and the preset routing logic, determine the transaction template method as the target of the call;

[0017] The business logic code block is passed as a parameter to the transaction template method.

[0018] In one possible embodiment, the step of routing the transaction control request to the corresponding transaction template method further includes:

[0019] By pre-constructing a mapping table between transaction control requests and transaction template methods, the transaction execution request is routed to the corresponding transaction template method; or,

[0020] By pre-setting a set of conditional judgment statements, the transaction control request is used as the judgment condition to call the corresponding transaction template method.

[0021] In one possible embodiment, the step of invoking the transaction template method to cause the business logic code block to execute within the transaction context defined by the transaction attribute includes:

[0022] The transaction attributes are parsed from the transaction template method;

[0023] The transaction manager that executes the current transaction is determined based on the transaction attributes, and its current thread transaction status is judged. Based on the judgment result, the corresponding transaction context is created or added.

[0024] In one possible embodiment, the step of determining the transaction manager executing the current transaction based on the transaction attributes, judging its current thread transaction state, and creating or joining the corresponding transaction context based on the judgment result includes:

[0025] When the transaction attribute contains a new transaction, it is determined whether there is an active transaction in the current thread of the transaction manager. If there is, the current active transaction is suspended and a new transaction context is created; otherwise, a new transaction context is created directly.

[0026] If the transaction attribute does not contain a new transaction, then it is determined whether there is an active transaction in the current thread of the transaction manager. If there is, the current active transaction is joined; otherwise, a new transaction context is created.

[0027] On one hand, embodiments of this application provide a fine-grained transaction control system, including:

[0028] The receiving module is used to receive transaction control requests through a static API call, wherein the request includes a business logic code block and transaction attribute parameters.

[0029] The routing module is used to route the transaction control request to the corresponding transaction template method, wherein the transaction template method is bound to a pre-defined transaction attribute through declarative configuration, and the logic of its method body is fixed to execute the functional interface object passed in through parameters.

[0030] The calling module is used to invoke the transaction template method, so that the business logic code block is executed in the transaction context defined by the transaction attribute.

[0031] On one hand, embodiments of this application provide a fine-grained transaction control device, including:

[0032] The static utility class layer is configured to provide a global static call interface for receiving business logic code blocks and transaction attribute parameters encapsulated in functional interface objects;

[0033] The routing adaptation layer, which communicates with the static utility class layer, is configured to receive the business logic code block and transaction attribute parameters, and route the execution request to the corresponding transaction template method according to the transaction attribute parameters.

[0034] The proxy execution layer, which is communicatively connected to the routing adaptation layer, includes one or more of the transaction template methods; wherein each of the transaction template methods is bound to specific transaction attributes through declarative configuration, and its method body is configured to execute the passed-in functional interface object;

[0035] The static utility class layer, the routing adaptation layer, and the proxy execution layer work together to enable the business logic code block to be executed in a transaction context defined by the bound transaction attributes.

[0036] On one hand, embodiments of this application provide an electronic device, which includes a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor executes any of the fine-grained transaction control methods described above.

[0037] On the one hand, this application provides a computer-readable storage medium including program code, which, when the storage medium is running on an electronic device, causes the electronic device to execute any of the fine-grained transaction control methods described above.

[0038] On one hand, an embodiment of this application provides a computer program product, which includes computer instructions stored in a computer-readable storage medium; when the processor of an electronic device reads the computer instructions from the computer-readable storage medium, the processor executes the computer instructions, causing the electronic device to perform any of the above-described fine-grained transaction control methods.

[0039] The beneficial effects of this application are as follows:

[0040] This application provides a fine-grained transaction control method, system, device, electronic device, and storage medium. It constructs a three-layer architecture consisting of a static utility class layer, a routing adaptation layer, and a proxy execution layer. The static utility class provides a global entry point to receive business logic code blocks encapsulated in functional interfaces and optional transaction attribute parameters. The routing adaptation layer dynamically routes execution requests to the corresponding transaction template method in the proxy execution layer based on the transaction attribute parameters. Finally, by calling the transaction template method, the transaction manager of the dependency injection framework creates or adds a transaction context based on its declaratively configured transaction attributes, and executes the business logic code block within that context. The technical effect of this invention is that it successfully resolves the contradiction between the coarse granularity of declarative transaction control and the strong invasiveness of programmatic transaction code. It achieves dynamic and flexible control of transaction boundaries and propagation behavior at the code block level using concise declarative syntax, significantly improving the accuracy, maintainability, and development efficiency of transaction management in complex business scenarios.

[0041] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

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

[0043] Figure 1 This is a flowchart illustrating the implementation of a fine-grained transaction control method in an embodiment of this application.

[0044] Figure 2 This is a schematic diagram of the structure of a fine-grained transaction control system according to an embodiment of this application;

[0045] Figure 3 This is a schematic diagram of the architecture of a fine-grained transaction control device in an embodiment of this application;

[0046] Figure 4 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0048] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0049] Existing Spring transaction management solutions inherently contradict each other in terms of control granularity and flexibility. Spring's native declarative transactions (@Transactional annotation), while concise, are coarse-grained, unable to independently initiate transactions within specific code blocks within methods, and nested transaction configuration is inconvenient. On the other hand, programmatic transactions (TransactionTemplate), while offering fine-grained control, suffer from redundant syntax, strong intrusiveness, a lack of unified and intuitive APIs, and cumbersome dynamic switching of transaction behavior. Therefore, this application provides a fine-grained transaction control solution to overcome the respective shortcomings of the two mainstream approaches. It achieves fine-grained and flexible transaction control at the code block level (rather than the method level), while possessing near-declarative concise syntax and the dynamic control capabilities of programmatic transactions. This significantly improves the accuracy, maintainability, and development efficiency of transaction management in complex business scenarios while preserving the natural structure of the code.

[0050] The core idea of ​​this application lies in allowing developers to submit business code blocks requiring transaction management and optional transaction attributes through a global static entry point, in the form of a functional object interface. This request is automatically routed to a transaction template method with pre-defined transaction attributes. By calling this method, the Spring framework is triggered to dynamically create or add a specific transaction context for the code block at runtime, and execute it within this context, ultimately automatically committing or rolling back the transaction. Through process-oriented assembly, Spring's declarative transaction automation management capabilities are precisely applied to any code fragment, thereby achieving fine-grained control at the code block level through process innovation. Based on the above method, this invention constructs a three-layer architecture including a static utility class layer, a routing adaptation layer, and a proxy execution layer, unitizing and interfaceizing Spring's declarative transaction management capabilities, thereby achieving fine-grained and flexible transaction control over any code block (rather than the entire method). This architecture provides a concise global entry point through a top-level static utility class, receiving business code blocks encapsulated in lambda expressions and optional transaction propagation behavior parameters. The middle-level routing adapter dynamically dispatches requests to the corresponding transaction template methods at the lower level based on these parameters. The underlying transaction executor's methods are pre-bound with specific transaction attributes using the `@Transactional` annotation. When invoked, Spring AOP automatically creates or adds the corresponding transaction context, executing the business code block within it. This design combines the convenience of declarative transactions with the flexibility of programmatic transactions, ultimately resolving the contradiction between control granularity and flexibility in traditional solutions with a concise one-line syntax, achieving efficient transaction management at the code block level with dynamically specified transaction attributes.

[0051] Spring is an open-source, lightweight Java enterprise application development framework and inversion of control container. Its core value lies in simplifying the development, configuration, integration, and deployment of complex enterprise Java applications through the two concepts of inversion of control and aspect-oriented programming, and providing a standardized solution for common enterprise needs such as transaction management.

[0052] Lambda expressions refer to the way developers wrap business code blocks (a piece of logic) that need to be managed by transactions into a concise object that can be passed as a parameter. Lambda expressions are automatically converted into a functional object interface by the compiler. By objectifying the code block, the flexibility of transaction boundary definition and the conciseness of business logic transmission are achieved. Lambda expressions are the core carrier and key technical means to achieve fine-grained transaction control.

[0053] like Figure 1 The diagram shown is an implementation flowchart of a fine-grained transaction control method provided in this application embodiment. The specific implementation process of this method is as follows:

[0054] S101, receive transaction control requests through static call interface, wherein the requests include business logic code blocks and transaction attribute parameters.

[0055] In the Spring-based transaction management system, the static call interface is implemented through a static utility class, named `TransactionUtils` in this embodiment. This class itself is not managed by the Spring framework; that is, it is not annotated with `@Component` or similar annotations, and it does not contain member variables requiring dependency injection. The purpose of this class is to provide a global, concise entry point for transaction control that can be accessed directly without instantiation or dependency injection. Therefore, all methods defined in this class are modified with the `public static` keyword. The transaction control request is triggered by calling the static method `execute` of the `TransactionUtils` class. This method employs an overload design to flexibly accept different parameter combinations. When the static class method is called, the transaction control request is received. The call request sent by the developer contains two core components: a business logic code block and transaction attribute parameters. The business logic code block is passed as a task parameter, and the transaction attribute parameter is passed as a `propagation` parameter, using the `Propagation` enumeration type defined by the Spring framework, to specify the transaction propagation behavior. This parameter is optional; when calling a method overload that does not specify this parameter, `Propagation.REQUIRED` is used by default. Inside the static `execute` method, the received request needs to be forwarded to the business component managed by Spring for further processing. Since `TransactionUtils` is a static class, it's impossible to directly obtain the bean via dependency injection. Therefore, a service locator pattern is needed to bridge the Spring container. Specifically, first, a bean instance named `TransactionSupport` is obtained from the Spring application context using the static method `getBean(TransactionSupport.class)` of a utility class (such as `SpringContextUtil`). Then, the `execute` method of this `TransactionSupport` instance is called, passing the received task and propagation parameters to it, thus completing the transfer of transaction control requests from the static interface to the dynamic Spring component.

[0056] S102, the transaction control request is routed to the corresponding transaction template method, wherein the transaction template method is bound to a pre-defined transaction attribute through declarative configuration, and the logic of its method body is fixed to execute the functional interface object passed in through parameters.

[0057] In practical applications, a Spring Bean can be pre-configured to host routing functionality. This class, named `TransactionSupport`, acts as a transaction support component, annotated with `@Component` or `@Service`, and is managed uniformly by the Spring container. It holds an instance of the transaction execution proxy component (`TransactionExecutor`) through dependency injection (e.g., using the `@Autowired` annotation). The `TransactionSupport` component (i.e., the transaction support component) internally contains routing decision logic. When its `execute` method is called and receives transaction attribute parameters (e.g., `Propagation.REQUIRES_NEW`), this logic is triggered. It determines the name of the target method (e.g., `execWithRequiresNew`) through conditional judgments (e.g., `switch-case`) or a strategy mapping table (e.g., a predefined Map). After the routing decision is completed, the `TransactionSupport` component (the transaction support component) then calls the corresponding target method (i.e., the transaction template method) in its held `TransactionExecutor` instance, passing the business logic code block (a functional interface object) as a parameter. The transaction template method is a public method defined in the `TransactionExecutor` class. Its core feature is that it declares specific transaction attributes through the @Transactional annotation, and the method body logic is fixed to execute the passed-in functional interface object.

[0058] S103, Invoke the transaction template method to make the business logic code block execute in the transaction context defined by the transaction attribute.

[0059] When a transaction template method (such as `transactionExecutor.execWithRequiresNew(task)`) is called through a transaction support component (`TransactionSupport`), the actual call does not directly act on the native method of the transaction execution proxy component (`TransactionExecutor`) object. Since an instance of `TransactionExecutor` is a bean managed by the Spring container, and its methods are annotated with `@Transactional`, the Spring framework creates an AOP proxy object for it at runtime. The call to the transaction template method is first intercepted by this AOP proxy object. After receiving the method call, the proxy object's embedded transaction interceptor (such as `TransactionInterceptor`) performs transaction attribute parsing and transaction lifecycle management in sequence. Specifically, first, the transaction interceptor parses the complete transaction definition (`TransactionDefinition`) from the `@Transactional` annotation of the called target method (i.e., the transaction template method), including propagation behavior, isolation level, etc.; then, the transaction interceptor passes the transaction definition to the underlying transaction manager (`PlatformTransactionManager`). The transaction manager performs specific operations based on propagation behavior attributes (such as Propagation.REQUIRES_NEW) and the current thread's transaction state: if an active transaction exists, it is suspended and a new transaction is created; otherwise, a new transaction is created directly. The newly created or existing transaction context is bound to the currently executing thread.

[0060] This embodiment receives requests through a static API call, refining the granularity of transaction control from the method level of traditional Spring declarative transactions to the code block level. Specifically, it encapsulates business logic code blocks into functional interface objects and passes them as parameters. This allows developers to independently and flexibly start transactions with specific attributes (such as different propagation behaviors) for different logical fragments within the same method. This solves the drawbacks of existing technologies where the coarse granularity of the @Transactional annotation necessitates method splitting and disrupts the natural code structure. At the same time, it parameterizes transaction attributes, supporting dynamic specification at the time of invocation, thus preserving the flexibility and control of programmatic transactions. It overcomes the shortcomings of existing technologies such as code redundancy, strong intrusion, and unintuitive and inconsistent APIs of TransactionTemplate.

[0061] In some implementations, step S101, the step of receiving a transaction control request through a static call interface, includes:

[0062] Receive a call request and input parameters from the developer. The call request includes a static utility class to be called, and the input parameters include the business logic code block and the transaction attribute parameters.

[0063] The business logic code block is encapsulated into a functional interface object;

[0064] The transaction execution request is generated based on the functional interface object and the transaction attribute parameters;

[0065] Obtain the static invocation method based on the static utility class, and receive the transaction control request through the static invocation interface.

[0066] In practical applications, developers initiate calls by writing code statements within their business logic. These calls are manifested as references to specific static utility classes (typically named `TransactionUtils`). The input parameters are directly represented as the actual arguments of the method call at the code level. The business logic code block is a section of code written directly into the method parameter location in the form of a lambda expression; the transaction attribute parameter is an optional enumeration parameter of type `Propagation`, used to specify the propagation behavior. When developers write the lambda expression, the compiler will determine the type of the target parameter (e.g., `Runnable` or `Callable`). <t>The system automatically converts the object into an instance of the functional interface. When a static method (such as `execute`) of the static utility class (`TransactionUtils`) is called, the encapsulated functional interface object and transaction attribute parameters are treated together as a complete, pending "transaction execution request" within the static method. This request is then processed as a whole by subsequent logic within the method. By locating the specific static method through the static utility class (`TransactionUtils`), when the program execution flow enters this static method, it signifies that the transaction control request has been formally received through the static call interface.

[0067] This embodiment constructs a unified, type-safe transaction control entry point that is decoupled from specific business logic. It provides a structured input for subsequent fine-grained transaction processing, provides developers with a clear and standardized API usage paradigm, and establishes a preprocessing flow for transaction control requests, thereby reducing the complexity and uncertainty of the fine-grained transaction control process.

[0068] In some implementations, step S102, the step of routing the transaction control request to the corresponding transaction template method, includes:

[0069] Based on the propagation behavior parameters in the transaction control request and the preset routing logic, determine the transaction template method as the target of the call;

[0070] The business logic code block is passed as a parameter to the transaction template method.

[0071] In this embodiment, the propagation behavior parameter refers to the propagation intent of the transaction. The preset routing logic is a set of routing decision logic pre-set within the transaction support component (TransactionSupport). When the routing logic is executed, it takes the passed-in parameter as input and outputs a definite target method identifier by querying or matching the above-mentioned preset logic. For example, when the parameter is Propagation.REQUIRES_NEW, the routing logic will determine that the target method is execWithRequiresNew. After determining the target transaction template method, the transaction support component immediately initiates a call, which points to the corresponding method of the transaction execution component (TransactionExecutor) that it depends on. During the call, a functional interface object encapsulating the business logic is passed as a parameter to the target transaction template method. At this point, the business logic code block has been successfully routed to a transaction template method with specific transaction attributes, preparing for subsequent execution in a specific transaction context.

[0072] This embodiment maps the abstract transaction propagation intent to specific transaction template methods, enabling dynamic and flexible binding of transaction behaviors and business code blocks, and providing configurable intelligent scheduling capabilities for the core transaction control logic.

[0073] In some implementations, step S102, the step of routing the transaction control request to the corresponding transaction template method, further includes:

[0074] By pre-constructing a mapping table between transaction control requests and transaction template methods, the transaction execution request is routed to the corresponding transaction template method; or,

[0075] By pre-setting a set of conditional judgment statements, the transaction control request is used as the judgment condition to call the corresponding transaction template method.

[0076] This embodiment provides two preferred implementation methods for routing decision logic. One is a policy mapping table, for example, pre-constructing a Map.<Propagation, Method> One type is a mapping table that uses enumeration values ​​as keys and references to their corresponding transaction template methods as values; another type is a conditional structure, such as using a switch-case statement, where different Propagation enumeration values ​​(such as REQUIRES_NEW, REQUIRED, NESTED) are used as conditions for the case branches.

[0077] In some implementations, step S103 specifically includes the following steps:

[0078] The transaction attributes are parsed from the transaction template method;

[0079] The transaction manager that executes the current transaction is determined based on the transaction attributes, and its current thread transaction status is judged. Based on the judgment result, the corresponding transaction context is created or added.

[0080] Because the transaction template method is annotated with Spring's `@Transactional`, Spring's AOP proxy interception mechanism intervenes first when the corresponding transaction template method is invoked. Specifically, the transaction interceptor in Spring's AOP extracts all configured transaction attributes from the `@Transactional` annotation of the invoked transaction template method, including but not limited to propagation, isolation level, and timeout. These attributes are encapsulated into a transaction definition object (`TransactionDefinition`), which serves as the sole basis for subsequent transaction operations. After obtaining the transaction definition, the transaction interceptor uses Spring's context configuration (such as a data source) or the transaction manager lookup strategy to determine the platform transaction manager instance that will handle the transaction. This platform transaction manager ultimately becomes the underlying component that actually executes transaction operations (such as start, commit, and rollback).

[0081] In a preferred embodiment, the step of determining the transaction manager executing the current transaction based on the transaction attributes, judging its current thread transaction state, and creating or joining the corresponding transaction context based on the judgment result includes:

[0082] When the transaction attribute contains a new transaction, it is determined whether there is an active transaction in the current thread of the transaction manager. If there is, the current active transaction is suspended and a new transaction context is created; otherwise, a new transaction context is created directly.

[0083] If the transaction attribute does not contain a new transaction, then it is determined whether there is an active transaction in the current thread of the transaction manager. If there is, the current active transaction is joined; otherwise, a new transaction context is created.

[0084] Before processing a transaction request, the transaction manager checks whether the execution thread is already bound to an active transaction context. This check is a crucial factual basis for determining subsequent operations. If the propagation behavior attribute indicates a new transaction is required (e.g., `Propagation.REQUIRES_NEW`): regardless of whether an active transaction exists, the transaction manager creates a completely new and independent transaction context. If an active transaction exists, it is suspended until the new transaction completes. If the propagation behavior attribute indicates support for the current transaction (e.g., `Propagation.REQUIRED`) and an active transaction exists: the transaction manager does not create a new transaction but adds subsequent operations to the existing active transaction context. In practical applications, other situations may arise: depending on the different propagation behavior semantics (e.g., `NESTED`, `MANDATORY`, `NEVER`, etc.), the transaction manager executes corresponding logic, such as throwing exceptions or creating nested transactions.

[0085] After the business logic code block completes execution, its result, whether successful or exception-based, will be used as input to trigger the Spring transaction manager's automatic handling of normal execution and transaction commit, and exception execution and transaction rollback. Specifically,

[0086] The normal execution and transaction commit process includes: when the code block completes execution normally without throwing any exceptions, the Spring AOP transaction interceptor automatically calls the transaction manager to commit the currently active transaction. This operation makes all changes to the database in the code block permanent, ensuring data persistence.

[0087] The process of exception execution and transaction rollback includes: when an exception is thrown during the execution of a code block, the transaction interceptor automatically calls the transaction manager to roll back the currently active transaction. This operation undoes all database changes made within the transaction context, restoring the database to its state before the transaction began, strictly guaranteeing data consistency.

[0088] This embodiment constructs a fine-grained, full-lifecycle transaction control process—from static utility class entry reception to route adaptation and distribution to proxy execution—combining functional interfaces with Spring's declarative transaction management mechanism. It successfully reshapes Spring's transaction management capabilities to be fine-grained, dynamic, and concise, fundamentally resolving the inherent contradiction between the coarse-grained and inflexible control of traditional @Transactional annotations and the redundancy and intrusiveness of TransactionTemplate programmatic transaction code. This application allows developers to dynamically specify transaction attributes and initiate transactions at any code block level (not the entire method) with an extremely concise one-line syntax, making transaction boundary control more flexible and precise. Simultaneously, through a unified API design, it seamlessly integrates scenarios with and without return values, significantly improving development efficiency, code readability, maintainability, and controllability in complex transaction scenarios. It provides a new paradigm for transaction control that combines declarative conciseness with programmatic flexibility for enterprise application development based on the Spring framework.

[0089] Based on the same inventive concept, embodiments of this application also provide a fine-grained transaction control system. For example... Figure 2 As shown, this is a schematic diagram of the structure of a fine-grained transaction control system 200, which may include:

[0090] The receiving module 201 is used to receive a transaction control request through a static call interface, wherein the request includes a business logic code block and transaction attribute parameters;

[0091] The routing module 202 is used to route the transaction control request to the corresponding transaction template method, wherein the transaction template method is bound to a pre-defined transaction attribute through declarative configuration, and the logic of its method body is fixed to execute the functional interface object passed through the parameter;

[0092] Module 203 is invoked to invoke the transaction template method, so that the business logic code block is executed in the transaction context defined by the transaction attribute.

[0093] Based on the same inventive concept, embodiments of this application also provide a fine-grained transaction control device, such as... Figure 3 As shown, this is a schematic diagram of the architecture of the fine-grained transaction control device 300, including:

[0094] The static utility class layer 301 is configured to provide a global static call interface for receiving business logic code blocks and transaction attribute parameters encapsulated in functional interface objects;

[0095] The routing adaptation layer 302, which is communicatively connected to the static utility class layer 301, is configured to receive the business logic code block and transaction attribute parameters, and route the execution request to the corresponding transaction template method according to the transaction attribute parameters.

[0096] The proxy execution layer 303 is communicatively connected to the routing adaptation layer 302 and includes one or more of the transaction template methods; wherein each of the transaction template methods is bound to specific transaction attributes through declarative configuration, and its method body is configured to execute the passed-in functional interface object;

[0097] The static utility class layer 301, the route adaptation layer 302, and the proxy execution layer 303 work together to enable the business logic code block to be executed in a transaction context defined by the bound transaction attributes.

[0098] See attached document Figure 3 The schematic diagram shown illustrates the process by which the fine-grained transaction control system 200 implements the fine-grained transaction control method through the fine-grained transaction control device 300, as follows:

[0099] The static utility class layer 301 serves as the unified entry point for the entire transaction control process. Its core goal is to provide developers with an extremely concise calling method, allowing them to trigger the call flow with a single line of code within their business logic. This line of code contains two key pieces of information: a business logic code block (in the form of a lambda expression) and optional transaction attribute parameters. The Java compiler automatically encapsulates the lambda expression into a functional interface object. Since the static utility class itself is not a Spring-managed bean, it needs to dynamically obtain an instance of the transaction support component from the Spring application context through a service locator. After obtaining the instance of the transaction support component, the static utility class immediately calls its method, forwarding the encapsulated business logic code block and transaction attribute parameters. At this point, the static utility class layer 301 has fulfilled its mission, delegating the complex processing flow to the subsequent route adaptation layer 302 and proxy execution layer 303.

[0100] The routing adaptation layer 302 acts as the intelligent router for the entire process. Its core responsibility is to accurately distribute requests to the correct executor based on the caller's intent (transaction attributes). Specifically, it receives functional interface objects and transaction attribute parameters from the upper layer through the transaction support component. The routing adaptation layer 302 pre-sets a set of routing logic, typically represented by a switch-case statement or a strategy mapping table. This logic maps different transaction propagation behaviors to the corresponding specific transaction template method names in the next layer (proxy execution layer 303). After making a routing decision, the routing adaptation layer 302 calls the corresponding transaction template method of the proxy execution layer 303, which it holds internally through dependency injection, passing the business logic code block as a parameter.

[0101] The proxy execution layer 303 is the final executor of transaction management and the layer that directly interacts with the Spring transaction infrastructure. Its core principle is to utilize the proxy mechanism of Spring AOP. An instance of the proxy execution layer 303 is a Spring Bean, and its methods are annotated with `@Transactional`. Therefore, Spring creates an AOP proxy object for it at runtime. Any call to a method in the proxy execution layer 303 will first be intercepted by the transaction interceptor. The transaction interceptor parses the transaction attributes (propagation behavior, isolation level, etc.) from the `@Transactional` annotation of the called transaction template method. Then, the interceptor calls Spring's transaction manager, which, based on the parsed transaction attributes and whether an active transaction exists in the current thread, decides whether to create a new transaction or join an existing one, thus binding an active transaction context to the current thread. Once the transaction context is ready, the interceptor will allow the execution of the native method body of the corresponding transaction template method. This method body is extremely simple and fixed, namely task.run() or return task.call(). The execution of this line of code means that the business logic code block (Lambda expression) written by the developer is finally called in the active transaction context managed by Spring. At this time, all database operations within the code block will be under the management of this transaction.

[0102] After the business logic block finishes execution, control is returned to the AOP proxy. Based on the execution result (successful completion or exception thrown), the Spring framework ensures that the transaction is automatically committed or rolled back.

[0103] Based on the same inventive concept, this application also provides an electronic device that can implement the functions of the aforementioned fine-grained transaction control method system. (Refer to...) Figure 4 The electronic device includes:

[0104] At least one processor 401 and a memory 402 connected to at least one processor 401. In this embodiment, the specific connection medium between the processor 401 and the memory 402 is not limited. Figure 4 The example shown is the connection between processor 401 and memory 402 via bus 400. Bus 400 is... Figure 4 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. The 400 bus can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 4 The term is represented by a single thick line, but this does not imply that there is only one bus or one type of bus. Alternatively, processor 401 can also be called a controller; there is no restriction on the name.

[0105] In this embodiment, memory 402 stores instructions executable by at least one processor 401. By executing the instructions stored in memory 402, at least one processor 401 can execute the fine-grained transaction control method discussed above. Processor 401 can implement... Figure 3 The system shown illustrates the functions of each module.

[0106] The processor 401 is the control center of the system. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 402 and calling data stored in memory 402, the system can perform various functions and process data, thereby monitoring the system as a whole.

[0107] In one possible design, processor 401 may include one or more processing units. Processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 401. In some embodiments, processor 401 and memory 402 may be implemented on the same chip; in some embodiments, they may also be implemented separately on separate chips.

[0108] Processor 401 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the fine-grained transaction control method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0109] Memory 402, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 402 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 402 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 402 can also be a circuit or any other system capable of implementing storage functions for storing program instructions and / or data.

[0110] By designing and programming the processor 401, the code corresponding to the fine-grained transaction control method described in the foregoing embodiments can be embedded into the chip, enabling the chip to execute it during operation. Figure 2 The steps of the fine-grained transaction control method in the illustrated embodiment are described below. How to design and program the processor 401 is a technique well-known to those skilled in the art and will not be elaborated upon here.

[0111] Based on the same inventive concept, embodiments of this application also provide a storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the fine-grained transaction control method described above.

[0112] In some possible implementations, various aspects of the fine-grained transaction control method provided in this application can also be implemented as a program product, which includes program code that, when the program product is run on a system, causes the control device to perform the steps in the fine-grained transaction control method according to the various exemplary embodiments of this application described above.

[0113] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application 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.

[0114] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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... Figure 1 One or more processes and / or boxes Figure 1 A system that specifies functions in one or more boxes.

[0115] 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.

[0116] 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 function specified in one or more boxes.

[0117] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.< / t>

Claims

1. A fine-grained transaction control method, characterized in that, include: Transaction control requests are received via static API calls, wherein the requests include business logic code blocks and transaction attribute parameters. The transaction control request is routed to the corresponding transaction template method, wherein the transaction template method is bound to a pre-defined transaction attribute through declarative configuration, and the logic of its method body is fixed to execute the functional interface object passed in as a parameter; Invoking the transaction template method causes the business logic code block to execute within the transaction context defined by the transaction attribute.

2. The method as described in claim 1, characterized in that, The step of receiving transaction control requests through a static API call includes: Receive a call request and input parameters from the developer. The call request includes a static utility class to be called, and the input parameters include the business logic code block and the transaction attribute parameters. The business logic code block is encapsulated into a functional interface object; The transaction execution request is generated based on the functional interface object and the transaction attribute parameters; Obtain the static invocation method based on the static utility class, and receive the transaction control request through the static invocation interface.

3. The method as described in claim 1, characterized in that, The step of routing the transaction control request to the corresponding transaction template method includes: Based on the propagation behavior parameters in the transaction control request and the preset routing logic, determine the transaction template method as the target of the call; The business logic code block is passed as a parameter to the transaction template method.

4. The method as described in claim 1, characterized in that, The step of routing the transaction control request to the corresponding transaction template method further includes: By pre-constructing a mapping table between transaction control requests and transaction template methods, the transaction execution request is routed to the corresponding transaction template method; or, By pre-setting a set of conditional judgment statements, the transaction control request is used as the judgment condition to call the corresponding transaction template method.

5. The method as described in claim 1, characterized in that, The step of invoking the transaction template method, causing the business logic code block to execute within the transaction context defined by the transaction attribute, includes: The transaction attributes are parsed from the transaction template method; The transaction manager that executes the current transaction is determined based on the transaction attributes, and its current thread transaction status is judged. Based on the judgment result, the corresponding transaction context is created or added.

6. The method as described in claim 5, characterized in that, The steps of determining the transaction manager to execute the current transaction based on the transaction attributes, judging its current thread transaction state, and creating or joining the corresponding transaction context based on the judgment result include: When the transaction attribute contains a new transaction, it is determined whether there is an active transaction in the current thread of the transaction manager. If there is, the current active transaction is suspended and a new transaction context is created; otherwise, a new transaction context is created directly. If the transaction attribute does not contain a new transaction, then it is determined whether there is an active transaction in the current thread of the transaction manager. If there is, the current active transaction is joined; otherwise, a new transaction context is created.

7. A fine-grained transaction control system, characterized in that, include: The receiving module is used to receive transaction control requests through a static API call, wherein the request includes a business logic code block and transaction attribute parameters. The routing module is used to route the transaction control request to the corresponding transaction template method, wherein the transaction template method is bound to a pre-defined transaction attribute through declarative configuration, and the logic of its method body is fixed to execute the functional interface object passed in through parameters. The calling module is used to invoke the transaction template method, so that the business logic code block is executed in the transaction context defined by the transaction attribute.

8. A fine-grained transaction control device, characterized in that, include: The static utility class layer is configured to provide a global static call interface for receiving business logic code blocks and transaction attribute parameters encapsulated in functional interface objects; The routing adaptation layer, which communicates with the static utility class layer, is configured to receive the business logic code block and transaction attribute parameters, and route the execution request to the corresponding transaction template method according to the transaction attribute parameters. The proxy execution layer, which is communicatively connected to the routing adaptation layer, includes one or more of the transaction template methods; wherein each of the transaction template methods is bound to specific transaction attributes through declarative configuration, and its method body is configured to execute the passed-in functional interface object; The static utility class layer, the routing adaptation layer, and the proxy execution layer work together to enable the business logic code block to be executed in a transaction context defined by the bound transaction attributes.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores program code that, when executed by the processor, causes the processor to perform the method of any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, Includes program code that, when the storage medium is run on an electronic device, causes the electronic device to perform any of the methods described in claims 1 to 6.

Images