Transaction management method, system and equipment for nested execution of delivery rules and medium

Abstract

The invention relates to a transaction management method, system and device for nested execution of a delivery rule and a medium, and belongs to the technical field of semiconductor production management. According to the method, a Spring transaction framework is integrated by initializing a job rule transaction manager, and a trigger sequence and transaction isolation among a plurality of job rules are managed; in response to a report completion rule request initiated by a user operation or a system event, executing the service logic in the first transaction; after the report completion rule is executed, creating a monitor and binding the monitor to the first transaction to monitor the submission event; after the first transaction is submitted, triggering a service logic for executing an ending work rule in the second isolated transaction; and finally unbinding and cleaning the monitor. Through the above steps, automatic nested execution of the delivery rule is realized, transaction isolation is ensured, the development process is simplified, and the reliability and maintainability of the system are improved.

Description

Technical Field

[0001] This invention belongs to the field of semiconductor manufacturing technology, and in particular relates to a transaction management method, system, device and medium for nested execution of dispatch rules. Background Technology

[0002] In the MES+ (Manufacturing Execution System+) of the semiconductor manufacturing industry, the dispatching process involves the nested execution of multiple work rules (such as Pre (preparation work), Reserve (reserving machines), TrackIn (machine reporting start of work), TrackOut (machine reporting completion of work), and Post (closing work)). These rules typically need to be triggered in a specific order, and transactions within each rule must remain isolated to ensure data consistency. The dispatching process refers to the complete automated business sequence that a production batch (such as a specific batch of wafers) must follow to complete processing at a specific process station. The basic logical unit constituting the dispatching process is called a dispatching rule. Each dispatching rule represents a specific strategy or instruction formulated to achieve the phased goals of the process; it is a node in the process, clearly defining the business objectives that need to be achieved at a specific point in time. The specific execution of each dispatching rule is manifested as a series of specific work rules.

[0003] In existing technologies, transaction management is typically implemented through hard-coding in the business code. This means developers must manually handle the transaction commit and rollback logic for each job rule; for example, after executing a TrackOut rule, a Post rule needs to be explicitly called and its transaction boundaries managed. This approach leads to high coupling of business code, requiring developers to re-examine the transaction segmentation method with each process iteration or rule change, increasing development complexity and maintenance costs. Furthermore, due to the complex dependencies between transactions, improper transaction management can easily lead to data inconsistencies or system errors, affecting the reliability and efficiency of the dispatch process. Therefore, the main technical problem with existing technologies is that the complexity of transaction management when multiple job rules are nested in the semiconductor dispatch process leads to low development efficiency, requiring developers to frequently focus on transaction segmentation details and thus unable to concentrate on business logic development.

[0004] This invention aims to solve this problem by introducing a job rule transaction manager. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a transaction management method, system, device and medium for nested execution of dispatch rules, which effectively solves the problem of low R&D efficiency caused by the complexity of transaction management in the semiconductor dispatch process in the prior art.

[0006] The first aspect of this invention discloses a transaction management method for nested execution of dispatch rules, comprising the following steps: Step S101: Initialize the job rule transaction manager, wherein the job rule transaction manager integrates the Spring transaction framework to manage the triggering order among multiple job rules and ensure transaction isolation of each job rule; Step S102: In response to a report completion rule request initiated by a user operation or system event, execute the business logic of the report completion rule in the first transaction, wherein the report completion rule is a type of job rule, and the request includes a batch number and a unique process site code; Step S103: After the reporting completion rule is executed, a listener is created through the job rule transaction manager and the listener is bound to the first transaction, wherein the listener is used to listen for the commit event of the first transaction; Step S104: After the first transaction is committed, the job rule transaction manager detects the commit event through the listener and triggers the business logic of executing the cleanup work rule in the second transaction, wherein the cleanup work rule is a type of job rule, and the second transaction is isolated from the first transaction; Step S105: After the closing work rule is executed, the listener is unbound and cleaned up through the job rule transaction manager.

[0007] The above method, wherein initializing the job rule transaction manager in step S101 includes: By integrating the Spring transaction framework into the job rule transaction manager through dependency injection, the job rule transaction manager can utilize the transaction listening function of the Spring transaction framework.

