Transaction context online merging method and device for distributed transactions

Abstract

Embodiments of the present specification provide a transaction context online merging method and device for distributed transactions. The method comprises: in response to a preset event indicating that the ownership of target data is changed from a source participant to a target participant, obtaining a classification result of a source transaction context related to the target data held by the source participant, the classification result indicating categories to which respective fields in the source transaction context belong in a plurality of categories, the plurality of categories including a data operation state category and a protocol participation state category, fields of the data operation state category being used to support local data rollback, and fields of the protocol participation state category being used to indicate execution related information of a distributed transaction commit protocol; reading first category fields of the data operation state category from the source transaction context; merging the first category fields into a target transaction context of the target participant; and determining a protocol participation state of the target transaction context based on protocol facts that have been persisted locally by the target participant.

Description

Technical Field

[0001] This specification relates to the field of database technology, and more particularly to a method and apparatus for online merging of transaction contexts in distributed transactions. Background Technology

[0002] In distributed database systems, to support horizontal scaling, load balancing, failover, and elastic scaling, the system needs to frequently perform shard reassembly, data migration, and log stream adjustments. During these physical topology changes, the transaction contexts of active transactions that were originally running on the source node (or source log stream) often need to be migrated or merged to the target node.

[0003] As database clusters grow in size, online migration of data shards (without interrupting business operations) becomes a critical requirement. During migration, it is essential to ensure that running distributed transactions are not forcibly terminated (i.e., achieving "online merging"). However, online merging of distributed transactions faces several challenges and difficulties. It is challenging to simultaneously guarantee the integrity of local data rollback and the recoverability of protocol participant states during online merging within a distributed transaction context. Improved solutions are needed to address these issues. Summary of the Invention

[0004] This specification describes one or more embodiments of a method and apparatus for online merging of transaction contexts in distributed transactions. This method and apparatus can simultaneously ensure data rollback integrity and protocol state recoverability during online migration or merging of distributed transactions, reducing transaction interruptions and improving the availability and security of distributed systems.

[0005] According to the first aspect, an online method for merging transaction contexts in distributed transactions is provided, including:

[0006] In response to a preset event indicating a change in ownership of target data from the source participant to the target participant, the classification result of the source transaction context related to the target data held by the source participant is obtained. The classification result indicates the category to which each field in the source transaction context belongs among multiple categories. The multiple categories include data operation status category and protocol participation status category. The fields of the data operation status category are used to support local data rollback, and the fields of the protocol participation status category are used to indicate execution-related information of the distributed transaction commit protocol.

[0007] Read the first type of field of the data operation status category from the source transaction context;

[0008] Merge the first type of fields into the target participant's target transaction context;

[0009] Based on the fact that the target participant has persisted the protocol locally, the protocol participation status of the target transaction context is determined.

[0010] According to the second aspect, an online transaction context merging apparatus for distributed transactions is provided, comprising:

[0011] The acquisition module is used to, in response to a preset event indicating a change in the ownership of target data from the source participant to the target participant, acquire the classification result of the source transaction context related to the target data held by the source participant. The classification result indicates the category to which each field in the source transaction context belongs among multiple categories. The multiple categories include data operation status category and protocol participation status category. The fields of the data operation status category are used to support local data rollback, and the fields of the protocol participation status category are used to indicate the execution information related to the distributed transaction commit protocol.

[0012] A reading module is used to read a first type of field of the data operation status category from the source transaction context;

[0013] The merge module is used to merge the first type of fields into the target transaction context of the target participant;

[0014] The determination module is used to determine the protocol participation status of the target transaction context based on the protocol facts that have been persisted locally by the target participant.

[0015] According to a third aspect, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0016] According to a fourth aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0017] According to a fifth aspect, a computing device is provided, including a memory and a processor, wherein executable code is stored in the memory, and the processor, when executing the executable code, implements the method of the first aspect.

[0018] In the embodiments of this specification, fields in the source transaction context are categorized, and only data operation status category fields used to support local data rollback are merged into the target transaction context based on the categorization results. Simultaneously, the protocol participation status of the target transaction context is not directly inherited from the source transaction context, but is determined based on the locally persisted protocol facts of the target participant. This ensures, on the one hand, that the target participant obtains the data operation status required to support data rollback, avoiding the loss of rollback capabilities due to transaction context migration; on the other hand, it prevents the target participant from incorrectly inheriting the protocol status of the source participant, ensuring that the protocol participation status is consistent with the actual local protocol facts of the target participant, thus improving the reliability of protocol advancement and crash recovery. This scheme can simultaneously guarantee data rollback integrity and protocol status recoverability during online migration or merging of distributed transactions, reducing transaction interruptions and improving the availability and security of distributed systems. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This diagram illustrates an application scenario of an online transaction context merging method for distributed transactions provided in an embodiment of this specification.

[0021] Figure 2 A flowchart illustrating the online transaction context merging method for distributed transactions provided in the embodiments of this specification;

[0022] Figure 3 This diagram illustrates how the classification engine classifies any field i in the source transaction context;

[0023] Figure 4 A schematic diagram of the structure of an online transaction context merging apparatus for distributed transactions according to one embodiment is shown. Detailed Implementation

[0024] To facilitate understanding of the solutions provided in the embodiments of this specification, a brief introduction will first be given to the technical terms that may be involved in the embodiments of this specification.

[0025] Distributed Transaction: A database transaction that spans multiple nodes or data shards, relying on atomic commit protocols such as two-phase commit to ensure atomicity and consistency across nodes.

[0026] Transaction Participant: A logical unit in a distributed transaction that holds a portion of the transaction data and participates in the two-phase commit protocol. It can correspond to a physical node, log stream, sharded replica, or data source.

[0027] Transaction Context: A set of execution information maintained by a transaction on a particular participant, including at least the records of operations performed by the transaction on the data, and the protocol progress information of the transaction on that participant.

[0028] Data Operation State: In the transaction context, this represents the state of the data that a transaction operates on. It is used to support undo, lock release, data visibility determination, data reclamation boundary calculation, or operation history overwrite determination.

[0029] Protocol Participant State: In the context of a transaction, this indicates or constrains the state of a participant in the two-phase commit protocol, their protocol role, or their commitment to external protocols.

[0030] Source Participant: Dedicated to P_src, it holds the source transaction context and can be denoted as ctx_src.

