A transaction request processing method, device and storage medium

Abstract

The application discloses a transaction request processing method and device and a storage medium, relates to the technical field of distributed computing, and comprises the following steps: in response to a transaction operation request, a root component performs a corresponding calling operation, records the calling operation to form an ordered calling instance tree, and receives task processing results returned by each role component; a deduplication list is determined based on the calling tree, a closing request is sent along each calling branch in stages, a confirmation message is determined when all closing ready responses are returned, the task processing result of the root component is submitted, and a success result is returned to the initiator; the confirmation message is sent based on the deduplication list, each role component is instructed to submit the task processing result; a completion receipt is received, the completion state and the processing mode are determined based on the completion receipt and the deduplication list, and when a context loss indication is received, parent calling recovery is triggered according to the calling tree. The application realizes reliable completion of the transaction operation request through double-view cooperation, pre-submission inspection and independent submission driven by the confirmation message.

Description

Technical Field

[0001] This application relates to the field of distributed computing technology, and in particular to a transaction request processing method, device and storage medium. Background Technology

[0002] In distributed systems, multiple business components typically have independent databases and local transaction capabilities to assume different business roles or authoritative facts. When a single root business operation requires the collaboration of multiple components, existing solutions have many shortcomings.

[0003] Two-phase commit requires multiple participants to enter a ready state, and a coordinator then summarizes the responses and decides whether to commit or rollback. In environments where terminals may be offline, networks are intermittent, and databases are independent, this approach can easily prolong the time spent on locks and resources, making the overall response dependent on the slowest participant.

[0004] The try-confirm-cancel approach typically requires each business transaction to implement resource reservation, confirmation, and cancellation logic separately. For business facts without inherent reservation implications, physical actions that have already occurred, or facts with independent roles, reverse cancellation is difficult to implement precisely. Long transaction compensation schemes first commit multiple partial transactions and then correct the result through compensation actions, but compensation may not necessarily restore the original state and may introduce additional versions, idempotency, and external side-effect control.

[0005] Furthermore, when the inter-component call relationships are complex, existing methods are prone to issues such as circular waiting or duplicate commits. When the same operation enters the same component multiple times, persisting each call separately can lead to the exposure of intermediate states, repeated version increments, duplicate message generation, and database write amplification. Moreover, the lack of ongoing accountability after confirmation means that while some participating components have completed their tasks, incomplete components may be unable to continue due to offline status, restarts, or the loss of transaction objects. Simply returning a commit response does not prove that the root business operation has been completed by all necessary components, nor does it provide a safe way to determine whether a redo is necessary after a response is lost.

[0006] Therefore, how to reduce the processing efficiency reduction caused by repeated submissions, loop waiting, exposure of intermediate states, and offline, restart, or lost responses of some components in a distributed system is an urgent technical problem to be solved.

[0007] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0008] The main purpose of this application is to provide a transaction request processing method, device and storage medium, which aims to solve the technical problem of how to reduce the processing efficiency reduction of a cross-component business operation in a distributed system due to repeated submissions, loop waiting, exposure of intermediate states and offline, restart or response loss of some components.

[0009] To achieve the above objectives, this application proposes a transaction request processing method, the method comprising: In response to a transaction operation request, the root component of the transaction operation request executes the call operation corresponding to the transaction operation request. During the execution of the call operation, the call operations of each role component are recorded to form an ordered call instance tree, and the task processing results returned by each role component are received. If all the role components have returned the task processing results, a deduplication list is determined based on the ordered call instance tree, and the deduplication list contains the identity information of each role component. Along each call branch of the ordered call instance tree, the close request is sent to each of the role components level by level, and the close ready response is received from each of the role components; If all the aforementioned role components have returned the closed ready response, a confirmation message is determined based on the deduplication list, and the task processing result of the root component is determined and submitted. After the root component successfully submits the task processing result, it first returns a success result to the initiator of the transaction operation request, and then sends a confirmation message to each of the role components based on the deduplication list. The confirmation message is used to instruct each role component to submit the corresponding task processing result. Upon receiving a context loss indication from each of the aforementioned role components, the parent call recovery process of each of the aforementioned role components is triggered according to the ordered call instance tree; The system receives completion receipts returned by each role component, and determines the completion status of the transaction operation request and the processing method of the completion status based on the completion receipts returned by each role component and the deduplication list. The completion receipt is the receipt returned by the role component after submitting the task processing result.

[0010] In one embodiment, the step of sending the close request level by level to each of the role components along each call branch of the ordered call instance tree, and receiving the close ready response from each of the role components, includes: Along each call branch of the ordered call instance tree, a close request is sent to each of the role components level by level. The close request is used to instruct each role component to perform a commit check on the task processing result after all the necessary sub-call branches of the role component have returned a close ready response. The commit check includes conflict detection of the write data corresponding to each role component. If all necessary sub-call branches have returned the closed ready response and each role component has passed the commit detection, control each role component to return the closed ready response to the parent component corresponding to each role component, and receive the closed ready response that is aggregated to the root component level by level; If any of the aforementioned role components returns a close failure response or fails to return a close ready response within a preset time period, a release request is sent to the role component that has returned the close ready response, and each role component participating in the transaction operation request is instructed to clear the root transaction work area that has not yet been committed. The release request is used to instruct the role component that has returned the close ready response to release the resources occupied in the process of responding to the close request.

[0011] In one embodiment, the step of executing the call operation corresponding to the transaction operation request through the root component of the transaction operation request and receiving the task processing results returned by each of the role components includes: When any role component is invoked for the first time, a corresponding root transaction workspace is established for that role component; The intermediate results generated by the role component during the processing of the call operation are temporarily stored in the root transaction work area; When the role component completes the processing of the call operation, the task processing result returned by the role component is received, and the task processing result is determined based on the intermediate result.

[0012] In one embodiment, the step of recording the call operations of each role component to form an ordered call instance tree includes: Upon detecting a call operation from each of the aforementioned role components, a call node is created for the call operation, and the parent call relationship corresponding to the call operation is recorded in the call node; The result of the invoked role component is stored in the root transaction work area corresponding to the invoked role component; In the case of a circular call between the role components, a circular iteration number is recorded for the circular call, and the circular call is terminated when the circular call reaches at least one of the following conditions: termination condition, maximum expansion depth, maximum number of iterations, or timeout gate. The calling nodes are arranged according to the order in which the calling operations are initiated, forming the ordered calling instance tree.

[0013] In one embodiment, the step of determining the deduplication list based on the ordered call instance tree after all the role components have returned the task processing results includes: Stop updating the ordered call instance tree; Extract the identity information of each role component from the ordered call instance tree, and deduplicate the extracted identity information; The deduplication list is determined based on the deduplicated identity information of the character components.

[0014] In one embodiment, the step of determining the completion status of the transaction operation request and the processing method of the completion status based on the completion receipts returned by each role component and the deduplication list includes: If no response to the confirmation message is received from the role component, the confirmation message carrying the same transaction identifier is sent to the role component repeatedly; if the role component already has a completion receipt corresponding to the transaction identifier, the completion receipt is returned without resubmitting the task processing result. Once all the role components in the deduplication list have returned the completion receipt, the transaction operation request is determined to be completed.

[0015] In one embodiment, the step of triggering the parent call recovery process of each of the role components according to the ordered call instance tree includes: In the ordered call instance tree, determine all the call nodes of the role component, and the parent component corresponding to each call node; For each of the aforementioned calling nodes, a recovery instruction is sent to the parent component corresponding to each of the aforementioned calling nodes. The recovery instruction is used to instruct the parent component to initiate a recovery call to the role component according to the original calling parameters saved by the parent component, and to provide the role component with the first return value saved by the parent component as the return result of the recovery call. The first return value is the result recorded and saved by the parent component when it first calls the role component. If all parent components corresponding to the calling nodes of the role component have completed the recovery call, the confirmation message is sent repeatedly to the role component.

[0016] In one embodiment, the step of determining and submitting the task processing result of the root component includes: Generate a record of confirmation messages to be sent for each of the role components in the deduplication list; In a local database transaction, the task processing result of the root component and the record to be sent are jointly submitted to the local database of the root component.