[0008] In the above method, creating a listener in step S103 includes: The listener is created through the interface provided by the job rule transaction manager, and the listener name is constructed according to preset rules. The preset rules include a combination of a fixed prefix, the batch number, the unique code of the process site, and the name of the closing work rule to ensure that the listener name is globally unique.

[0009] In the above method, step S103, binding the listener to the first transaction, includes: The listener is bound to the first transaction through the job rule transaction manager, and multiple listeners can be bound to the same transaction in a specific order, wherein the specific order is determined based on business rules.

[0010] In the above method, triggering the listener in step S104 includes: After the first transaction is committed, the job rule transaction manager detects the commit event through the callback mechanism of the Spring transaction framework and triggers the listener bound to the first transaction; Once triggered, the listener's execution logic runs in a second transaction, which is isolated from the first transaction through a transaction isolation mechanism.

[0011] The business logic for executing the cleanup rules in the second transaction, as described above, includes: If the business logic of the closing work rule executes normally, then the second transaction is committed; If the business logic of the closing work rule fails to execute, the second transaction will be rolled back, and the rollback will not affect the first transaction that has already been committed.

[0012] In the above method, step S105, unbinding and cleaning up the listener, includes: The job rule transaction manager removes the association between the listener and the first transaction and releases the system resources occupied by the listener.

[0013] A second aspect of this invention discloses a transaction management system with nested execution of dispatch rules, comprising: The job rule transaction manager integrates the Spring transaction framework to manage the triggering order of multiple job rules and ensure transaction isolation between each job rule. An initialization module is used to initialize the job rule transaction manager; The request processing module is used to respond to a report completion rule request initiated by a user operation or system event, and execute the business logic of the report completion rule in the first transaction, wherein the report completion rule is a type of job rule, and the request includes a batch number and a unique process station code. The listener management module is used to create a listener through the job rule transaction manager after the reporting completion rule is executed, and bind the listener to the first transaction, wherein the listener is used to listen for the commit event of the first transaction; The event triggering module is used to detect the commit event through the job rule transaction manager after the first transaction is committed, and trigger the business logic of executing the closing work rule in the second transaction, wherein the closing work rule is a type of job rule, and the second transaction is isolated from the first transaction; The cleanup module is used to unbind and clean up the listener through the job rule transaction manager after the completion of the closing work rule.

[0014] A third aspect of the present invention discloses an electronic device, comprising: a memory and a processor, wherein the processor and the memory are connected; The memory is used to store programs; The processor invokes a program stored in the memory to execute the method provided by the first aspect embodiment and / or any possible embodiment in combination with the first aspect embodiment.

[0015] The fourth aspect of the present invention discloses a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a computer to perform the methods provided by the embodiments of the first aspect and / or any possible embodiments in combination with the embodiments of the first aspect.

[0016] Compared with existing technologies, this invention has the following advantages: By initializing a job rule transaction manager integrated with the Spring transaction framework, unified management of the triggering order and transaction isolation among multiple job rules is achieved, avoiding the coupling problem of hard-coding transaction logic in business code, and eliminating the need for developers to manually handle transaction splitting details. When a user initiates a request to report a completed rule, after executing its business logic in the first transaction, the transaction manager automatically creates and binds a listener, ensuring that a second isolated transaction is triggered to execute the closing work rule after the transaction is committed. This nested execution mechanism guarantees the independence of each rule transaction, and even if subsequent rule execution fails, it will not affect committed transactions, thereby improving the reliability and maintainability of the system. Finally, by unbinding and cleaning up listeners, dynamic resource management is achieved, further reducing maintenance costs. Overall, this invention allows developers to focus on the business logic development of individual job rules, significantly improving the development efficiency and sustainability of the dispatching process.

[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0018] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention.

[0019] Figure 2 This is a system module diagram of Embodiment 2 of the present invention. Detailed Implementation