[0031] Destination Participant: Dedicated to P_dst, it serves as the destination of the merge and holds the target transaction context, which can be denoted as ctx_dst.

[0032] Idempotent Merge: Repeated merging will not result in duplicate undo, duplicate lock release, or erroneous protocol advancement.

[0033] Online Transaction Context Merging: Merging transaction contexts from different participants into the target transaction context before a distributed transaction has reached its final state, without forcibly terminating the transaction during the merging process.

[0034] In distributed database systems, to support horizontal scaling, load balancing, failover, and elastic scaling, the system needs to frequently perform shard reassembly, data migration, and log stream adjustments. During these physical topology changes, the transaction contexts of active transactions that were originally running on the source participant often need to be migrated or merged onto the target participant.

[0035] In related technologies, the migration of transaction contexts is usually achieved by methods such as full merging, unilateral discarding, or forced termination of active transactions.

[0036] The full merge method migrates all fields from the source transaction context to the target transaction context, including data operation status fields and protocol participation status fields. However, protocol participation status is usually strongly correlated with the actual protocol facts formed locally by the participant. If the target participant inherits the protocol status of the source participant without experiencing the corresponding protocol stage, the protocol status cannot be correctly reconstructed during crash recovery, which can easily lead to abnormal protocol progress.

[0037] While the one-sided discard method is simple to implement, it can lead to the loss of data operation state on the source participant, thereby affecting the integrity of local data rollback.

[0038] Forcibly terminating active transactions would disrupt business continuity and fail to meet online migration requirements.

[0039] Furthermore, hard-coded classification methods based on field names, storage locations, or fixed log formats lack universality, are difficult to adapt to changes in transaction context structures, and cannot reliably distinguish the functional semantics of different fields in distributed transactions.

[0040] It is evident that the relevant technologies struggle to simultaneously guarantee the integrity of local data rollback and the recoverability of protocol participation states during the online merging process of distributed transaction contexts.

[0041] In view of this, embodiments of this specification provide an online method for merging transaction contexts in distributed transactions. This method categorizes fields in the source transaction context and, based on the categorization results, merges only the data operation state category fields used to support local data rollback into the target transaction context. Simultaneously, it does not directly inherit the protocol participation state from the source transaction context, but determines the protocol participation state of the target transaction context based on the protocol facts already persisted locally by the target participant. Therefore, on the one hand, it ensures that the target participant obtains the data operation state required to support data rollback, avoiding the loss of rollback capabilities due to transaction context migration; on the other hand, it avoids the target participant incorrectly inheriting the protocol state of the source participant, ensuring that the protocol participation state is consistent with the actual local protocol facts of the target participant, improving the reliability of protocol advancement and crash recovery. This scheme can simultaneously guarantee data rollback integrity and protocol state recoverability during online migration or merging of distributed transactions, reducing transaction interruptions and improving the availability and security of distributed systems.

[0042] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0043] Figure 1This diagram illustrates an application scenario of an online transaction context merging method for distributed transactions provided in an embodiment of this specification. For example... Figure 1 As shown, client 100 sends a transaction access request to the distributed database system 200, and the distributed database system 200 responds to the transaction request by initiating a distributed transaction T1 through a coordinator. The participants in distributed transaction T1 include participant 1, participant 2, and participant 3. The coordinator can interact with participant 1, participant 2, and participant 3 respectively, directing each participant to collaboratively complete the distributed transaction.

[0044] For example, the coordinator directs participant 1 to perform transaction operation A on local data shard S1, participant 2 to perform transaction operation B on local data shard S2, and participant 3 to perform transaction operation C on local data shard S3. Transaction operations A, B, and C can be referred to as sub-transactions or local transactions of the distributed transaction, respectively.

[0045] To ensure the successful execution of distributed transaction T1, each participant maintains a transaction context for its local sub-transaction. For example, participant 1 maintains a transaction context ctx_1 for its locally executed sub-transaction 1, participant 2 maintains a transaction context ctx_2 for its locally executed sub-transaction 2, and participant 3 maintains a transaction context ctx_3 for its locally executed sub-transaction 3.

[0046] While distributed transaction T1 is still executing, or in other words, while there are active transactions on data shard S1, data shard S1 is migrated online from node A to node B. If only data shard S1 is migrated without its sub-transaction 1 being migrated along with it, sub-transaction 1 will lose the ability to operate on data shard S1, leading to transaction interruption or data inconsistency.

[0047] To ensure uninterrupted business operations, the ongoing distributed transaction T1 must not be forcibly terminated during the migration process. This requires merging the transaction context ctx_1 held by participant 1 into the transaction context ctx_2 held by participant 2 online. The online transaction context merging method provided in this specification can be executed to merge the transaction context ctx_1 held by participant 1 into the transaction context ctx_2 held by participant 2. This method safely completes the online transaction context merging without interrupting the distributed transaction, ensuring the target participant has full data rollback capabilities and preventing the target participant from incorrectly inheriting the protocol participation state of the source participant, thereby improving the reliability and recoverability of the distributed transaction system.

[0048] It should be noted that, Figure 1The scenario shown is merely an example of an application scenario of the online merging method for the transaction context of a distributed transaction provided in the embodiments of this specification, and does not constitute a limitation on the solution of this specification. For example, the solution provided in the embodiments of this specification can also be applied to other scenarios, such as log stream switching, load balancing scheduling, fault switching, elastic scaling, and other scenarios that will lead to changes in physical topology. These scenarios will cause the transaction context of active transactions that were originally running on the source participant to be migrated or merged to the target participant.

[0049] The following describes the detailed implementation process of the online transaction context merging method for distributed transactions provided in the embodiments of this specification.

[0050] Figure 2 This is a flowchart illustrating the online transaction context merging method for distributed transactions provided in the embodiments of this specification. It should be noted that this method can be implemented using any device, equipment, platform, or device cluster with computing and processing capabilities. Figure 2 As shown in the embodiments of this specification, the online transaction context merging method for distributed transactions includes steps S210 to S240.

[0051] In step S210, in response to a preset event indicating a change in ownership of the target data from the source participant to the target participant, the classification result of the source transaction context related to the target data held by the source participant is obtained.

[0052] In distributed database systems (such as OceanBase), events such as shard migration, data migration, log stream adjustment, load balancing, failover, and elastic scaling are often required. These events can lead to changes in physical topology. During these physical topology changes, the transaction context of active transactions that were originally running on the source participant often needs to be migrated or merged to the target participant.