[0017] Furthermore, to achieve the above objectives, this application also proposes a transaction request processing apparatus, which includes: The instance tree generation module is used to respond to a transaction operation request, execute the call operation corresponding to the transaction operation request through the root component of the transaction operation request, record the call operations of each role component during the execution of the call operation to form an ordered call instance tree, and receive the task processing results returned by each role component. The deduplication list generation module is used to determine a deduplication list based on the ordered call instance tree, provided that all role components have returned the task processing results. The deduplication list contains the identity information of each role component. The shutdown response module is used to send shutdown requests to each of the role components level by level along each call branch of the ordered call instance tree, and to receive shutdown ready responses from each of the role components. The result submission module is used to determine a confirmation message based on the deduplication list, and to determine and submit the task processing result of the root component, when all the aforementioned role components have returned the closed ready response; The confirmation message sending module is used to first return a success result to the initiator of the transaction operation request after the task processing result of the root component is successfully submitted, and then send a confirmation message to each of the role components based on the deduplication list. The confirmation message is used to instruct each role component to submit the corresponding task processing result. The call recovery module is used to trigger the parent call recovery process of each of the aforementioned role components according to the ordered call instance tree when a context loss indication is received from each of the aforementioned role components. The status determination module is used to receive the completion receipts returned by each role component, and determine the completion status of the transaction operation request and the processing method of the completion status based on the completion receipts returned by each role component and the deduplication list. The completion receipt is the receipt returned by the role component after submitting the task processing result.

[0018] In addition, to achieve the above objectives, this application also proposes a transaction request processing apparatus, the apparatus comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the transaction request processing method as described above.

[0019] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the transaction request processing method as described above.

[0020] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the transaction request processing method as described above.

[0021] Therefore, the technical solution provided in this application, during the processing of transaction operation requests, executes the corresponding call operation through the root component, records the call operations of each role component to form an ordered call instance tree, and receives the task processing results returned by each role component; after each role component has returned the task processing results, a deduplication list is determined based on the ordered call instance tree, so that the close request is sent level by level along the call branch and the close ready response is converged level by level along the call branch; when each role component has returned the close ready response, a confirmation message is determined based on the deduplication list, and the task processing result of the root component is submitted; after the root component submits successfully, it first returns a success result to the initiator of the transaction operation request, and then sends a confirmation message to each role component based on the deduplication list, instructing each role component to submit the task processing result; it receives the completion receipts returned by each role component, determines the completion status and processing method of the transaction operation request based on the completion receipts and the deduplication list, and triggers the parent call recovery process according to the ordered call instance tree when a context loss indication is received.

[0022] Therefore, this application performs conflict detection on the write data of each role component before sending the confirmation message by closing the request, ensuring that each role component executes the commit after meeting the commit conditions, avoiding the situation where some role components commit and others cannot commit; through the dual-view design of ordered call instance tree and deduplication list, the call relationship is fully preserved for fault recovery, while avoiding duplicate confirmations for the same role component during the confirmation phase; the confirmation message instructs each role component to independently submit the local task processing results, without the need for synchronization and coordination between the databases of each role component; in the event of abnormal situations such as duplicate confirmation, lost response, component restart, or lost context, the unfinished part is continued by repeatedly sending confirmation messages and parent calls to restore the process until all role components return completion receipts, confirming that the transaction operation request has been processed. This scheme supports circular calls between components, and multiple calls of the same role component are merged into a single commit, improving the reliability and fault tolerance of distributed transaction processing. Attached Figure Description

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

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

[0025] Figure 1 This is a flowchart illustrating an embodiment of the transaction request processing method for this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the transaction request processing method for this application. Figure 3 This is a flowchart illustrating Embodiment 3 of the transaction request processing method for this application. Figure 4 This is a schematic diagram of the module structure of the transaction request processing device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the transaction request processing method in this application embodiment.

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

[0027] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0028] To better understand the technical solution of this application, a detailed description is provided below in conjunction with specific implementation methods.

[0029] This application's embodiments are applicable to distributed processing scenarios where multiple business components collaborate to complete a single business operation. Role components refer to business components that undertake specific business responsibilities, such as components responsible for material management, quality inspection, and equipment qualification verification, respectively. Each role component maintains its own business data within its scope of responsibility. Some role components have their own databases and support local transactions, which refer to the commit and rollback mechanisms within a single database; different role components can use different database products. Role components can synchronously call each other; synchronous calling refers to a calling method where the caller initiates a call and waits for the callee to return the processing result. During the processing of a single business operation, the same role component may be called multiple times, and calls between role components may also form circular calls. The network may be interrupted, retransmitted, or lose responses; role components may go offline, restart, or lose the intermediate processing state stored in memory. This application does not require the databases of each role component to remain completely consistent at the same time; each role component is only responsible for the consistency of its own business data. This application's embodiments are not limited to manufacturing execution scenarios and are also applicable to systems where multiple business components collaborate, such as warehousing, quality, approval, equipment control, and order processing.

[0030] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as an application server deployed in the aforementioned system. In this embodiment, each step of the method is executed or coordinated by a root component. The root component refers to the component that receives business operation requests and is responsible for following up on the entire processing process, while the role components refer to the components that are called to participate in the processing and submit their own processing results. The following uses a transaction coordination service device as an example to describe this embodiment and the following embodiments.

[0031] Example 1 Based on this, refer to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the transaction request processing method of this application. This embodiment provides a transaction request processing method, which includes steps S10 to S70: Step S10: In response to the transaction operation request, execute the call operation corresponding to the transaction operation request through the root component of the transaction operation request. During the execution of the call operation, record the call operations of each role component to form an ordered call instance tree, and receive the task processing results returned by each role component.

[0032] It should be noted that a transaction operation request refers to a business operation that requires the collaborative processing of multiple role components. Examples include an operator scanning a code to start work or clicking a button on a terminal, or an operation triggered by a system scheduled task or batch processing command. A call operation refers to a call initiated by the root component or a role component to other role components during the processing of a transaction operation request. The called role component performs the corresponding business processing and returns the result. Call operations can form chained calls, such as the root component calling role component A, which in turn calls role component B; or they can form circular calls, such as role component A calling role component B, role component B calling role component C, and role component C calling role component A.

[0033] It's important to note that the ordered call instance tree (also known as the call tree) is a record structure for call operations. A call node is a node in the tree that records a single call; each call node corresponds to one actual call. Call nodes are arranged in the order in which they were initiated and the tree records the parent-child relationships between them—that is, who called whom. It's important to understand that the nodes in the tree correspond to calls, not components. When a component with the same role is called multiple times, it corresponds to multiple call nodes in the tree. The recording of the call tree is automatically completed by the transaction processing program; the business processing program does not need to be aware of the tree structure construction process.

[0034] It should be noted that the task processing result refers to the final processing result returned by each role component after completing the processing of the called operation. The called role component returns the processing result to the caller, and after being passed down level by level, it is finally summarized to the root component.

[0035] In one feasible implementation, a transaction identifier can be assigned to each transaction operation request. The transaction identifier is used to uniquely distinguish this transaction operation request among numerous requests. The transaction identifier can be determined by the identifier of the component that initiated the request and the request number, which is generated when the request is first sent. When the terminal sends a request and does not receive a response, and then sends the same request again, the same request number is used, thereby using the same transaction identifier, avoiding the same business operation being treated as two different transactions due to repeated sending.

[0036] Step S20: After all the role components have returned the task processing results, determine the deduplication list based on the ordered call instance tree. The deduplication list contains the identity information of each role component.

[0037] It's important to note that the deduplication list is a list obtained by deduplicating components from the ordered call instance tree by their identity. Even if a component with the same role corresponds to multiple call nodes in the tree, only one identity information is retained in the deduplication list. The deduplication list is used to determine the recipients of subsequent confirmation messages and to track completion progress. The ordered call instance tree is retained intact after the deduplication list is determined for subsequent fault recovery. The deduplication list does not retain the call node positions and parent-child relationships; therefore, the ordered call instance tree cannot be reconstructed from the deduplication list.

[0038] Step S30: Send the shutdown request to each role component level by level along each call branch of the ordered call instance tree, and receive the shutdown ready response from each role component.