[0020] Example 1 like Figure 1 As shown, a transaction management method for nested execution of dispatch rules includes the following steps: Step S101: Initialize the job rule transaction manager, wherein the job rule transaction manager integrates the Spring transaction framework to manage the triggering order among multiple job rules and ensure transaction isolation of each job rule; Step S102: In response to a report completion rule request initiated by a user operation or system event, execute the business logic of the report completion rule in the first transaction, wherein the report completion rule is a type of job rule, and the request includes a batch number and a unique process station code; Step S103: After the reporting completion rule is executed, a listener is created through the job rule transaction manager and the listener is bound to the first transaction, wherein the listener is used to listen for the commit event of the first transaction; Step S104: After the first transaction is committed, the job rule transaction manager detects the commit event through the listener and triggers the business logic of executing the cleanup work rule in the second transaction, wherein the cleanup work rule is a type of job rule, and the second transaction is isolated from the first transaction; Step S105: After the closing work rule is executed, the listener is unbound and cleaned up through the job rule transaction manager.

[0021] During implementation, in the initialization step of the job rule transaction manager, when the semiconductor production system starts, the system integrates the Spring transaction framework into the job rule transaction manager through dependency injection. Specifically, in the Java application, Spring's configuration class is used to inject an instance of Spring's transaction manager into the custom job rule transaction manager class using annotations such as @Autowired. This allows the job rule transaction manager to directly call the Spring transaction framework's API to manage the transaction lifecycle. For example, during system startup, the job rule transaction manager is initialized and loaded into memory, ready to handle subsequent rule execution requests. By initializing the job rule transaction manager, a unified transaction management foundation is achieved, enabling automated handling of triggering between job rules. Developers do not need to concern themselves with the underlying transaction details; they can focus solely on business logic development. The job rules include various types such as preparation rules, machine reservation rules, reporting start rules, reporting completion rules, and closing rules, and these job rules are executed nested in a preset order.

[0022] When a user initiates a request to report a completion rule, the system receives the request, which includes the batch number BATCH001 and the unique process site code SITE001. The server first initiates the first transaction, within which the business logic for the report completion rule is executed. For example, if a user interface triggers a report completion rule, the system checks the wafer status, updates the work-in-process tracking information in the database, and records the job completion time. The entire execution process is completed within the first transaction, ensuring the atomicity of data operations. By responding to requests and executing report completion rules, immediate response to rule execution is achieved, and transaction isolation ensures that the current operation does not affect other processes.

[0023] After the reported completion rule execution, the system creates a listener through the job rule transaction manager. A listener is a callback object used to listen for the commit event of the first transaction. The job rule transaction manager provides a creation interface to generate a listener name based on preset rules. For example, it combines the fixed prefix LISTENER, batch number BATCH001, process site unique code SITE001, and rule name "Finalizing Work Rule" to form the globally unique name LISTENER_BATCH001_SITE001 Finalizing Work Rule. This avoids naming conflicts between multiple listeners. By creating listeners, the uniqueness and traceability of the listeners are ensured, providing a reliable foundation for subsequent triggering.

[0024] After a listener is created, the job rule transaction manager binds it to the first transaction. The binding process is achieved by calling the transaction manager's binding method, adding the listener to the current transaction's listener list. For example, during the execution of a reporting completion rule transaction, the system binds only one listener, but the transaction manager supports binding multiple listeners in order of business logic. By binding listeners, the association between transactions and listeners is established, enabling subsequent operations to be automatically triggered after a transaction is committed, simplifying development complexity.

[0025] After the first transaction commits, the job rule transaction manager detects the commit event through the Spring transaction framework's callback mechanism. Upon detecting the event, the manager triggers the bound listener, thereby executing the business logic of the cleanup job rule in the second transaction. The second transaction is isolated from the first transaction; for example, using Spring's `@Transactional` annotation to set the transaction propagation behavior to `REQUIRES_NEW` ensures that the two transactions are independent. In the example, the listener triggers the cleanup job rule, and the system automatically cleans up temporary data and updates the site state. By triggering the listener to execute the cleanup job rule, automatic nested execution between rules is achieved. Transaction isolation prevents data pollution and improves system reliability.

[0026] After the cleanup rules are executed, the job rule transaction manager unbinds and cleans up the listeners. The unbinding process is achieved by removing the association between the listener and the first transaction and releasing the memory resources occupied by the listener. For example, after the cleanup rules are completed, the system calls the manager's cleanup method to delete the listener from the registry. By unbinding and cleaning up the listeners, resource waste is avoided, ensuring the efficiency and security of the system during long-term operation.