[0053] The events that cause physical topology changes can be configured as preset events. When a preset event occurs, the online merging operation of the transaction context of the distributed transaction is triggered, merging the source transaction context held by the source participant into the target upper and lower files held by the target participant.

[0054] by Figure 1 For example, distributed transaction T1 needs to operate on data shard S1 on node A, data shard S2 on node B, and data shard S3 on node C respectively. If, before distributed transaction T1 reaches its final state, an event occurs where data shard S1 migrates from node A to node B, the online merging operation of the transaction context of the distributed transaction will be triggered. In other words, the online merging method of the transaction context of the distributed transaction provided in the embodiments of this specification will begin execution.

[0055] at this time, Figure 1 Participant 1 can be called the source participant, data shard S1 can be called the target data, transaction context ctx_1 can be called the source transaction context, participant 2 can be called the target participant, and the context ctx_2 maintained on participant 2 is the target transaction context.

[0056] The online transaction context merging method for distributed transactions provided in this specification can be logically divided into two phases: Phase A and Phase B. Phase A involves semantic-level state classification, while Phase B is a separate online merging process. Phase A categorizes the fields in the source transaction context into two types: fields representing data operation states and fields representing protocol participation states. Phase B is responsible for performing the actual merging based on the classification results from Phase A.

[0057] Phase A can be implemented using a classification engine, and Phase B can be implemented using a merging engine. In other words, the online transaction context merging method for distributed transactions provided in the embodiments of this specification can be implemented collaboratively by a classification engine and a merging engine.

[0058] The following section will introduce the specific implementation of the classification engine.

[0059] The classification engine is used in execution phase A to perform semantic-level state classification of the source transaction context. It classifies each field in the source transaction context to obtain the classification result. The classification result indicates the category to which each field in the source transaction context belongs in multiple categories. These multiple categories include data operation status category and protocol participation status category. Fields in the data operation status category are used to support local data rollback, and fields in the protocol participation status category are used to indicate the execution information related to the distributed transaction commit protocol.

[0060] Figure 3 This diagram illustrates how the classification engine classifies any field i in the source transaction context. For example... Figure 3 As shown, when the classification engine performs classification, it first determines whether field i is used to describe the operational effect of a transaction on a data object (this determination operation can be called the first determination operation). If yes, then field i is determined as a data operation status category. If not, it continues to determine whether field i represents or constrains a protocol phase, protocol role, or external protocol commitment (this can be called the second determination operation). If yes, then field i is determined as a protocol participation status category.

[0061] Typical fields for data operation status categories include: Undo information, lock information, data operation location, SCN boundary, committed log sequence number, data reclamation boundary, etc. This information describes the actual impact of the transaction on the data and must be completely preserved; otherwise, subsequent rollback, lock release, visibility judgment, or data reclamation will result in errors.

[0062] Typical fields for protocol participant status categories include fields indicating the preparation phase, commit phase, rollback phase, scheduler node identity, or protocol voting result. These fields describe the roles and commitments of participants in the distributed transaction protocol and cannot be simply inherited from source participants.

[0063] It should be noted that, Figure 3 The order of judgment shown is merely an example and does not constitute a limitation on this solution. In some other examples, the first and second judgment operations can be executed in parallel, or the second judgment operation can be executed first and then the first judgment operation.

[0064] In one example, the classification engine can maintain a metadata registry that records the mapping between fields and metadata descriptors, which are used to indicate the functional semantics of the fields.

[0065] When classifying any field i in the source transaction context, the classification engine can do so through a metadata registry. For example, the classification engine can look up the metadata descriptor corresponding to field i in the metadata registry based on the field name of field i. The functional semantics of field i can be obtained from the found metadata descriptor. Subsequently, a first judgment operation and / or a second judgment operation can be performed based on this functional semantics.

[0066] Because metadata descriptors reflect the functional purpose of a field rather than simply its storage location, the classification results remain usable even if the field's storage location in memory structure, log format, or system table changes, as long as the metadata descriptor remains stable.

[0067] In one example, functional semantics can be a relatively coarse-grained semantic description. For instance, functional semantics might include semantics describing the operational effects of a transaction on a data object and semantics indicating the protocol stage, protocol role, or protocol commitment made by the source participant in the distributed transaction commit protocol. For example, a field named `last_scn_` in the metadata registry might have the functional semantics of describing the operational effects of a transaction on a data object. A field named `state_` might have the functional semantics of indicating the protocol stage, protocol role, or protocol commitment made by the source participant in the distributed transaction commit protocol.

[0068] The result can be obtained by directly searching the metadata registry.

[0069] In another example, functional semantics can also be a more fine-grained semantic description. Taking a distributed transaction protocol using a two-phase commit protocol as an example, functional semantics include: indicating the version number or position of the last data operation of the transaction; indicating the start version number or timestamp boundary of the transaction data operation; indicating the end version number or timestamp boundary of the transaction data operation; indicating the maximum log sequence number of the committed transaction; recording the Undo information generated by the transaction; recording the set of locks held by the transaction; recording the data rows modified by the transaction; used to determine whether the transaction data is visible to other transactions; indicating the data reclamation boundary, used to determine which old versions can be reclaimed; indicating the Redo log position corresponding to the transaction; indicating the Undo log position corresponding to the transaction; indicating the protocol phase of the participant in the two-phase commit; indicating that the participant has entered the Prepare phase; indicating that the participant has committed; identifying the transaction scheduling node or coordinator; indicating whether to use a sub-two-phase commit; indicating the role of the participant in the protocol; indicating the voting results of the participant in the Prepare phase, etc.

[0070] At this point, after obtaining the functional semantics of field i by searching the metadata registry, it is necessary to determine whether the functional semantics belongs to the functional semantics set corresponding to the data operation status category. This functional semantics set is {representing the version number or position of the last data operation of the transaction, representing the start version number or timestamp boundary of the transaction data operation, representing the end version number or timestamp boundary of the transaction data operation, representing the maximum log sequence number committed by the transaction, recording the Undo information generated by the transaction, recording the set of locks held by the transaction, recording the data rows modified by the transaction, used to determine whether the transaction data is visible to other transactions, representing the data reclamation boundary, used to determine which old versions can be reclaimed, representing the Redo log position corresponding to the transaction, and representing the Undo log position corresponding to the transaction}.