[0039] It's important to note that the close request is a pre-commit check query performed before the confirmation message is sent. The close request propagates down the call branches of the ordered call instance tree. Each component only returns a close-ready response along its corresponding parent call branch when the necessary sub-call branch is ready and the component meets the commit conditions. The close request and the subsequent confirmation message are two different control messages; the close request is a pre-commit check query, while the confirmation message is the formal commit instruction. Subsequent confirmation and commit operations can only be executed after all components have returned a close-ready response. If any necessary call branch fails to return a close-ready response within the preset time, the confirmation message sending and commit phase will not proceed.

[0040] Step S40: After all role components have returned a closed and ready response, determine the confirmation message based on the deduplication list, and determine and submit the task processing result of the root component.

[0041] It should be noted that the confirmation message is sent to each role component in the deduplication list, and the confirmation message is used to instruct each role component to submit its task processing result. The root component also undertakes some business processing itself, and the task processing result of the root component refers to the final result of its own business processing. After all role components have returned task processing results and have all returned a close ready response, the root component determines and submits its own task processing result. The root component does not need to wait for each role component to complete its own submission when submitting its task processing result; each role component submits its result after receiving the confirmation message.

[0042] Step S50: After the root component successfully submits the task processing result, first return a success result to the initiator of the transaction operation request, and then send a confirmation message to each role component based on the deduplication list. The confirmation message is used to instruct each role component to submit the corresponding task processing result.

[0043] It should be noted that after the confirmation message is sent, if there are still role components that have not been submitted, the root component will continue to follow up until all role components in the deduplication list have returned a completion receipt.

[0044] It should be noted that a successful result returned to the initiator indicates that the root component's task processing result has been submitted and the transaction operation request has entered the continuous progress phase, which constitutes confirmation and acceptance of this transaction. Confirmation and acceptance does not equate to the overall completion of the transaction operation request. The overall completion status is only formed after all role components in the deduplication list have returned completion receipts. The root component's record will store confirmation and acceptance separately to avoid providing temporary partial completion as overall completion to the outside world. For requests that arrive repeatedly with the same transaction identifier, the initial acceptance result will be returned directly without duplicate processing.

[0045] It should be noted that, in one feasible implementation, the root component concurrently sends confirmation messages to each role component in the deduplication list, and each role component executes its own local commit without waiting for the others. Upon receiving a confirmation message, a role component commits the write data corresponding to the task processing result and the completion receipt in the same local database transaction, and then returns the completion receipt. Since the write data and completion receipt are written together in the same local transaction, response loss, duplicate confirmations, and role component restarts will not lead to duplicate writes: a role component that receives a duplicate confirmation message will query its local completion receipt and directly return the initial result, without incrementing the version number, generating a new document number, or triggering duplicate operations on external devices; under the same transaction operation request, the business commit of the same role component is executed only once.

[0046] Step S60: Upon receiving context loss indications from each role component, trigger the parent call recovery process of each role component according to the ordered call instance tree.

[0047] It's important to note that transaction context refers to the intermediate processing state that a role component stores in memory during the processing of a transaction operation request. If a role component restarts, this intermediate processing state is lost, making it impossible to complete the transaction commit. In this case, the role component will return a context loss indication to the root component. The parent call recovery process refers to finding the parent component that called the role component based on its call node in the ordered call instance tree. The parent component then re-initiates the call to help the role component rebuild its lost intermediate processing state. The handling of no response differs from that of a context loss indication: for an unresponsive role component, only a confirmation message is repeatedly sent; parent call recovery is only triggered when the role component explicitly returns a context loss indication.

[0048] Step S70: Receive the completion receipts returned by each role component, and determine the completion status of the transaction operation request and the processing method of the completion status based on the completion receipts and deduplication list returned by each role component. The completion receipt is the receipt returned by the role component after submitting the task processing result.

[0049] It should be noted that the completion receipt is proof of submission returned by the role component after submitting the task processing result locally. The completion receipt and the task processing result are submitted in the same local database transaction. The root component updates the completion progress based on the completion receipt status of each role component in the deduplication list: when all role components in the deduplication list have returned completion receipts, the transaction operation request is determined to be completed; when there are role components that have not returned completion receipts, the transaction operation request remains incomplete, and the root component continues to repeatedly send confirmation messages to the incomplete role components until all are completed; after the number of repeated sending reaches the pre-set limit, the transaction operation request is marked as requiring manual processing, and relevant processing records are retained for auditing. The status of requiring manual processing is different from the status of processing completed.

[0050] It should be noted that the aforementioned pre-set maximum number of attempts is hereinafter referred to as the maximum number of resend attempts. The maximum number of resend attempts refers to the maximum number of times an acknowledgment message can be sent repeatedly to the same role component, accumulated based on the number of resends during the period when the role component has not returned a completion receipt; once the role component returns a completion receipt, it will no longer be resent. For example, the maximum number of resends can be configured to be 5 to 10 times, based on the typical recovery time of a role component after going offline, restarting, or experiencing a network interruption, and the business's tolerance for processing time; a progressively increasing waiting interval can be set between two adjacent resends. A larger value increases the probability of obtaining a completion receipt through retries, and the longer the transaction remains in an incomplete state; a smaller value marks the transaction operation request as requiring manual processing earlier.

[0051] In this embodiment, through steps S10 to S70, the application records the call operations during the call execution process to form an ordered call instance tree, determines the deduplication list based on the tree, and propagates the close request and close ready response along the call branches to complete the pre-commit check. After all role components have returned the close ready response, the task processing result of the root component is submitted. Success is returned to the request initiator first, and then the confirmation message drives each role component to submit its own task processing result. The process continues to advance based on the completion receipt and the deduplication list until the processing is completed. When the context is lost, the parent call is triggered to recover based on the call tree, thereby achieving reliable completion of a transaction operation request without requiring the databases of each role component to maintain cross-database consistency.

[0052] Example 2 Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment can be referred to the above description, and will not be repeated hereafter.

[0053] In one feasible implementation, refer to Figure 2 , Figure 2 This is a flowchart illustrating Embodiment 2 of the transaction request processing method of this application. Step S10, which involves performing a call operation and receiving the task processing result, includes: It should be noted that the form of information exchange between the components in this application is not limited. Any form that can deliver messages to the target component, such as inter-process communication, remote call, message queue, or shared storage, can be used; the message format and encoding method are also not limited. The content carried by various messages will be described in the corresponding steps. As long as it can carry the corresponding content and be delivered between components, it belongs to the message referred to in this application.

[0054] Step S111: When any role component is invoked for the first time, a corresponding root transaction workspace is established for the role component.

[0055] It's important to note that the root transaction workspace is a storage area where a role component temporarily stores intermediate processing states and data to be written during the handling of a transaction operation request. Each role component establishes a separate root transaction workspace for each transaction operation request, and only one root transaction workspace is established for the same role component while handling the same transaction operation request. The root transaction workspace is used to store intermediate results during processing and does not store formal business data. For example, in the barcode scanning start-up scenario, the inventory role component first verifies the materials, adjusts the quantity after quality calculation, and is then called a third time due to route calculation; all three calls share the same root transaction workspace.

[0056] Step S112: Temporarily store the intermediate results generated by the role component during the processing of the call operation in the root transaction work area.

[0057] It should be noted that intermediate results refer to data generated by a role component during the processing of a call operation, data that is ready to be written to the database but has not yet been written. This includes data to be written, the version number of business data read at the start of processing, and branch results generated by a single call. When a role component is called repeatedly or in a loop, the intermediate results generated by each call are temporarily stored in the same root transaction work area, thereby merging multiple calls to the same role component for processing. Before the confirmation message is sent, if the transaction is canceled or times out, only the temporarily stored data in the root transaction work area is cleared. Since no formal business data has been written at this time, no rollback operation is required.

[0058] For example, the contents of the root transaction workspace can be divided into three categories according to their purpose. The identity class includes the transaction identifier, role component identity, branch identity, and request summary, using strings. The result class includes intermediate results, data to be written, and final results, which can be stored using structured data or business entity objects, respectively saving the processing results returned by each call, the formal business data to be written to the local database, and the final result determined before commit. The recovery class includes the business data version number (using an integer or timestamp structure), the initial result (for reuse during repeated calls or parent call recovery), and the derived transaction intent (recording subsequent operations to be executed sequentially after confirmation). Multiple calls from the same role component share a single workspace record, while different role components each have their own record.