[0027] In one embodiment, initializing the job rule transaction manager in step S101 includes: By integrating the Spring transaction framework into the job rule transaction manager through dependency injection, the job rule transaction manager can utilize the transaction listening function of the Spring transaction framework.

[0028] In implementation, the initialization of the job rule transaction manager integrates the Spring transaction framework into it via dependency injection. Specifically, during system startup, Spring's dependency injection mechanism is used. For example, the `@Autowired` annotation automatically injects the Spring transaction manager instance into the job rule transaction manager's class properties, allowing the transaction manager to directly call Spring's API to manage transaction lifecycles. For instance, during the startup of a semiconductor manufacturing system, the job rule transaction manager is configured as a Spring bean, ensuring seamless integration with the Spring container. This dependency injection approach achieves standardization and maintainability for the job rule transaction manager, eliminating the need for developers to manually handle transaction integration details and reducing code complexity.

[0029] In one embodiment, creating a listener in step S103 includes: The listener is created through the interface provided by the job rule transaction manager, and the listener name is constructed according to preset rules. The preset rules include a combination of a fixed prefix, the batch number, the unique code of the process site, and the name of the closing work rule to ensure that the listener name is globally unique.

[0030] In implementation, the listener creation process is handled through an interface provided by the job rule transaction manager. Specifically, the job rule transaction manager exposes a `createListener` method, which accepts parameters such as the batch number (BATCH001), the unique process site code (SITE001), and the closing rule name. It then constructs the listener name based on preset rules, for example, combining the fixed prefix `LISTENER`, the batch number `BATCH001`, the unique process site code `SITE001`, and the closing rule name into a globally unique name: `LISTENER_BATCH001_SITE001` (Closing Rule). In this scenario, after the rule execution is reported as complete, the system calls this interface to create the listener, avoiding conflicts with other listeners. This globally unique listener name construction ensures accurate listener identification and avoids naming conflicts, improving system reliability in multi-tasking environments.

[0031] In one embodiment, binding the listener to the first transaction in step S103 includes: The listener is bound to the first transaction through the job rule transaction manager, and multiple listeners can be bound to the same transaction in a specific order, wherein the specific order is determined based on business rules.

[0032] In implementation, the step of binding a listener to the first transaction is supported by the job rule transaction manager, which allows multiple listeners to be bound in a specific order. This specific order is determined based on business rules. For example, in semiconductor manufacturing, if business rules require preprocessing rules to be executed before finishing rules, the job rule transaction manager provides the `bindListener` method, which allows listeners to be added to the transaction's listener queue in sequence. In the example, only one listener is bound, but the manager supports multiple bindings. The order can be arranged according to business logic as needed, thus enabling flexible scheduling of transaction triggering in complex business scenarios by supporting the sequential binding of multiple listeners, ensuring the correctness and scalability of rule execution.

[0033] In one embodiment, triggering the listener in step S104 includes: After the first transaction is committed, the job rule transaction manager detects the commit event through the callback mechanism of the Spring transaction framework and triggers the listener bound to the first transaction; Once triggered, the listener's execution logic runs in a second transaction, which is isolated from the first transaction through a transaction isolation mechanism.

[0034] In implementation, the listener triggering process utilizes Spring's transaction framework callback mechanism to detect the first transaction's commit event. Specifically, after the first transaction commits, Spring automatically triggers the transaction commit callback. The job rule transaction manager captures this event and executes the bound listener logic. This listener logic runs in the second transaction, which is isolated from the first transaction through transaction isolation mechanisms, such as setting the transaction propagation behavior to REQUIRES_NEW. For example, after the TrackOut transaction commits, Spring's callback mechanism calls the listener, thereby executing the cleanup job rules in an independent transaction. This approach, using Spring's callback mechanism and transaction isolation, achieves automatic detection and isolated execution of transaction events, preventing data cross-contamination and improving system consistency.