[0071] If field i is determined not to belong to the data operation state category, then it is further determined whether the functional semantics corresponding to field i belong to the functional semantics set corresponding to the protocol participation state category. The functional semantics set is {representing the protocol phase of the participant in the two-phase commit, indicating that the participant has entered the Prepare phase, indicating that the participant has committed, identifying the transaction scheduling node or coordinator, indicating whether to use sub-two-phase commit, indicating the role of the participant in the protocol, indicating the voting result of the participant in the Prepare phase}.

[0072] In another example, the classification engine can also classify any field i in the source transaction context in other ways. For example, it can determine whether the field name of any field i belongs to a first preset set. If yes, it determines that field i belongs to the data operation state category; if not, it continues to determine whether field i belongs to a second preset set. If yes, it determines that field i belongs to the protocol participation state category. Here, the first preset set is a pre-maintained set of field names belonging to the data operation state category, and the second preset set is a pre-maintained set of field names belonging to the protocol participation state category.

[0073] See also Figure 3 When the classification engine determines that field i does not belong to either the data operation status category or the protocol participation status category, it will classify it into another category. For example, other categories of fields include: transaction metadata fields, session and origin fields, time and timeout fields, etc. Other categories of fields can be split or retained according to their purpose.

[0074] For example, transaction metadata fields include a distributed transaction identifier, used to uniquely identify a distributed transaction; this can be selected to be retained. Another example is time and timeout fields, which include a transaction context retention period; this can be selected not to be retained.

[0075] The classification result can be obtained by classifying each field in the source transaction context using a classification engine.

[0076] After obtaining the classification results, they can be saved in the form of a classification mapping table. The classification mapping table can record the classification results, as well as the merging strategy labels for each field determined based on the classification results. The merging strategy labels can include merging labels corresponding to data operation status categories, and ignore labels corresponding to protocol participation status categories.

[0077] The table below shows the classification mapping of typical fields in a transaction context.

[0078] last_scn_ The last data operation point of the transaction Data operation status merge max_submitted_seq_no_ Maximum sequence number of submitted data operation log Data operation status merge start_scn_ / end_scn_ Data operation log timestamp boundaries Data operation status merge lock_mem_ctx_ Set of table locks or row locks within a transaction Data operation status merge state_ Two-phase submission phase Protocol Participation Status neglect scheduler_ Transaction scheduling node identifier Protocol Participation Status neglect is_sub2pc Should we adopt a two-phase commit? Protocol Participation Status neglect

[0079] Subsequently, when the merging engine reads fields, it can directly consume the label information from the category mapping table without repeatedly performing semantic judgments in the merging path. This decouples the semantic recognition process from the data merging process. The semantic recognition process can be centrally maintained when the transaction context structure changes, and the data merging process can rely on stable labels for execution.

[0080] For high-frequency migration scenarios, this approach can reduce the overhead of judgment during each merge. For transaction contexts with a large number of fields, this approach can also reduce the maintenance complexity caused by hard-coding judgments field by field.

[0081] In one example, the classification engine performs the classification operation on the source transaction context and generates a classification mapping table before the online merge operation is triggered. In this way, when the online merge operation is executed, the classification result of the source transaction context can be directly obtained through the classification mapping table, reducing the execution time of the online merge operation.

[0082] In another example, the classification engine's operation of classifying the source transaction context and generating a classification mapping table begins after the online merge operation is triggered. In other words, the overall logical chain of the online transaction context merging method for distributed transactions provided in this specification is as follows: a preset event occurs (e.g., shard migration) triggers online merging → the classification engine generates a classification mapping table → the merging engine executes the merging operation → merging is complete, and the target participant continues to participate in the distributed transaction protocol.

[0083] In another example, after classifying the source transaction context and obtaining the classification result, the classification engine also verifies the validity of the classification result.

[0084] Optionally, the verification can include whether the classification mapping table covers the necessary fields in the source transaction context, and whether the merge strategy label is consistent with the semantic category. If a field is found to be missing a classification record, the classification engine can be triggered to re-execute the classification; if a conflict is found between the merge label and ignore label configurations, it can be handled in a safer manner. For example, conflicting fields can be temporarily designated as ignore fields, and an exception log can be recorded to avoid the protocol participation state being mistakenly migrated. This verification process can improve the reliability of the classification results and provide stable input for subsequent reading and merging.

[0085] By classifying the source transaction context through a classification engine, the source transaction context on the source participant is no longer treated as a semantic whole, but is broken down into a set of fields with different merging strategies. Fields corresponding to the data operation status category can enter the subsequent merging chain, while fields corresponding to the protocol participation status category can be excluded from the direct merging chain. This processing provides a basis for subsequently reading only the data operation status category field and skipping the protocol participation status category field, and also enables the target participant to independently determine the protocol participation status based on local protocol facts.

[0086] In step S220, the first type of field of the data operation status category is read from the source transaction context.

[0087] The process of reading the data operation status category field from the source transaction context can be based on the merge strategy label in the classification mapping table.

[0088] For example, fields with merge tags in the source transaction context can be read, while fields with ignore tags are skipped to obtain the data operation status category field. Since fields with ignore tags typically correspond to protocol participation status categories, this reading method prevents the protocol participation status field from entering the subsequent direct merge chain.

[0089] In one example, after reading the data operation status category field, an integrity check can also be performed on the data operation status category field.

[0090] Optionally, integrity checks may include verifying that all fields marked with merge tags in the category mapping table have been read, checking that field values ​​are empty, and verifying that field formats conform to the input requirements of the merge engine. If any field reading fails, the failed field information can be logged, and a retry can be triggered. If the source participant is inaccessible due to a failure, the relevant fields can be reconstructed from the source participant's persistent logs, replica data, or recovery module. This approach reduces the impact of single points of failure on the context merge process.

[0091] In step S230, the first type of fields are merged into the target transaction context of the target participant.

[0092] After reading the data operation status category field, the merge engine can be used to merge the data operation status category field into the target transaction context. The target context can serve as the merge base, and the data operation status category field in the source transaction context can serve as the input to be merged.

[0093] The merge engine can perform different merge operations based on field types and write the merge results to the target transaction context. This process can preserve the existing state of the target participant and supplement the data operation state on the source participant related to the target data.