[0059] Step S113: After the role component completes the processing of the call operation, receive the task processing result returned by the role component. The task processing result is determined based on the intermediate result.

[0060] It should be noted that the task processing result is the final result determined by the role component based on the intermediate results in the root transaction workspace after processing. Unlike the intermediate results, the task processing result is returned to the caller and ultimately summarized in the root component. In one feasible implementation, the branch identity refers to the identifier of the call in the call tree, used to distinguish different calls, and the request digest refers to the summary of the call request content. When the same call arrives repeatedly due to network reasons, if the branch identity and request digest are the same, the role component directly returns the processing result of the first call; if the branch identity is the same but the request digest is different, it indicates that the request is erroneous, and the role component refuses to process it and issues an alert.

[0061] In this implementation, by establishing a root transaction workspace corresponding to the transaction operation request for the role component that is called for the first time, and temporarily storing the intermediate results generated during the processing in the root transaction workspace, the results of multiple calls and cyclic calls of the same role component are merged into the same workspace, and the task processing result is determined based on the merged intermediate results, thereby avoiding the problems of intermediate state exposure, repeated version number increment and repeated writing caused by writing to the database separately for each call.

[0062] In one feasible implementation, step S10, which records the invocation operations of each role component to form an ordered invocation instance tree, includes: Step S121: When the call operation of each role component is detected, a call node is created for the call operation, and the parent call relationship corresponding to the call operation is recorded in the call node.

[0063] It should be noted that each call node corresponds to an actual call, and the parent call relationship records the caller and callee of that call. In one feasible implementation, each time a call is initiated, a child node position is reserved for this call in the call tree, and multiple calls are arranged sequentially according to the order in which they are initiated. When the callee returns the processing result, it also returns the subtree information generated by this call. The caller fills the subtree information into the reserved position, forms a complete subtree, and continues to return upwards. Finally, the root component obtains the complete call tree, and the business processing program does not participate in the construction of the tree.

[0064] For example, the content recorded on the calling node includes: node identifier (a string used to uniquely identify the calling node); caller identity and callee identity (component identifier strings, which constitute a parent-call relationship); branch identity (identifying which call branch the call belongs to); request digest (a fixed-length string obtained from the original call parameters using a digest algorithm, used to identify repeated calls); loop iteration number and sequence number (both integers, representing the loop iteration number of the call and multiple arrivals on the same node, respectively); processing status (enumerated values, such as processing, completed, submitted). The above fields and their data types are for illustrative purposes only; other equivalent forms can be used in actual implementations.

[0065] It's important to note that using a tree structure to record call facts is key to supporting circular calls: the tree expands into a call node with each call, and each call in the circular call forms a new call node pointing to its respective parent node. The tree structure itself does not contain cycles, thus it can completely record the facts of circular calls without affecting tree traversal and parent node location. For example, when role components A, B, and C form a circular call, each call expands into call nodes at different levels in the tree, with the same role component appearing repeatedly at different levels. If the call facts were recorded as a directed graph between components, the circular call would cause the graph structure to contain cycles, making traversal and parent node location difficult.

[0066] Step S122: Store the call result of the called role component in the root transaction work area corresponding to the called role component.

[0067] It should be noted that the call result is the processing output of the called role component for this call, corresponding to the intermediate result in step S112. Regardless of whether the called role component is being called for the first time or repeatedly, the call result is stored in the same root transaction work area. In one feasible implementation, when the caller receives the call result, it saves the original call parameters and the initial return value of this call together in the recovery data of this component for reuse in subsequent parent call recovery processes.

[0068] It should be noted that multiple calls corresponding to the same role component will have their processing results merged into the same root transaction workspace record for that role component, and will not be committed separately according to the number of calls. Intermediate results in the workspace are accumulated sequentially according to the order in which the calls were initiated: the processing result returned by each call is appended to the existing intermediate results. After all calls are completed, the accumulated results form the data to be written, and the final result is determined accordingly. If the branch identity has not appeared before, it is treated as a new call, and the processing result is appended to the intermediate results in sequence. Multiple calls in a loop are also accumulated in the same way as above: multiple arrivals within the same round are sorted by sequence number, and between different rounds, they are sorted by loop iteration number, and then accumulated sequentially. For example, if a role component receives three calls in a single transaction operation request, with the branch identities of the first two being A and B respectively; the third arrival has the same branch identity and request digest as the first, which is a duplicate arrival of the first, no new record is added, and the processing result of the first is directly returned, with two records actually participating in the accumulation. The number of calls corresponding to several call nodes in the tree only affects the cumulative number of calls, not the number of submissions. The component in this role will ultimately only submit once when it receives a confirmation message. The submission content is the accumulated data to be written and the confirmed result.

[0069] It should be noted that the merging process may encounter situations requiring adjudication. If the same data item has the same value in different calls, that value is directly adopted; if the values ​​are different, the business rules of the relevant component determine which one to use, for example, the result of the call that passes validation. When different calls make mutually exclusive write requests for the same data item, the business rules of the relevant component also determine which one to retain; if the business rules cannot determine which to keep, it means that the merged data to be written does not meet the commit conditions, the commit check of the relevant component fails, and a close failure response is returned.

[0070] Step S123: In the case of a circular call between role components, record the circular iteration number for the circular call, and end the circular call when the circular call reaches at least one of the following conditions: termination condition, maximum expansion depth, maximum number of iterations, or timeout gate.

[0071] It should be noted that circular calls refer to a situation where calls between role components form a loop. Each call in a circular call carries a loop iteration number, which is used to distinguish which call in the loop, so as to identify the corresponding call node. The expansion of a circular call is subject to at least one of the following constraints: business termination condition, maximum expansion depth, maximum number of iterations, or timeout threshold. The circular call ends when the constraint is met, thus avoiding infinite calls.

[0072] It should be noted that the three constraint parameters of the loop call limit the loop call from three dimensions: number of layers, number of times, and duration. The loop call ends when any one of these parameters is reached. Maximum expansion depth refers to the maximum number of layers that the loop call is allowed to expand to in the ordered call instance tree. It is measured by the call hierarchy traversed from the root component to the current calling node, with the role component directly called by the root component at the first layer. For example, the maximum expansion depth can be configured from 5 to 20 layers, such as 10 layers. A larger value covers a wider range of business scenarios, but increases the number of calling nodes and processing time. A smaller value results in faster convergence, but may prematurely end calls that could have continued. Maximum number of iterations refers to the maximum number of times the same role component is allowed to be called repeatedly in the same loop call, accumulated based on the number of times that role component is called in the loop call. For example, the maximum number of iterations can be configured from 5 to 20 times, such as 10 times. A larger value better adapts to business scenarios requiring multiple rounds of adjustment, but results in longer convergence time. A smaller value results in faster convergence, but insufficient loop rounds may lead to incomplete results. Timeout threshold refers to the maximum duration allowed for a loop call from the moment it is first initiated. For example, the timeout threshold can be configured in the range of seconds to minutes, such as 1 second to 30 seconds. A smaller value can prevent the loop call from occupying processing resources for a long time, while a larger value allows the loop to fully expand, but the overall processing time will be extended.

[0073] Step S124: Arrange the calling nodes according to the order initiation of the calling operations to form an ordered calling instance tree.

[0074] It should be noted that the calling nodes are arranged in the order in which the calls are initiated, and the order in which the processing results are returned by each component does not affect the order of the calling nodes in the tree.

[0075] In this implementation, by creating a call node for each call and recording the parent call relationship, the call result is stored in the root transaction work area of ​​the called role component. The iteration number is recorded for the cyclic call and a termination constraint is applied. The call nodes are arranged in the order of initiation, so that the ordered call instance tree can completely record the call facts and accommodate cyclic calls. Repeated calls of the same role component are retained in the tree in the form of multiple call nodes, providing a complete factual basis for the subsequent generation of the deduplication list and fault recovery.

[0076] In one feasible implementation, step S20, which involves determining the deduplication list based on the ordered call instance tree, includes: Step S211: Stop updating the ordered call instance tree.

[0077] It should be noted that after all role components have returned task processing results, that is, after all calls have returned results, no new call nodes will be added to the call tree. The call instance tree will be fixed, and the subsequent confirmation and recovery phases will be based on the fixed call instance tree.