[0035] In one embodiment, the business logic for executing the cleanup rules in the second transaction includes: If the business logic of the closing work rule executes normally, then the second transaction is committed; If the business logic of the closing work rule fails to execute, the second transaction will be rolled back, and the rollback will not affect the first transaction that has already been committed.

[0036] In practice, the business logic for executing the cleanup rules in the second transaction includes committing or rolling back the transaction based on the execution result. Specifically, if the business logic executes normally, such as the cleanup rules successfully cleaning up temporary data and updating the site status, the system automatically commits the second transaction; if the business logic executes abnormally, such as data verification failure or insufficient resources, the system rolls back the second transaction, and the rollback operation only affects the current transaction and does not affect the first transaction that has already been committed.

[0037] After the rollback operation, the system continues with subsequent processing, such as logging exceptions and updating relevant statuses to indicate that the closing work rule failed. It may also trigger error notification mechanisms, such as sending alarm messages to the operator. However, it will not automatically retry the closing work rule to avoid an infinite loop. In this scenario, when the closing work rule is executed, the system checks the resource status. If an exception is found, the second transaction is rolled back. Subsequently, the system marks the wafer status corresponding to batch number BATCH001 and the unique process site code SITE001 as requiring manual intervention and records error details in the log file. This rollback and subsequent error handling achieve transaction atomicity and system robustness, ensuring data consistency and preventing cascading failures. Furthermore, the logging and notification mechanisms provide traceable fault management.

[0038] In one embodiment, unbinding and cleaning up the listener in step S105 includes: The job rule transaction manager removes the association between the listener and the first transaction and releases the system resources occupied by the listener.

[0039] In implementation, the steps of unbinding and cleaning up listeners involve removing the association between the listener and the first transaction and releasing resources through the job rule transaction manager. Specifically, the job rule transaction manager provides the `unbindListener` method, which is called after the closing job rule execution is complete to remove the listener from the transaction listener list and reclaim the memory resources it occupies. For example, in this scenario, after the listener is unbound, the system immediately releases related resources to prevent memory accumulation. Thus, by unbinding and cleaning up listeners, efficient management of system resources is achieved, memory leaks are avoided, and long-term performance is optimized.

[0040] Example 2 like Figure 2 As shown, a transaction management system with nested execution of dispatch rules includes: The job rule transaction manager integrates the Spring transaction framework to manage the triggering order of multiple job rules and ensure transaction isolation between each job rule. An initialization module is used to initialize the job rule transaction manager; The request processing module is used to respond to a report completion rule request initiated by a user operation or system event, and execute the business logic of the report completion rule in the first transaction, wherein the report completion rule is a type of job rule, and the request includes a batch number and a unique process station code. The listener management module is used to create a listener through the job rule transaction manager after the reporting completion rule is executed, and bind the listener to the first transaction, wherein the listener is used to listen for the commit event of the first transaction; The event triggering module is used to detect the commit event through the job rule transaction manager after the first transaction is committed, and trigger the business logic of executing the closing work rule in the second transaction, wherein the closing work rule is a type of job rule, and the second transaction is isolated from the first transaction; The cleanup module is used to unbind and clean up the listener through the job rule transaction manager after the completion of the closing work rule.

[0041] The transaction management system with nested execution of dispatch rules provided in this embodiment has the same implementation principle and technical effect as the method embodiment in Embodiment 1. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in Embodiment 1.

[0042] Example 3 A computer-readable storage medium having a computer program stored thereon, the computer program being executed by a computer to perform a transaction management method for nested execution of dispatch rules as described in Embodiment 1 above.

[0043] Example 4 An electronic device includes: a memory and a processor, wherein the processor and the memory are connected; The memory is used to store programs; The processor calls a program stored in the memory to execute a transaction management method for nested execution of dispatch rules as described in Embodiment 1.

[0044] It should be noted that the electronic device mentioned may be, but is not limited to, personal computers (PCs), tablet computers, mobile internet devices (MIDs), etc.

[0045] It should be noted that processors, memory, and other components that may be present in electronic devices are electrically connected to each other, directly or indirectly, to enable data transmission or interaction. For example, processors, memory, and other components may be electrically connected to each other via one or more communication buses or signal lines.

[0046] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

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