[0094] For cases where the target participant is a member of the original participant set in a distributed transaction, for example, a distributed transaction includes participant 1, participant 2, and participant 3. Assume participant 1 is the source participant, and participant 2 or participant 3 is the target participant. In this case, the target participant holds the transaction context, meaning the target transaction context is not empty. The merge engine can then use an idempotent merge method to combine the data operation status category fields from the source transaction context into the target transaction context. Specifically, it merges the data operation status category fields from the source transaction context with the data operation status category fields from both the source and target transaction contexts.

[0095] Idempotent merging can be understood as follows: when the same input is submitted repeatedly, the merge operation will not cause erroneous changes to the target transaction context.

[0096] For collection-type fields in the data operation status category, the merge engine can take the union of the fields on the source side and the target side, and perform deduplication through a globally unique identifier to obtain the merged result.

[0097] For example, collection-type fields can include lock collections, rollback reference collections, and operation object collections. Deduplication can determine whether a source-side element already exists in the target transaction context based on a globally unique identifier. If the source-side element already exists on the target side, the existing element on the target side can be retained; if the source-side element does not exist on the target side, it can be added to the target side. Through union and deduplication, the target participant can obtain a set of data operation objects jointly covered by the source and target sides, while reducing the risk of duplicate releases or rollbacks caused by duplicate elements.

[0098] For boundary category fields in the data operation status category field, the merge engine can perform boundary value processing based on the boundary calculator. When the value of the data operation status category field is a boundary category, the starting edge can take the minimum value of the source side and the target side, and the ending edge can take the maximum value of the source side and the target side to obtain the merge result.

[0099] For example, boundary fields can include operation timestamp boundaries, log sequence number boundaries, data reclamation boundaries, or operation range boundaries. Setting the starting edge to its minimum value ensures the merged transaction context covers earlier data operations; setting the ending edge to its maximum value ensures the merged transaction context covers later data operations. This approach ensures the target transaction context's data operation boundaries cover the historical operation range of both the source and target sides, reducing missed rollbacks, missed releases, or erroneous reclamation caused by overly narrow boundaries.

[0100] In one different implementation, a method of writing to a staging area followed by an atomic commit can be used to achieve the merge. Specifically, the merge engine can first write the merge result to the staging area corresponding to the target transaction context and record the merge epoch. After the staging area is successfully written, an atomic commit can be performed, making the target transaction context officially visible. If the staging area write fails, the merge can be abandoned, and the original state of the target transaction context can be maintained. This method can reduce the impact of merge failure on the normal transaction processing of the target participants and also provide clear boundaries for retrying.

[0101] For cases where the target participant is not a member of the original participant set of the distributed transaction, for example, the distributed transaction includes participant 1, participant 2, and participant 3. Assuming participant 1 is the source participant and the target participant is participant 4, which is not a member of the original participant set of the distributed transaction, the transaction context held by the target participant is the initialized transaction context, and the target transaction context is empty. In this case, the data operation status category field in the source transaction context can be directly copied to the target transaction context.

[0102] In one example, when an online merge operation begins, a merge epoch can be generated first. The merge epoch is used to uniquely identify a transaction context merge instance.

[0103] In distributed transaction online migration scenarios, the merge process may be triggered repeatedly due to network jitter, module restarts, or task retries. If repeated merges lead to duplicate additions of rollback records, duplicate lock releases, or repeated expansion of operation boundaries, it may affect transaction correctness. Therefore, the merge engine can perform idempotent control by combining merge requests and merge epochs. The merge request can carry a transaction identifier, the identifier of the source participant, the identifier of the target participant, and the data range affected by this merge. The merge epoch can be used to distinguish different merge instances. If a merge request corresponding to the same merge epoch has already been successfully processed, subsequent identical requests can be identified as duplicate requests and skipped from being written repeatedly.

[0104] In another example, the merge engine can also generate a merge process record. This record can include field identifiers, field types, target side values ​​before and after the merge, and the merge epoch. This record can be used for subsequent auditing, fault recovery, or duplicate merge verification. When a retry merge occurs, the merge epoch and idempotency check can be used to determine if the current request corresponds to a successfully merged instance. If it is determined to be a duplicate request, the set union or boundary calculation operations can be avoided, thereby reducing redundant processing overhead and lowering the risk of repeated state modifications.

[0105] Through the steps described above, fields in the source transaction context used to support local data rollback can be transferred to the target transaction context, while fields corresponding to the protocol participation status category can be excluded from the direct merge chain. The target participant can thus obtain the data operation status related to the target data without directly inheriting the protocol participation status of the source participant. This provides a foundation for subsequently determining the protocol participation status independently based on the target participant's local protocol facts.

[0106] In step S240, the protocol participation status of the target transaction context is determined based on the protocol facts that have been persisted locally by the target participant.

[0107] After the data operation status fields are merged into the target transaction context, the protocol participation status of the target transaction context will be determined based on the protocol facts that have been persisted locally by the target participant.

[0108] For example, a target participant can examine the local persistent log, extract records related to the distributed transaction commit protocol from the local persistent log, and then determine the protocol participation status based on the extraction results.

[0109] Protocol facts can include local persistent traces formed by the target participants during the protocol's execution. For example, protocol facts may include protocol message processing records, preparation phase pre-operation records, commit records, rollback records, or protocol commitment records. These records can be used to determine the target participant's position within the distributed transaction commit protocol.

[0110] Since these records are generated locally by the target participant and stored in the local persistent log, the target participant can restore the protocol state based on the local records after a crash and restart.

[0111] One specific method for determining this is to examine the local persistent log records of the target participant. If the persistent log records do not contain any protocol-related records, the protocol participation status of the target transaction context can be determined to be in a running state. This scenario corresponds to a stage where the target participant has not yet participated in protocol advancement and is only undertaking data operations.

[0112] If the persistent log records include pre-preparation phase operation records and the transaction has not yet entered the final state, the protocol participation state of the target transaction context can be determined as the preparation state. Pre-preparation phase operation records can indicate that the target participant performed local persistence operations to enter the preparation phase, but has not yet formed a committed or rollback final state.

[0113] If the persistent log includes commit records, the protocol participation status of the target transaction context can be determined to be committed. A commit record indicates that the target participant has locally persisted the commit decision, and subsequent processing can revolve around resource release and state cleanup after the commit.