[0078] Step S212: Extract the identity information of each role component from the ordered call instance tree, and deduplicate the extracted identity information.

[0079] It should be noted that when extracting the identity information of each role component from the call nodes, only one identity information is retained for multiple call nodes of the same role component. The deduplicated list only retains the component identity and does not retain the call node position, parent call relationship, or number of repetitions. Therefore, the ordered call instance tree cannot be reconstructed from the deduplicated list.

[0080] Step S213: Determine the deduplication list based on the deduplicated role component identity information.

[0081] It should be noted that the deduplication list is used to determine the recipients of confirmation messages and to track completion progress. The ordered call instance tree and the deduplication list are two views of the same transaction operation request facts, referred to as dual views below: the ordered call instance tree uses calls as nodes, retaining the call node position, parent-child relationship, and repetition count, fully reflecting the call facts; the deduplication list deduplicates by role component identity, retaining only the component identity and not the call node position or parent-child relationship. The ordered call instance tree continues to be fully retained after the deduplication list is determined: during the confirmation phase, the deduplication list is used to avoid duplicate confirmations for the same role component; during the recovery phase, the ordered call instance tree is used to locate all parent call branches of the target role component. The two views have different uses and cannot be substituted for each other. Specifically, the deduplication list is equivalent to the component index of this transaction. This deduplication list can consist of the following content and corresponding data structures: role component identity (string); completion receipt status (boolean or enumeration value, indicating whether the corresponding role component has returned a completion receipt); retry count (integer, the cumulative number of resentment of confirmation messages); call count (integer, representing the number of times the role component has been called in the call tree).

[0082] In this implementation, the call tree is stopped from being updated after all role components have returned the task processing results. The identity information is extracted from the fixed call instance tree to obtain a deduplication list while retaining the complete call tree. This ensures that the confirmation phase and the recovery phase each have an adapted view, avoiding repeated confirmation of the same role component by call node, and also retaining complete parent call branch information for the recovery phase.

[0083] In one feasible implementation, step S30, which involves sending a shutdown request and receiving a shutdown ready response, includes: Step S301: Along each call branch of the ordered call instance tree, the close request is sent to each role component level by level. The close request is used to instruct each role component to perform a commit check on the task processing result after all the necessary sub-call branches of each role component have returned a close ready response. The commit check includes conflict detection of the written data corresponding to each role component.

[0084] It should be noted that the process of sending the close request step by step along each call branch is as follows: it is first sent to the role component called by the root component, and then the role component that received the close request continues to send it to the role components called by its own component, until all role components are covered. When the same role component corresponds to multiple call branches and receives the close request repeatedly through multiple branches, only one commit check is performed and the same close ready response is returned. The check is not repeated and the value is not used repeatedly.

[0085] It should be noted that a necessary sub-call branch refers to a call branch that starts from a role component and extends downwards along the call tree, covering all role components that it calls. For role components without downstream calls, their necessary sub-call branches are considered ready. Commit detection refers to the check performed by a role component before submitting the task processing result to ensure it meets the commit conditions. Commit detection includes conflict detection for written data. Written data refers to the formal business data that a role component prepares to write to the local database in order to submit the task processing result. Conflict detection checks whether value conflicts will occur after the written data is formally written to the database. Value conflicts include two types: one is that a value in the written data that is required to be unique is duplicated with a value already formally written in the database, such as a document number to be written being duplicated with an existing document number; the other is that a value in the written data is duplicated with a value that other concurrent transactions need to write. Ultimately, the same value can only belong to one transaction.

[0086] It should be noted that the commit check is only performed on the component after all its necessary sub-call branches have returned a closed and ready response. The reason for this arrangement is that if the commit check is performed and the value is taken before the downstream call is completed, the component may make a judgment based on an incomplete state. After the downstream returns, the check will need to be re-checked and the result may need to be changed. By waiting for the downstream to be ready before checking the component, the check conclusion and the result of taking the value can be determined at one time.

[0087] It's important to note that conflict detection only reflects the data state at the moment of execution. There's a time gap between the completion of the detection and the actual commit, during which other concurrent transactions might preemptively acquire the same value. Therefore, conflict detection alone cannot eliminate value conflicts with concurrent transactions. To address this, after a successful detection, the relevant component needs to reserve the unique value written to the data, ensuring that this value is reserved for this transaction before the actual commit, preventing other concurrent transactions from acquiring it.

[0088] Step S302: If all necessary sub-call branches have returned a closed ready response and each role component has passed the commit check, control each role component to return a closed ready response to its corresponding parent component, and receive the closed ready responses that converge to the root component level by level.

[0089] It should be noted that after receiving a close request, the role component pauses new data writing related to the current transaction, waits for all ongoing data writing operations to complete, and then performs conflict detection based on the data already written to the database, overlaying the final changes in the root transaction's working area. If the detection passes, it reserves the values ​​or resources in the written data that are required to be unique, and this reservation continues until the transaction is officially committed or the current close fails. After both the check and reservation are completed, the role component returns a close-ready response to the corresponding parent component. If only a value is found to be currently unused but not reserved, the role component is considered to have failed the commit check.

[0090] It's important to note that scheduling conflict checking and value retrieval before sending the confirmation message is to ensure the determinism of commits by each component during the confirmation phase. After the confirmation message is sent, each component will execute its local commit sequentially, with no rollback. If a value conflict is discovered only during commit, the commit will fail, and other components that have already committed cannot roll back, resulting in an inconsistent state where some components commit successfully while others fail. By eliminating value conflicts before sending the confirmation message, as long as all necessary sub-call branches of each component pass the commit check and return a closed-ready response, the local commits of each component during the confirmation phase can be successfully completed.

[0091] Step S303: If any role component returns a closure failure response or fails to return a closure ready response within a preset time, a release request is sent to the role component that has returned a closure ready response, and each role component participating in the transaction operation request is instructed to clear the root transaction work area that has not yet been committed. The release request is used to instruct the role component that has returned a closure ready response to release the resources occupied in the process of responding to the closure request.

[0092] It should be noted that the preset duration refers to the maximum waiting time from the moment the root component completes sending the close request step by step along each calling branch until the corresponding role component returns a close-ready response or a close-failure response. For example, the preset duration can be configured in the range of seconds to minutes, such as 1 second to 60 seconds, and the value should be determined according to the deployment environment: a smaller value is used when components are deployed within the same local area network, and a larger value is used when deployed across data centers or wide area networks. The preset duration is set based on the fact that it should cover the normal time required for the role component to pause new data writing, wait for in-transit writes to finish, perform commit checks and occupy the value, and return a close-ready response step by step along the line. The relationship between the preset duration and the transaction convergence process is as follows: if the value is too small, role components with network jitter or slightly slower processing will be judged as not ready and will need multiple retries to enter the confirmation phase; if the value is too large, the probability of entering the confirmation phase in a single round increases, but the time the role component occupies the value is extended, which may increase the blocking of other concurrent transactions. Understandably, the preset duration should be set based on the actual duration and scale of the tasks processed by each component.

[0093] It should be noted that if any role component fails the commit check and returns a close failure response, or fails to complete the check and occupancy within the preset time and returns a close ready response, this transaction does not form a formal close decision and does not send a confirmation message, nor does it enter the subsequent formal commit stage, remaining in a state where it can be terminated or retried. The root component sends a release request to the role component that has returned a close ready response and instructs each role component participating in this transaction to clear the uncommitted root transaction work area; the ready role components release the occupied values ​​accordingly, and the released values ​​can be used by other concurrent transactions, avoiding the blocking of other transactions by ready role components occupying values. The root component also instructs each role component participating in the transaction operation request to clear the uncommitted root transaction work area, that is, to clear the intermediate results and transient dispatch business graph temporarily saved before confirmation; since no formal business data has been written before confirmation, this clearing does not involve the rollback of committed data.

[0094] It should be noted that the close request phase does not write any formal database records, does not put the database in a state of waiting for commit, and does not hold database locks for a long time. The formal commit is still completed by each role component in its own local transaction after receiving the confirmation message. Therefore, the close request mechanism is different from the database pre-commit in two-phase commit and belongs to the pre-check before commit.