[0048] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0049] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, laptop, server, mobile phone, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0050] The above description is merely a preferred embodiment of the present invention and does not constitute any limitation on the present invention. Any simple modifications, alterations, or equivalent structural changes made to the above embodiments based on the technical essence of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A transaction management method for nested execution of dispatch rules, characterized in that, Includes the following steps: Step S101: Initialize the job rule transaction manager, wherein the job rule transaction manager integrates the Spring transaction framework to manage the triggering order among multiple job rules and ensure transaction isolation of each job rule; Step S102: In response to a report completion rule request initiated by a user operation or system event, execute the business logic of the report completion rule in the first transaction, wherein the report completion rule is a type of job rule, and the request includes a batch number and a unique process station code; Step S103: After the reporting completion rule is executed, a listener is created through the job rule transaction manager and the listener is bound to the first transaction, wherein the listener is used to listen for the commit event of the first transaction; Step S104: After the first transaction is committed, the job rule transaction manager detects the commit event through the listener and triggers the business logic of executing the cleanup work rule in the second transaction, wherein the cleanup work rule is a type of job rule, and the second transaction is isolated from the first transaction; Step S105: After the closing work rule is executed, the listener is unbound and cleaned up through the job rule transaction manager.

2. The method according to claim 1, characterized in that, The initialization of the job rule transaction manager in step S101 includes: By integrating the Spring transaction framework into the job rule transaction manager through dependency injection, the job rule transaction manager can utilize the transaction listening function of the Spring transaction framework.

3. The method according to claim 1, characterized in that, Creating a listener in step S103 includes: The listener is created through the interface provided by the job rule transaction manager, and the listener name is constructed according to preset rules. The preset rules include a combination of a fixed prefix, the batch number, the unique code of the process site, and the name of the closing work rule to ensure that the listener name is globally unique.

4. The method according to claim 3, characterized in that, Binding the listener to the first transaction in step S103 includes: The listener is bound to the first transaction through the job rule transaction manager, and multiple listeners can be bound to the same transaction in a specific order, wherein the specific order is determined based on business rules.

5. The method according to claim 1, characterized in that, The triggering of the listener in step S104 includes: After the first transaction is committed, the job rule transaction manager detects the commit event through the callback mechanism of the Spring transaction framework and triggers the listener bound to the first transaction; Once triggered, the listener's execution logic runs in a second transaction, which is isolated from the first transaction through a transaction isolation mechanism.

6. The method according to claim 5, characterized in that, The business logic for executing the cleanup rules in the second transaction includes: If the business logic of the closing work rule executes normally, then the second transaction is committed; If the business logic of the closing work rule fails to execute, the second transaction will be rolled back, and the rollback will not affect the first transaction that has already been committed.

7. The method according to claim 1, characterized in that, The step S105 of unbinding and cleaning the listener includes: The job rule transaction manager removes the association between the listener and the first transaction and releases the system resources occupied by the listener.

8. A transaction management system with nested execution of dispatch rules, characterized in that, include: The job rule transaction manager integrates the Spring transaction framework to manage the triggering order of multiple job rules and ensure transaction isolation between each job rule. An initialization module is used to initialize the job rule transaction manager; The request processing module is used to respond to a report completion rule request initiated by a user operation or system event, and execute the business logic of the report completion rule in the first transaction, wherein the report completion rule is a type of job rule, and the request includes a batch number and a unique code of the process site; The listener management module is used to create a listener through the job rule transaction manager after the reporting completion rule is executed, and bind the listener to the first transaction, wherein the listener is used to listen for the commit event of the first transaction; The event triggering module is used to detect the commit event through the job rule transaction manager after the first transaction is committed, and trigger the business logic of executing the closing work rule in the second transaction, wherein the closing work rule is a type of job rule, and the second transaction is isolated from the first transaction; The cleanup module is used to unbind and clean up the listener through the job rule transaction manager after the completion of the closing work rule.

9. An electronic device, characterized in that, include: A memory and a processor, wherein the processor and the memory are connected; The memory is used to store programs; The processor invokes a program stored in the memory to execute the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is executed by a computer to perform the method as described in any one of claims 1-7.

Images