[0114] If unidentifiable or conflicting protocol records exist in the local persistent log, a conservative recovery strategy can be adopted. In one different embodiment, this can be achieved by temporarily setting the protocol participation state of the target transaction context to the running state and triggering manual verification.

[0115] In another embodiment, this can be achieved by pausing the target participant's external protocol responses and waiting for the transaction coordinator to retry the protocol message. This reduces the probability of erroneously advancing the transaction when the protocol facts are incomplete.

[0116] Once the participation status of the protocol is determined, a merge completion record can be generated and persisted.

[0117] Optionally, the merge completion record may include the transaction identifier of the distributed transaction, the identifier of the source participant, the identifier of the target participant, the data range affected by the merge, and a completion flag.

[0118] In another example, the merge completion record may also include a merge epoch. The merge epoch can be used to uniquely identify a transaction context merge instance. The merge epoch can be generated when the online merge operation begins, associating the merge epoch with the distributed transaction, source participant, and target participant. This association can be recorded in the merge completion record or in a separate index table. Through the merge epoch, the system can distinguish merge instances triggered at different times and for different reasons, and it can also provide a basis for identifying duplicate requests.

[0119] Once the merge is complete, the record can be written to the persistent storage module or to the local persistent log. After a successful write, the target participant can continue to participate in the distributed transaction protocol interaction based on the protocol participation state of the target transaction context.

[0120] For example, when the protocol participation status is in the running state, the target participant can continue to receive transaction operation requests; when the protocol participation status is in the ready state, the target participant can respond to subsequent protocol messages from the transaction coordinator based on the ready state; when the protocol participation status is in the committed state, the target participant can perform post-commit cleanup. In this way, the target participant can continue to participate in the protocol after context merging without interrupting upper-layer business transactions.

[0121] After generating the merged complete record, the source transaction context can be marked as read-only and added to the delayed reclamation queue.

[0122] Once marked as read-only, the source transaction context can no longer accept new data operation state writes or participate in protocol state progression. A delayed reclamation queue can retain the source transaction context for a period of time to provide a basis for querying in cases of doubt regarding the merge result, system restarts, or the need for backtracking audits. When the delayed reclamation conditions are met, such as the retention period ending, checkpoint progression, or recovery confirmation completion, the source transaction context can be reclaimed. This process reduces interference from the source state to subsequent transaction processing and also reduces long-term storage resource occupation.

[0123] The following example, using a distributed database sharding migration scenario, illustrates the specific implementation of an online transaction context merging method for distributed transactions provided in this specification.

[0124] In a distributed database system, suppose a business order transaction T1001 is being executed. This transaction involves two participants: participant 1 and participant 2. Due to the need for online sharding migration, part of the transaction context originally carried by participant 1 needs to be migrated and merged onto participant 2. Participant 1 can be referred to as the source participant, denoted as P_src, and participant 2 as the target participant, denoted as P_dst.

[0125] The entire migration process must not terminate running transactions, nor allow upper-level business processes to detect any anomalies.

[0126] At the start of the migration, the system first detects the shard migration event and generates a unique merge epoch for this transaction context merge, for example, merge_epoch = 20260616-000123. This merge epoch is used to identify this merge operation and prevent confusion during subsequent retries or repeated executions.

[0127] Subsequently, the system enters Phase A, the semantic-level state classification phase. The classification engine reads the transaction context on P_src and analyzes the functional semantics of each field. For fields such as last_scn_, start_scn_, end_scn_, max_submitted_seq_no_, undo_refs, and lock_mem_ctx_, the classification engine determines that they describe the operational effects of the transaction on the data, respectively used for operation position recording, log boundary calculation, undo rollback, and lock release. Therefore, they are classified as data operation states and marked as needing to be merged. For fields such as state_, scheduler_, and is_sub2pc_, the classification engine determines that they describe the stage, role, or protocol commitment of the participants in the two-phase commit protocol. Therefore, they are classified as protocol participation states and marked as not directly inheritable.

[0128] After classification is complete, the system enters Phase B, the separate online merging phase. At this point, the merging engine does not simply copy the entire context of P_src to P_dst, but only reads the fields in the classification results that are marked as data operation status categories that need to be merged.

[0129] Assume that P_src has an Undo reference set of {U1001, U1002}, a lock set of {row_1, row_2}, a starting SCN of 150, an ending SCN of 180, a last operation position of 180, and a committed log sequence number of 25. Meanwhile, P_dst already has some context, with an Undo reference set of {U1002, U1003}, a lock set of {row_2, row_3}, a starting SCN of 160, an ending SCN of 175, a last operation position of 175, and a committed log sequence number of 22.

[0130] During the merge process, the system employs different idempotent merge rules for different types of data operation states. For set-type states such as Undo reference sets and lock sets, the system takes the union of the source and target sets and removes duplicates based on unique identifiers. Therefore, the merged Undo reference set becomes {U1001, U1002, U1003}, and the lock set becomes {row_1, row_2, row_3}. In this way, regardless of whether the transaction is eventually committed or rolled back, the target participant possesses complete data operation information, can correctly release all related locks, and can also undo all modified data if a rollback is required.

[0131] For boundary-type states like SCN boundaries, the system takes the smaller value between the two sides for the starting boundary and the larger value between the two sides for the ending boundary. Therefore, the merged starting SCN is 150, the ending SCN is 180, and the last operation position and committed log sequence number are also taken as the larger values ​​between the two sides, namely 180 and 25. In this way, the merged transaction context can fully cover the range of data operations that have occurred at both the source and destination ends.

[0132] Meanwhile, the system does not directly copy the protocol participation state of P_src to P_dst. Suppose P_src is currently in the PREPARE state, but P_dst has no local Prepare logs and has not formed any recoverable protocol facts related to Prepare. If the system simply inherits the PREPARE state of P_src to P_dst, then P_dst will hold a protocol commitment it never actually experienced. Once P_dst crashes, it will be unable to recover this PREPARE state from its local logs after restarting, resulting in an unrecoverable protocol state. Therefore, in this scheme, the protocol state of P_dst does not come from P_src, but is re-derived by P_dst based on the locally persisted protocol facts. Since P_dst in this example has neither Prepare facts nor Commit logs locally, the merged protocol state remains RUNNING.