[0095] In this implementation, by driving each role component to complete the submission check and value retrieval before submission through the closure request, the confirmation message sending and submission stage only begins after all role components have returned a closure ready response. Furthermore, if any role component fails or times out, the ready components are notified to release the reserved values. This advances the exposure of value conflicts to before the confirmation message is sent, ensuring that the local submission of each role component can be successfully completed during the confirmation stage. This avoids the inconsistent state where some role components submit successfully while others fail.

[0096] Example 3 Based on the first embodiment of this application, in the third embodiment of this application, the contents that are the same as or similar to those in the first and second embodiments described above can be referred to the above description and will not be repeated hereafter.

[0097] In one feasible implementation, step S40, which involves determining and submitting the task processing result of the root component, includes: Step S401: Generate a record to be sent for confirmation messages to each role component in the deduplication list.

[0098] It should be noted that the record to be sent is a record pre-built by the root component for sending confirmation messages. Its content corresponds to the confirmation message for the corresponding role component, and each role component corresponds to one record to be sent. The record to be sent has not yet been written to the database when it is generated. In step S402, the record to be sent and the task processing result of the root component are written to the local database of the root component in the same local database transaction. After the local database transaction is committed, the record to be sent becomes a confirmation message record that has been written to the database and is waiting to be sent. The root component sends the confirmation message based on this record. Even if a failure occurs during the sending process, the root component can continue to send based on the written record to be sent after restarting, so that the sending of the confirmation message has a persistent basis. Under the same transaction operation request, when sending the confirmation message of the same role component repeatedly, the same record to be sent is reused, and a new record is not generated repeatedly.

[0099] For example, each record to be sent corresponds to a target role component, recording the target role component's identity, transaction identifier, message type (enumeration value, such as acknowledgment message, cleanup message), message content or a reference to message content, sending status (enumeration value, such as pending, sent, acknowledged), and sending count (integer). When the message content is long, only the reference is saved to avoid duplicate space occupation; the sending status and sending count allow the root component to directly see which messages have not yet been delivered and which have been delivered but have not yet received an acknowledgment after restarting.

[0100] Step S402: In a local database transaction, the task processing result of the root component and the record to be sent are jointly submitted to the local database of the root component.

[0101] It should be noted that the task processing results of the root component and the records to be sent are written together in the same local database transaction. That is, the business results of the root component are written at the same time as the confirmation message is written; either both are written successfully, or neither is written. The processing status of the root component locally is set to committed when the local transaction is committed.

[0102] It should be noted that, in one feasible implementation, the root component completes persistence in the following order: first, write recovery data; then, commit the business logic; and finally, add a completion marker. First, a preparation record is written to the recovery log and flushed to disk. The recovery log is an exemplary method for saving recovery data, which refers to the persistent information required for fault recovery, including the original request content, request summary, transaction identifier, and initial return value. The preparation record indicates that the recovery data has been written but the business logic has not yet been committed. Then, the task processing results and pending records of the root component are jointly committed within the same local database transaction. After the local transaction succeeds, an effectiveness marker is appended to the recovery log, indicating that the business logic commit has been completed. By following the above sequence, if a crash occurs at any stage, the write status of the preparation record and the activation mark in the recovery log, as well as whether the local database transaction has been committed, can be used to determine whether the business has been committed: If the crash occurs before the local transaction is committed, and only the preparation record exists after restarting but the business has not been committed, the preparation record is identified as an ineffective orphan record and its cleanup is delayed; if the crash occurs after the local transaction is committed but before the activation mark is written, after restarting, the recovery data is verified based on the record identifier and summary saved in the committed records in the local database. If a match is found, the activation mark is written, and the business is not recommitted. By coordinating the recovery data, business commitment, and activation mark, the window of duplicate commits and missing recovery data caused by the crash is closed.

[0103] In this implementation, by submitting the task processing results of the root component and the record to be sent of the confirmation message together in the same local database transaction, and by coordinating the order of flushing the recovery data to disk first and then appending the effective flag, the landing of the root component's own business results and the formation of the basis for sending the confirmation message are atomically consistent. This closes the fault window of the root component having been committed but the confirmation message not being formed, as well as the lack of recovery data after a crash, and provides a persistent foundation for the reliable delivery of the confirmation message.

[0104] In one feasible implementation, refer to Figure 3 , Figure 3 This is a flowchart illustrating the transaction request processing method of this application in Embodiment 3. Step S60, which involves triggering the parent call recovery process of each role component based on the ordered call instance tree, includes: Step S611: Determine all calling nodes of the role component and the parent component corresponding to each calling node in the ordered calling instance tree.

[0105] It should be noted that the role component that returns a context loss indication and needs to be restored will be referred to as the target role component. The target role component may correspond to multiple call nodes in the ordered call instance tree, with each call node corresponding to a direct parent component. Each call node and its corresponding parent component constitute a parent call branch of the target role component. The parent components corresponding to all call nodes constitute all necessary parent call branches of the target role component, and each parent call branch is a necessary branch. For example, if the call tree contains branches from the root component to role component A and then to target role component C, and also from the root component to role component B and then to target role component C, then the parent components corresponding to all call nodes of target role component C include role component A and role component B, i.e., two parent call branches. If a parent call branch is missing, it needs to be restored separately; the restoration of other parent call branches cannot replace this.

[0106] Step S612: For each calling node, a recovery instruction is sent to the parent component corresponding to each calling node. The recovery instruction is used to instruct the parent component to initiate a recovery call to the role component according to the original calling parameters saved by the parent component, and to provide the role component with the first return value saved by the parent component as the return result of the recovery call. The first return value is the result recorded and saved by the parent component when it first calls the role component.

[0107] It should be noted that the recovery call reuses the original parameters and return value from the initial call, and does not read the current business values ​​that may have changed, ensuring that the intermediate processing state after recovery remains consistent with the initial call. In one feasible implementation, each parent call branch can be recovered in parallel, the target role component continues to use the original transaction identifier, and the intermediate results after recovery are merged into the original root transaction work area without creating a second work area.

[0108] It's important to note that the purpose of a recovery call is to resend the missing input data to the target component. If the target component loses its intermediate processing state, simply resending confirmation messages will not enable it to complete the commit, because the target component no longer knows the parameters passed to previous calls within the current transaction or the return results of those calls, making it impossible to reconstruct the data to be written for this transaction. A recovery call, initiated by the parent component based on the saved original call parameters, effectively resends the input data carried in the original call, allowing the target component to regain access to the input data from each parent call branch, thereby reconstructing the data to be written in the root transaction workspace.

[0109] It should be noted that the recovery data saved by the parent component may also be lost due to reasons such as the parent component restarting itself. In this case, the parent component cannot provide the original parameters and initial return value required for the recovery call. It can only search upwards along the parent call node in the call tree, and the recovery is completed level by level by the higher-level caller that has saved the recovery data. The parameters and return results carried by each parent call branch are different. If the input facts of a certain parent call branch are missing, the recovery of other parent call branches cannot replace them, and replacement will lose the input information unique to that parent call branch. During the recovery process, intermediate components that have completed the commit in the call tree will no longer execute business commits, but only provide their saved initial results and necessary recovery data to avoid duplicate commits or duplicate external side effects during the recovery process.

[0110] Step S613: After all parent components corresponding to all calling nodes of the role component have completed the recovery call, send confirmation messages to the role component repeatedly.

[0111] It should be noted that a confirmation message can only be resent to the target role component when all necessary parent call branches have been restored, i.e., when the branch completeness condition is met. The target role component then performs a local commit based on the restored intermediate processing state.

[0112] In this implementation, by determining all call nodes and corresponding parent components of the target role component from the ordered call instance tree, restoring each parent call branch according to the initial call parameters and initial return value, and resending the confirmation message after all parent call branches have been restored, the problem of incomplete intermediate processing state caused by restoring only some parent call branches is avoided, enabling the target role component to complete the submission based on the complete context after restoration.

[0113] In one feasible implementation, step S70, which involves determining the completion status and the processing method for the completion status based on the completion receipt and the deduplication list, includes: Step S701: If no response to the confirmation message is received from the role component, send the confirmation message carrying the same transaction identifier to the role component again; if the role component already has a completion receipt corresponding to the transaction identifier, return the completion receipt without resubmitting the task processing result.