[0133] After the merge is complete, the system writes the merge result to P_dst and records the merge completion information. Subsequently, P_dst continues to participate in the distributed transaction protocol based on the new context. The original context on the source participant P_src is not immediately deleted; instead, it is marked as read-only and placed in a delayed reclamation queue. This is done to avoid accidentally deleting the source context before the migration is fully stable, and also to facilitate subsequent auditing, recovery, or anomaly troubleshooting.

[0134] If the same merge operation is executed again due to network jitter or migration task retry, the system can still guarantee consistent results. This is because the merge has already been identified by `merge_epoch`, and the merge rule itself is idempotent. The Undo set and lock set are still merged and deduplicated, the SCN boundary is still a boundary value that covers the operation history of both sides, and the protocol state is still inferred from the local facts of the target. Therefore, repeated execution will not lead to duplicate Undo, duplicate lock release, or incorrectly advance the target protocol state to PREPARE or COMMIT.

[0135] In this way, the system preserves the complete data operation history of transactions during shard migration while avoiding the incorrect inheritance of protocol state. Ultimately, transaction T1001 can continue execution without interrupting business operations. If the coordinator ultimately decides to commit, P_dst can complete the commit based on the complete context; if the coordinator ultimately decides to roll back, P_dst can also completely undo the relevant modifications based on the merged Undo information; if P_dst crashes after migration, it can still recover the true and reliable protocol state based on local logs.

[0136] In summary, in the technical concepts of the various embodiments in this specification, a classification engine identifies the fields of data operation status categories and protocol participation status categories in the source transaction context. When the merging engine performs online merging, it only merges the data operation status category fields into the target transaction context. Simultaneously, it does not directly inherit the protocol participation status from the source transaction context, but determines the protocol participation status of the target transaction context based on the protocol facts already persisted locally by the target participant. Therefore, on the one hand, it ensures that the target participant obtains the data operation status required to support data rollback, avoiding the loss of rollback capability due to transaction context migration; on the other hand, it avoids the target participant incorrectly inheriting the protocol status of the source participant, ensuring that the protocol participation status is consistent with the actual local protocol facts of the target participant, improving the reliability of protocol advancement and crash recovery. This scheme can simultaneously guarantee data rollback integrity and protocol status recoverability during online migration or merging of distributed transactions, reducing transaction interruptions and improving the availability and security of distributed systems.

[0137] Furthermore, the merge completion record and merge epoch can provide traceability of the merge process and support idempotent processing in failure retry scenarios; the read-only marking and delayed reclamation of the source transaction context can reduce the impact of residual state after the merge on system operation.

[0138] According to another embodiment, an online transaction context merging apparatus for distributed transactions is provided. Figure 4 This diagram illustrates the structure of an online transaction context merging apparatus for distributed transactions according to one embodiment. This apparatus can be deployed in any device, platform, or device cluster with data storage, computing, and processing capabilities. Figure 4 As shown, the device 400 includes:

[0139] The acquisition module 401 is used to acquire the classification result of the source transaction context related to the target data held by the source participant in response to a preset event indicating that the ownership of the target data has changed from the source participant to the target participant. The classification result indicates the category to which each field in the source transaction context belongs in multiple categories. The multiple categories include data operation status category and protocol participation status category. The fields of the data operation status category are used to support local data rollback, and the fields of the protocol participation status category are used to indicate the execution information related to the distributed transaction commit protocol.

[0140] The reading module 402 is used to read a first type of field of the data operation status category from the source transaction context;

[0141] Merging module 403 is used to merge the first type of fields into the target transaction context of the target participant;

[0142] The determination module 404 is used to determine the protocol participation status of the target transaction context based on the protocol facts that have been persisted locally by the target participant.

[0143] In one possible implementation, the classification result is obtained through the following classification method:

[0144] For any field in the source transaction context, perform the first judgment operation and the second judgment operation respectively, wherein:

[0145] The first judgment operation includes: determining whether any field is used to describe the operation effect of the transaction on the data object; if so, determining any field as the data operation status category.

[0146] The second determination operation includes: determining whether any of the fields is used to represent any one of the protocol stage, protocol role, or protocol commitment made by the source participant in the distributed transaction commit protocol; if so, then the field is determined as the protocol participation status category.

[0147] In another possible implementation, the first determination operation and / or the second determination operation are performed in the following manner:

[0148] Based on the field name of any of the fields, the metadata descriptor corresponding to any of the fields is retrieved from the metadata registry, and the metadata descriptor indicates the functional semantics of any of the fields;

[0149] The first judgment operation and / or the second judgment operation are performed according to the functional semantics.

[0150] In another possible implementation, module 401 is specifically used for:

[0151] The classification mapping table is read to obtain the classification result. The classification mapping table records the classification result and the merging strategy label for each field determined according to the classification result. The merging strategy label includes a merging label corresponding to the data operation status category and an ignore label corresponding to the protocol participation status category.

[0152] In another possible implementation, the reading module 402 is used for:

[0153] Read the fields with merge tags in the source transaction context and skip the fields with ignore tags to obtain the first type of fields.

[0154] In another possible implementation, the merging module 403 is specifically used for:

[0155] The first type of fields are idempotently merged with the corresponding fields already existing in the target transaction context.

[0156] In another possible implementation, when performing an idempotent merging of the first type of fields with the corresponding fields already existing in the target transaction context, the merging module 403 is specifically used for:

[0157] When the value of the first type of field is a set, the union of the fields on the source side and the target side is taken, and deduplication is performed using a globally unique identifier to obtain the merged result;

[0158] When the value of the first type of field is a boundary type, the starting edge takes the minimum value between the source side and the target side, and the ending edge takes the maximum value between the source side and the target side to obtain the merging result.

[0159] In another possible implementation, the determining module 404 is specifically used for:

[0160] Check the persistent log records on the target participant's local machine;

[0161] If the persistent log records do not include any protocol-related records, then the protocol participation status of the target transaction context is determined to be in the running state.

[0162] If the persistent log records include pre-preparation operation records and the transaction has not entered the final state, then the protocol participation state of the target transaction context is determined to be in the preparation state.

[0163] If the persistent log records include commit records, then the protocol participation status of the target transaction context is determined to be a commit status.

[0164] In another possible implementation, the online transaction context merging device 400 for the distributed transaction further includes a persistence module 405. The persistence module 405 is used to generate and persist a merge completion record after determining the protocol participation status of the target transaction context based on the protocol facts that have been persisted locally by the target participant. The merge completion record includes the transaction identifier of the distributed transaction, the identifier of the source participant, the identifier of the target participant, the data range affected by the merge, and a completion flag.