[0114] It should be noted that the resent confirmation message carries the same transaction identifier as the previously sent confirmation message, enabling the role component to identify that the confirmation message is a further advance instruction of the same transaction, rather than an instruction for a new transaction. The allocation and reuse of the transaction identifier can be found in the explanation of step S10. No response received indicates that the role component may be offline, the network may be interrupted, or the response may be lost. In this case, only the confirmation message is resent; the lack of response is not inferred as context loss.

[0115] It should be noted that after receiving a repeatedly sent confirmation message, the role component first checks whether there is already a completion receipt corresponding to the transaction identifier locally: if there is a completion receipt, it directly returns the completion receipt and does not repeat the local commit; if there is no completion receipt and the root transaction work area exists, the role component does not wait for other role components and directly executes the local commit; if there is no completion receipt and the root transaction work area does not exist, it means that the intermediate processing state of the role component has been lost, the role component returns a context loss indication, and the root component triggers the parent call recovery process according to the ordered call instance tree.

[0116] Step S702: If all role components in the deduplication list have returned completion receipts, the transaction operation request is confirmed to be completed.

[0117] It should be noted that the completion receipt is an acknowledgment returned by the role component after submitting the task processing result. The completion receipt and the task processing result are committed in the same local database transaction. The root component tracks the completion receipts of each role component based on the deduplication list, and determines the completion status of the transaction operation request accordingly: when all role components in the deduplication list have returned completion receipts, the completion status is determined to be overall completion; when there are role components that have not returned completion receipts, the completion status remains "converging".

[0118] It should be noted that the handling methods for the two completion states mentioned above are different. When the completion state is "overall completion", the root component saves the overall completion certificate, which is used to indicate that all role components have completed the commit; the root component sends a cleanup message to each role component, and after the role component verifies it, a cleanup mark is appended, and repeated cleanup maintains idempotency; the background compression program reclaims the log segments corresponding to the cleaned records in an atomic replacement manner; the completion receipt and the overall completion certificate are retained for auditing. When the completion state is "converging", the root component continuously resends confirmation messages carrying the same transaction identifier to role components that have not returned a completion receipt until all role components return a completion receipt. The handling method after the resending reaches the preset limit can be found in the description of step S70.

[0119] It should be noted that the processing of transaction operation requests can be described by states: processing, pre-commit check, confirmation, convergence, overall completion, as well as the open state returned after a pre-commit check failure, and the blocked state entered when completion cannot be completed for a long time. Processing indicates that the call operation is being executed and the task processing results are being summarized; pre-commit check indicates that close requests have been sent level by level along each call branch, waiting for each role component to return a close-ready response; confirmation indicates that the root component has completed the commit of its own task processing results, returned a success result to the initiator, and started sending confirmation messages; convergence indicates that the commit and recovery of incomplete role components are being continuously promoted; overall completion indicates that all role components have returned completion receipts; when a pre-commit check fails, the transaction returns to the open state, in a state where it can be re-initiated or canceled; when completion receipts cannot be completed for a long time, or recovery data cannot be obtained, it enters the blocked state.

[0120] In one feasible implementation, after the root component restarts, it determines the role component that has not returned a completion receipt based on the deduplication list and the received completion receipts, and resends an acknowledgment message carrying the same transaction identifier to the role component that has not returned a completion receipt; when the role component returns a completion receipt, the processing of that role component ends; when the role component returns a context loss indication again, the parent call recovery is performed.

[0121] In this implementation, by distinguishing between no response and context loss, in the case of no response, only a confirmation message carrying the same transaction identifier is repeatedly sent. Role components with corresponding completion receipts directly return completion receipts. After all role components return completion receipts, the overall completion is confirmed. After the root component restarts, a confirmation message is resent to probe, so that response loss and component restart will not lead to duplicate submissions. The incomplete parts can continue to be processed until they are completed, realizing the responsibility of continuous follow-up after confirmation.

[0122] In one feasible implementation, the process of performing the invocation operation in step S10 also includes the registration and generation of asynchronous business logic: It should be noted that a derived transaction intent refers to the registration information of asynchronous business operations that a role component determines needs to execute during processing, which are related to the current transaction operation request but do not affect the current processing result. When the business corresponding to the called operation can determine the processing conclusion without waiting for the remote result, the derived transaction intent is registered in the root transaction workspace of the corresponding role component. Before confirmation, no sub-transaction number or sending record is assigned to the derived transaction intent, nor is a network request initiated. When the transaction is canceled before confirmation, the derived transaction intent is cleared along with the root transaction workspace. When the role component submits the task processing result locally, the derived transaction intent is written to the database along with the task processing result, generating an independent sub-transaction. The independent sub-transaction is executed and followed up independently, and the parent transaction does not wait for its remote processing result. In one feasible implementation, for external operations that cannot be undone (such as controlling the device to perform actions), a unique key-value pair is used to ensure that the same operation is executed only once. Execution is triggered only after the business is submitted, and receiving confirmation messages repeatedly will not trigger the external operation again.

[0123] In this implementation, by registering the derived transaction intent only before confirmation and generating an independent sub-transaction together when committing locally, the isolation of the sub-transaction after the parent transaction is cancelled is avoided, as is the unnecessary network request initiated before confirmation.

[0124] In one feasible implementation, the technical solution of this application can be flexibly selected at the implementation level: the root transaction work area can be located in process memory, shared memory, or controlled volatile storage; the role component can be a cloud service, edge service, industrial terminal, or controlled desktop application; concurrent confirmation can be implemented through message bus, HTTP (HyperTextTransfer Protocol), long connection, or reliable task queue; the completion progress can be represented by bitmap, status table, or event sequence; the recovery data can be implemented using controlled append-only file log or sequential persistent media, and the method of writing recovery data first, then submitting business, and then adding completion markers and restarting repair is suitable for different storage media.

[0125] In this embodiment, by providing multiple alternative implementations of the root transaction workspace, role components, concurrent confirmation, completion progress, and recovery data, the technical solution of this application can be adapted to different deployment environments and storage media, expanding the scope of application of the technical solution without changing the core technical solution of pre-commit checks, deduplication lists and call tree dual views, root component atomic commits, and continuous progress.

[0126] It should be noted that the technical features in the above embodiments can be arbitrarily combined according to actual needs. As long as the combined technical solutions do not contradict each other, they all fall within the protection scope of this application. For example, the circular call constraint in Embodiment 2 can be combined with the parent call recovery mechanism in Embodiment 3—each call in the circular call is recorded as a call node in an ordered call instance tree. When the context of the target role component is lost, all parent branches are located based on all call nodes in the tree for recovery; the conflict detection in the close request gate can be coordinated with the root component submission mechanism. After all role components return a close ready response, the root component atomically submits its own task processing result and the record to be sent. This application does not specifically limit the combination method between the various embodiments.

[0127] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the transaction request processing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0128] This application also provides a transaction request processing apparatus, please refer to... Figure 4 The transaction request processing device includes: The instance tree generation module 10 is used to respond to transaction operation requests, execute the call operation corresponding to the transaction operation request through the root component of the transaction operation request, record the call operation of each role component during the execution of the call operation to form an ordered call instance tree, and receive the task processing results returned by each role component. The deduplication list generation module 20 is used to determine the deduplication list based on the ordered call instance tree when all role components have returned the task processing results. The deduplication list contains the identity information of each role component. The shutdown response module 30 is used to send shutdown requests to each role component level by level along each call branch of the ordered call instance tree, and to receive shutdown ready responses from each role component. The result submission module 40 is used to determine the confirmation message based on the deduplication list and to determine and submit the task processing result of the root component after all role components have returned a closed and ready response. The confirmation message sending module 50 is used to first return a success result to the initiator of the transaction operation request after the task processing result of the root component is successfully submitted, and then send a confirmation message to each role component based on the deduplication list. The confirmation message is used to instruct each role component to submit the corresponding task processing result. Call recovery module 60, which is used to trigger the parent call recovery process of each role component according to the ordered call instance tree when a context loss indication is received from each role component; The status determination module 70 is used to receive the completion receipts returned by each role component, and determine the completion status of the transaction operation request and the processing method of the completion status based on the completion receipts and deduplication list returned by each role component. The completion receipt is the receipt returned by the role component after submitting the task processing result.