[0165] In another possible implementation, the online transaction context merging device 400 for distributed transactions further includes a processing module 406, which is used to perform the following after the generated and persisted merged records:

[0166] Based on the protocol participation state of the target transaction context, the target participant is enabled to continue participating in the protocol interaction of the distributed transaction; and / or

[0167] The source transaction context is marked as read-only, and the source transaction context is added to the delayed recycling queue.

[0168] In another possible implementation, the online transaction context merging device 400 for distributed transactions further includes a generation module 407, which generates a merge epoch before obtaining the classification results of the source transaction contexts held by the source participants in relation to the target data. The merge epoch is used to uniquely identify a transaction context merging instance.

[0169] Associate the merge epoch with the distributed transaction, the source participant, and the target participant;

[0170] The merge completion record also includes the merge epoch.

[0171] For specific implementation examples of each unit in the above device, please refer to the previous examples. Figure 2 The above-described device enables simultaneous assurance of data rollback integrity and protocol state recoverability during online migration or merging of distributed transactions, reducing transaction interruptions and improving the availability and security of distributed systems.

[0172] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 2 The method described.

[0173] According to yet another embodiment, a computer program product is also provided, including a computer program / instructions that, when executed by a processor, implement the foregoing combinations. Figure 2 The described method and steps.

[0174] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 2 The method described.

[0175] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0176] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for online merging of transaction contexts in distributed transactions, comprising: In response to a preset event indicating a change in ownership of target data from the source participant to the target participant, the classification result of the source transaction context related to the target data held by the source participant is obtained. The classification result indicates the category to which each field in the source transaction context belongs among multiple categories. The multiple categories include data operation status category and protocol participation status category. The fields of the data operation status category are used to support local data rollback, and the fields of the protocol participation status category are used to indicate execution-related information of the distributed transaction commit protocol. Read the first type of field of the data operation status category from the source transaction context; Merge the first type of fields into the target participant's target transaction context; Based on the fact that the target participant has persisted the protocol locally, the protocol participation status of the target transaction context is determined.

2. The method according to claim 1, wherein, The classification results were obtained through the following classification method: For any field in the source transaction context, perform the first judgment operation and the second judgment operation respectively, wherein: The first judgment operation includes: determining whether any field is used to describe the operation effect of the transaction on the data object; if so, determining any field as the data operation status category. The second determination operation includes: determining whether any of the fields is used to represent any one of the protocol stage, protocol role, or protocol commitment made by the source participant in the distributed transaction commit protocol; if so, then the field is determined as the protocol participation status category.

3. The method according to claim 2, wherein, The first judgment operation and / or the second judgment operation are performed in the following manner: Based on the field name of any of the fields, the metadata descriptor corresponding to any of the fields is retrieved from the metadata registry, and the metadata descriptor indicates the functional semantics of any of the fields; The first judgment operation and / or the second judgment operation are performed according to the functional semantics.

4. The method according to claim 1, wherein, Obtain the classification results of the source transaction context held by the source participant related to the target data, including: The classification mapping table is read to obtain the classification result. The classification mapping table records the classification result and the merging strategy label for each field determined according to the classification result. The merging strategy label includes a merging label corresponding to the data operation status category and an ignore label corresponding to the protocol participation status category.

5. The method according to claim 4, wherein, The first type of field for reading the data operation status category from the source transaction context includes: Read the fields with merge tags in the source transaction context and skip the fields with ignore tags to obtain the first type of fields.

6. The method according to claim 1, wherein, The step of merging the first type of fields into the target participant's target transaction context includes: The first type of fields are idempotently merged with the corresponding fields already existing in the target transaction context.

7. The method according to claim 6, wherein, The step of idempotently merging the first type of fields with the corresponding fields already existing in the target transaction context includes: When the value of the first type of field is a set, the union of the fields on the source side and the target side is taken, and deduplication is performed using a globally unique identifier to obtain the merged result; When the value of the first type of field is a boundary type, the starting edge takes the minimum value between the source side and the target side, and the ending edge takes the maximum value between the source side and the target side to obtain the merging result.

8. The method according to claim 1, wherein, Determining the protocol participation state of the target transaction context based on the locally persisted protocol facts of the target participant includes: Check the persistent log records on the target participant's local machine; If the persistent log records do not include any protocol-related records, then the protocol participation status of the target transaction context is determined to be in the running state. If the persistent log records include pre-preparation operation records and the transaction has not entered the final state, then the protocol participation state of the target transaction context is determined to be in the preparation state. If the persistent log records include commit records, then the protocol participation status of the target transaction context is determined to be a commit status.

9. The method according to claim 1, wherein, The process of determining the protocol participation state of the target transaction context based on the locally persisted protocol facts of the target participant further includes: Generate and persist a merge completion record, which includes the transaction identifier of the distributed transaction, the identifier of the source participant, the identifier of the target participant, the data range affected by the merge, and a completion flag.

10. The method according to claim 9, wherein, The process of generating and persisting the merged record then includes: Based on the protocol participation state of the target transaction context, the target participant is enabled to continue participating in the protocol interaction of the distributed transaction; and / or The source transaction context is marked as read-only, and the source transaction context is added to the delayed recycling queue.

11. The method according to claim 9, wherein, The step of obtaining the classification results of the source transaction context held by the source participant related to the target data also includes: Generate a merge epoch, which is used to uniquely identify a transaction context merge instance; Associate the merge epoch with the distributed transaction, the source participant, and the target participant; The merge completion record also includes the merge epoch.

12. An online transaction context merging device for distributed transactions, comprising: The acquisition module is used to, in response to a preset event indicating a change in the ownership of target data from the source participant to the target participant, acquire the classification result of the source transaction context related to the target data held by the source participant. The classification result indicates the category to which each field in the source transaction context belongs among multiple categories. The multiple categories include data operation status category and protocol participation status category. The fields of the data operation status category are used to support local data rollback, and the fields of the protocol participation status category are used to indicate the execution information related to the distributed transaction commit protocol. A reading module is used to read a first type of field of the data operation status category from the source transaction context; The merge module is used to merge the first type of fields into the target transaction context of the target participant; The determination module is used to determine the protocol participation status of the target transaction context based on the protocol facts that have been persisted locally by the target participant.

13. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-11.

14. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-11.

Images