[0129] The transaction request processing apparatus provided in this application, employing the transaction request processing method in the above embodiments, can solve the technical problem of reducing the processing efficiency reduction caused by repeated commits, loop waiting, intermediate state exposure, and partial component offline, restart, or response loss in a distributed system. Compared with the prior art, the beneficial effects of the transaction request processing apparatus provided in this application are the same as those of the transaction request processing method provided in the above embodiments, and other technical features in the transaction request processing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0130] This application provides a transaction request processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the transaction request processing method in the above embodiment 1.

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

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

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

[0134] The transaction request processing device provided in this application, employing the transaction request processing method in the above embodiments, can solve the technical problem of reducing the processing efficiency reduction caused by repeated submissions, loop waiting, intermediate state exposure, and partial component offline, restart, or response loss in a distributed system. Compared with the prior art, the beneficial effects of the transaction request processing device provided in this application are the same as those of the transaction request processing method provided in the above embodiments, and other technical features in this transaction request processing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0137] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the transaction request processing method in the above embodiments.

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

[0139] The aforementioned computer-readable storage medium may be included in the transaction request processing device; or it may exist independently and not assembled into the transaction request processing device.

[0140] The aforementioned computer-readable storage medium carries one or more programs that, when executed by the transaction request processing device, cause the transaction request processing device to: In response to a transaction operation request, the root component of the transaction operation request executes the call operation corresponding to the transaction operation request. During the execution of the call operation, the call operations of each role component are recorded to form an ordered call instance tree, and the task processing results returned by each role component are received. With all role components having returned task processing results, a deduplication list is determined based on the ordered call instance tree. The deduplication list contains the identity information of each role component. Along each call branch of the ordered call instance tree, the close request is sent to each role component level by level, and the close ready response is received from each role component. Once all role components have returned a closed and ready response, determine the confirmation message based on the deduplication list, and determine and submit the task processing result of the root component. After the root component successfully submits the task processing result, it first returns a success result to the initiator of the transaction operation request, and then sends a confirmation message to each role component based on the deduplication list. The confirmation message is used to instruct each role component to submit the corresponding task processing result. Upon receiving context loss indications from each role component, the parent call recovery process of each role component is triggered according to the ordered call instance tree; Receive completion receipts from each role component, and determine the completion status of the transaction operation request and the processing method for the completion status based on the completion receipts and deduplication list returned by each role component. The completion receipt is the receipt returned by the role component after submitting the task processing result.

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

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

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

[0144] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described transaction request processing method. This solves the technical problem of reducing processing efficiency in distributed systems caused by repeated commits, circular waits, exposure of intermediate states, and offline, restarted, or lost responses of some components during cross-component business operations. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the transaction request processing method provided in the above embodiments, and will not be repeated here.

[0145] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the transaction request processing method described above.

[0146] The computer program product provided in this application solves the technical problem of reducing processing efficiency in distributed systems caused by repeated submissions, loop waiting, exposure of intermediate states, and offline, restarted, or lost responses of some components during cross-component business operations. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the transaction request processing method provided in the above embodiments, and will not be repeated here.

[0147] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A transaction request processing method, characterized in that, The method includes: In response to a transaction operation request, the root component of the transaction operation request executes the call operation corresponding to the transaction operation request. During the execution of the call operation, the call operations of each role component are recorded to form an ordered call instance tree, and the task processing results returned by each role component are received. If all the role components have returned the task processing results, a deduplication list is determined based on the ordered call instance tree, and the deduplication list contains the identity information of each role component. Along each call branch of the ordered call instance tree, the close request is sent to each of the role components level by level, and the close ready response is received from each of the role components; If all the aforementioned role components have returned the closed ready response, a confirmation message is determined based on the deduplication list, and the task processing result of the root component is determined and submitted. After the root component successfully submits the task processing result, it first returns a success result to the initiator of the transaction operation request, and then sends a confirmation message to each of the role components based on the deduplication list. The confirmation message is used to instruct each role component to submit the corresponding task processing result. Upon receiving a context loss indication from each of the aforementioned role components, the parent call recovery process of each of the aforementioned role components is triggered according to the ordered call instance tree; The system receives completion receipts returned by each role component, and determines the completion status of the transaction operation request and the processing method of the completion status based on the completion receipts returned by each role component and the deduplication list. The completion receipt is the receipt returned by the role component after submitting the task processing result.

2. The method as described in claim 1, characterized in that, The step of sending the close request level by level to each of the role components along each call branch of the ordered call instance tree, and receiving the close ready response from each of the role components, includes: Along each call branch of the ordered call instance tree, a close request is sent to each of the role components level by level. The close request is used to instruct each role component to perform a commit check on the task processing result after all the necessary sub-call branches of the role component have returned a close ready response. The commit check includes conflict detection of the write data corresponding to each role component. If all necessary sub-call branches have returned the closed ready response and each role component has passed the commit detection, control each role component to return the closed ready response to the parent component corresponding to each role component, and receive the closed ready response that is aggregated to the root component level by level; If any of the aforementioned role components returns a close failure response or fails to return a close ready response within a preset time period, a release request is sent to the role component that has returned the close ready response, and each role component participating in the transaction operation request is instructed to clear the root transaction work area that has not yet been committed. The release request is used to instruct the role component that has returned the close ready response to release the resources occupied in the process of responding to the close request.

3. The method as described in claim 1, characterized in that, The step of executing the call operation corresponding to the transaction operation request through the root component of the transaction operation request and receiving the task processing results returned by each of the role components includes: When any role component is invoked for the first time, a corresponding root transaction workspace is established for that role component; The intermediate results generated by the role component during the processing of the call operation are temporarily stored in the root transaction work area; When the role component completes the processing of the call operation, the task processing result returned by the role component is received, and the task processing result is determined based on the intermediate result.

4. The method as described in claim 3, characterized in that, The step of recording the call operations of each role component to form an ordered call instance tree includes: Upon detecting a call operation from each of the aforementioned role components, a call node is created for the call operation, and the parent call relationship corresponding to the call operation is recorded in the call node; The result of the invoked role component is stored in the root transaction work area corresponding to the invoked role component; In the case of a circular call between the role components, a circular iteration number is recorded for the circular call, and the circular call is terminated when the circular call reaches at least one of the following conditions: termination condition, maximum expansion depth, maximum number of iterations, or timeout gate. The calling nodes are arranged according to the order in which the calling operations are initiated, forming the ordered calling instance tree.

5. The method as described in claim 1, characterized in that, The step of determining the deduplication list based on the ordered call instance tree, after all the role components have returned the task processing results, includes: Stop updating the ordered call instance tree; Extract the identity information of each role component from the ordered call instance tree, and deduplicate the extracted identity information; The deduplication list is determined based on the deduplicated identity information of the character components.

6. The method as described in claim 1, characterized in that, The steps of determining the completion status of the transaction operation request and the processing method for the completion status based on the completion receipts returned by each role component and the deduplication list include: If no response to the confirmation message is received from the role component, the confirmation message carrying the same transaction identifier is sent to the role component repeatedly; if the role component already has a completion receipt corresponding to the transaction identifier, the completion receipt is returned without resubmitting the task processing result. Once all the role components in the deduplication list have returned the completion receipt, the transaction operation request is determined to be completed.

7. The method as described in claim 1, characterized in that, The step of triggering the parent call recovery process of each role component according to the ordered call instance tree includes: In the ordered call instance tree, determine all the call nodes of the role component, and the parent component corresponding to each call node; For each of the aforementioned calling nodes, a recovery instruction is sent to the parent component corresponding to each of the aforementioned calling nodes. The recovery instruction is used to instruct the parent component to initiate a recovery call to the role component according to the original calling parameters saved by the parent component, and to provide the role component with the first return value saved by the parent component as the return result of the recovery call. The first return value is the result recorded and saved by the parent component when it first calls the role component. If all parent components corresponding to the calling nodes of the role component have completed the recovery call, the confirmation message is sent repeatedly to the role component.

8. The method as described in claim 1, characterized in that, The steps of determining and submitting the task processing results of the root component include: Generate a record of confirmation messages to be sent for each of the role components in the deduplication list; In a local database transaction, the task processing result of the root component and the record to be sent are jointly submitted to the local database of the root component.

9. A transaction request processing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the transaction request processing method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the transaction request processing method as described in any one of claims 1 to 8.

Images