CN111352704A - 基于策略管理的分布式全局事务处理系统和方法 - Google Patents

基于策略管理的分布式全局事务处理系统和方法 Download PDF

Info

Publication number
CN111352704A
CN111352704A CN201910785928.8A CN201910785928A CN111352704A CN 111352704 A CN111352704 A CN 111352704A CN 201910785928 A CN201910785928 A CN 201910785928A CN 111352704 A CN111352704 A CN 111352704A
Authority
CN
China
Prior art keywords
transaction
participating
state
policy
record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201910785928.8A
Other languages
English (en)
Inventor
叶常青
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of CN111352704A publication Critical patent/CN111352704A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2282—Tablespace storage structures; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G06F16/24554—Unary operations; Data partitioning operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种基于策略管理的分布式全局事务处理系统，包括：至少一个可配置的策略记录，每个该策略记录存储事务信息，参与事务处理的应用程序的信息，以及指定每个该应用程序在该事务处理中遵循的确保事务完整性的规则；至少两个应用程序，由计算机可执行程序实现，包括随时间生成消息的消息产生程序或随时间从其订阅的消息产生程序接收消息的消息消费程序，且该应用程序在更新事务的处理状态和/或该策略记录时，独立于参与该事务处理的其他应用程序；消息管理器用于随时间接收并存储该消息产生程序生成的消息，并将该消息分发给所有订阅该消息的消息消费程序；以及事务状态记录，用于记录该应用程序参与该事务处理的状态，以及该事务处理的状态。

Description

基于策略管理的分布式全局事务处理系统和方法
技术领域
本发明涉及全局事务处理和管理技术领域，具体涉及一种在分布式系统中多个独立应用程序执行事务的全局分布式事务管理系统和方法。
背景技术
如流处理和集成系统、lambda架构平台、微服务、大数据平台等新兴技术和应用需求增加了应用程序事务语义的多样性和复杂性。分布式系统中的每个应用程序同时独立或协作产生、消费和处理事件或消息。此外，这些应用程序需要访问多个流数据源以及传统的存储数据源。分布式应用程序的执行顺序是随机的，并且没有明确的事务边界。参与全局事务的每个应用程序都可以启动或结束事务，每个应用程序都需要未知的时间来完成接收到的事件或消息的业务逻辑。在这些系统中，保留全局事务ACID(数据库事务正确执行的四个基本特性：原子性Atomicity、一致性Consistency、隔离性Isolation、持久性 Durability)属性和处理的完整性通常是有很多问题且具有挑战性的。通过全局事务管理器的现有技术容器管理的事务机制在这些情况下不起作用，因为参与的应用程序甚至可能不在任何容器中运行。
发明内容
本发明提出了一种使用确定性策略管理全局事务的新方法和系统，其利用全局系统性能以有效，灵活和可扩展的方式解决了上述困难。
具体来说，本发明公开了一种全局事务的分布式处理的方法和系统的实施例，包括使用至少一个可配置的策略记录来存储事务信息；定义参与事务处理的两个或更多个应用程序；一个或多个规则指定每个参与应用程序在处理事务时需要遵循的以确保全局事务完整性的条件，其中参与的应用程序由计算机程序实现，应用程序或随时间生成消息的消息生成程序或随时间从其订阅的消息生成程序接收消息的消息消费程序；一个参与的应用程序在更新事务的处理状态和/或更新事务的可配置策略记录中独立于该其它参与的应用程序；消息管理器，用于随时间接收并存储从一个或多个消息生成程序生成的一个或多个消息，并将该消息分发给订阅该消息的一个或多个消息消费程序；事务状态记录，用于记录参与应用程序参与该事务处理的状态；其中，每个参与应用程序异步并独立运行基于策略启动事务处理或加入现有事务处理，更新事务状态记录中的处理状态，并检查该策略记录以确定其进行的下一步操作。
此外，在该方法或系统中，策略记录中的事务规则指定如果所有参与的应用程序在策略记录中定义的事务边界时间内准备好提交并且要求每个参与的应用程序提交事务，则全局事务准备好提交。从事务状态记录中知道全局事务已准备好提交时，提交其操作；并且其中当每个参与的应用程序准备提交其操作时，它更新其在事务状态记录中的状态以指示它准备提交，并且在从事务状态记录知道参与该事务的所有指定的参与应用程序已更新时，他们的事务状态记录表明他们已经准备好提交，每个参与的应用程序在事务边界时间内提交其操作并更新在事务状态记录中的状态。
策略记录可以包括规则，该规则定义如果一个或多个参与该事务处理的应用程序处理失败或未能在策略记录定义的事务边界时间内完成处理，则全局事务处理失败；当全局事务处理失败，该规则要求每个参与该事务处理的应用程序回滚其操作；从事务状态记录知道一个或多个参与该事务处理的应用程序处理失败或未能在策略记录定义的事务边界时间内完成处理，每个参与该事务处理的应用程序回滚其操作，应用程序的状态回滚到其操作之前的状态。
策略记录还可以包括事务规则，该规则定义根据事务状态记录中事务处理的状态知道已个或多个参与的应用程序已经失败，参与的应用程序停止事务处理并回滚其操作。
本发明的方法或系统，还包括事务状态通知器，当事务状态记录被更新或者每个参与的应用程序基于事务的策略记录的规则进行失败恢复时，事务状态通知器通知所有参与该事务处理的应用程序。
本发明的方法或系统，还包括策略管理器，用于通过接收来自用户界面或 API接口的输入，生成或编辑事务的策略记录的内容，该内容包括事务信息、规则和事务边界时间；一个或多个应用程序访问事务策略记录并通过策略管理器编辑策略记录的部分或全部内容，该内容包括事务信息、规则和事务边界时间，并由事务状态通知器通知所有参与该事务处理的应用程序。
附图说明
图1是本发明的分布式全局事务处理系统的第一部分示意图。
图2是本发明的分布式全局事务处理系统的第二部分示意图。
图3是本发明的基于策略的全局分布式事务处理的事务记录和策略记录的元数据示意图。
图4是全局事务和参与应用程序的状态转换图。
图5是包括一组参与应用程序和具有5个规则的策略的示例图。
图6说明由6个不同的事务记录组成的事务记录表的示例图。
图7说明基于策略的分布式事务处理中的参与应用程序，事务代理和策略管理器之间的交互的序列图的示例图。
图8说明说明参与的应用程序和事务代理的开始处理基于策略的分布式事务处理的框图。
图9说明参与的应用程序和事务代理的基于策略的分布式事务处理的准备提交的处理的框图。
图10说明参与的应用程序和事务代理的基于策略的分布式事务处理的提交处理的框图。
图11说明参与的应用程序和事务代理的回滚处理的框图。
图12说明参与应用程序的故障恢复处理示意图。
具体实施方式
下面结合附图对本发明的具体实施方式做出进一步的详细说明，所描述的实施例仅仅是本发明的一种实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有付出创造性劳动前提下所获得的所有其它实施例，都属于本发明的保护范围。
本发明公开了用于基于可定义的策略管理的分布式全局事务处理的系统和方法，其包括：策略记录，事务状态记录，事务代理和策略管理器；其中策略记录包括一组规则，用于定义事务中每个参与的应用程序要遵循的条件，以确保事务的完整性；例如，定义事务边界时间的规则，该事务边界时间确定事务完成的时限；一个或多个规则还指定有多少应用程序和具体哪些应用程序参与事务处理，以及一个或多个规则用于确定参与事务处理的应用程序如何准备提交、提交或中止事务；规则可以完全由用户定义，也可以是预定义和客户化，可以以任何工业标准格式定义，例如XML，JSON和DSL(特定邻域语言) 等语言编写及修改；规则可以作为策略记录存储在任何工业标准数据库或专有数据库中；规则是线程安全的，规则下的任何参与事务处理的应用程序都可以同时读取相同的规则，在同时刻只有一个应用程序可以对规则执行原子更新 (atomic update)。
策略管理器用于管理策略记录，例如，从存储器创建、更新和读取规则记录；通过用户界面或每个参与事务处理的应用程序都可以执行策略管理器以添加或更新任何策略的规则；以及根据可定义的权限将应用程序登记到策略中或从策略中删除应用程序。
参与事务处理的应用程序通过策略管理器登记到特定的策略中；而要取消关联事务处理的应用程序也通过策略管理器将其从策略中除名；参与全局事务的每个应用程序根据策略在事务处理中扮演等效角色或非等效角色并执行事务。参与事务的每个应用程序可以是事务的发起者也可以是事务的终止者。每个全局事务必须关联一个策略。启动全局事务会创建新的事务记录，其中事务记录包含一个策略标识Id，策略标识Id唯一标识与此事务关联的策略记录，由策略确定的参与此事务的应用程序列表以及相应应用程序的状态列表，一个事务状态，一个消息标识Id或一个组标识Id用于唯一标识在此事务范围内处理的一个或多个消息或事件，开始时间戳和事务结束时间戳。一个参与的应用程序根据策略更新其应用程序状态和事务状态。事务记录是线程安全的，策略下的任何参与应用程序都可以同时读取相同的事务记录，同一时间只有一个应用程序可以对事务记录执行原子更新；事务记录可以存储在任何工业标准数据库或专有存储中。
事务代理用于基于策略创建，更新和读取事务记录；事务代理通过策略管理器访问与事务关联的策略记录；参与事务的一个应用程序如果是事务的发起者使用事务代理创建事务记录，根据与事务关联的册立更新其应用程序状态和事务状态。在一些实施例中，多个应用程序可以共享一个事务代理，也可以每个应用程序具有自身的事务代理。
所有参与的应用程序都需要访问多个资源，包括流数据源以及存储的数据源。参与事务的应用程序具有不同的合法状态：非活跃(INACTIVE)，活跃 (ACTIVE)，准备(PREPARED)，失败(FAILED)，提交(COMMITTED) 和回滚(ROLLEDBACK)，其中状态根据策略和不同的操作转换到不同的状态；应用程序以非活跃(INACTIVE)状态开始，其中此状态的应用程序尚未接收任何消息或事件，并且尚未启动任何业务逻辑处理；处于活跃(ACTIVE) 状态的应用程序正在进行处理中；应用程序为其本地资源或其本地事务准备提交后，应用程序处于准备(PREPARED)状态；处于准备(PREPARED)状态的应用程序要么回滚要么提交事务处理；如果发生任何错误或异常，应用程序进入失败(FAILED)状态。处于失败(FAILED)状态的应用程序必须回滚。处于提交(COMMITTED)或回滚(ROLLEDBACK)状态的应用程序是最终状态，表示一个逻辑事务处理周期结束并可以开始下一个周期。应用程序的状态在内存中缓存并保留在存储器的事务记录中，内存中的值和存储器的事务记录中的值是同步的。
事务具有不同的合法状态：活跃(ACTIVE)、活跃/准备(部分准备) (ACTIVE/PREPARED(PARTIALLY PREPARED))、活跃/失败 (ACTIVE/FAILED)、提交(COMMITTED)和回滚(ROLLEDBACK)，其中事务代理用于基于策略和应用程序的状态计算事务的每个状态。实施例的策略的默认规则集定义，仅当每个参与的应用程序是活跃的或非活跃时，全局事务才处于活跃状态；仅当所有参与的应用程序都已提交时，全局事务才处于提交状态；仅当所有参与的应用程序都回滚时，全局事务才处于回滚状态；仅当每个参与的应用程序都已准备提交好或处于活跃状态或非活跃状态时，全局事务才处于活跃状态；仅当每个参与的应用程序发生故障或回滚或者处于活跃或非活跃状态(其中一个参与的应用程序必须失败或回滚)时，全局事务才处于活跃/失败状态。
基于策略的事务管理机制确保所有分布式参与事务的应用程序和资源要么一起提交或要么都回滚。
在处理的任何方面(例如，服务器或数据库崩溃，网络连接失败或发生未处理的软件异常)期间，事务可能失败。失败的事务变得不确定并造成系统潜在的不一致性。在分布式系统或参与的应用程序重新启动后，不确定的事务会将系统和参与的应用程序恢复到一致状态。每个参与的应用程序也通过事务代理分发和执行故障恢复。
基于策略的分布式事务处理没有管理事务和状态的集中式全局事务管理器；分布式事务管理的复杂性降低，并且数据流处理的效率和生产力增强，例如，参与的应用程序知道其他参与的应用程序的故障并且中断当前的处理并触发事务的回滚。
图1是本发明的基于策略的分布式全局事务流系统的方框图的第一部分，包括消息管理器105，一个或多个消息生成应用程序(100，101和10m，一个或多个消息消费应用程序112，113和11n，以及图2中所示的组件。消息管理器105具有消息流106，107和108；其中每个消息流以先进先出(FIFO) 顺序随时间存储一系列消息或事件。消息生成应用程序将消息发送到其消息生成应用程序注册的消息流中。消息管理器105将来自每个消息流的一个或多个消息传递给订阅该消息流的一个或多个消息消费应用程序。所有消息生成应用程序和消息消费应用程序都以分布式和并发模式运行。底层消息管理器保证将消息从消息流传递到订阅的消息消费应用程序一次仅一次。如果在消息传递过程中出现任何故障，或者消息消费应用程序无法处理收到的消息并回滚所述消息，则消息管理器105会重新传递被回滚的消息，直到此消息被消费 (consumed)或被提交(committed)为止。在该实施例中，如果在预设时间内重新传递失败，则消息管理器105可以丢弃被回滚的消息。图1中120和 130分别表示消息生成应用程序和消息消费应用程序可以通过使用图2所示的策略管理器登记与事务相关联的策略来参与事务。
图2是图1所示方框图的第二部分，显示基于策略的分布式事务系统，包括事务代理202，策略管理器210，事务通知器212，一组事务记录204和一组策略记录208。事务代理通过行业标准接口203(例如，JDBC，RESTFulAPI) 管理事务记录。事务记录是线程安全的。策略管理器通过行业标准接口209(例如，JDBC，RESTFulAPI)管理策略记录。策略记录也是线程安全的。每个事务记录与一个且仅一个策略记录相关联，例如，指示线205表示事务1与规则 2相关联；指示线206表示事务2也与规则2相关联；指示线207表示事务3 与规则1相关联。多个事务可以与同一策略记录相关联，例如，指示线205 和指示线206表示事务1和事务2都与策略2相关联。参与的应用程序执行事务代理和策略管理器。
对事务记录的任何更改，图2中的事务通知器212通知注册于事务通知器 212的应用程序。通知是以异步的方式发送到通过行业标准接口213(例如， RESTFulAPI)注册的应用程序，注册的应用程序见图1所示的任何消息消费程序和消息产生程序，可以是消息产生程序100或101或10m或全部，可以是消息消费程序112或113或11n或或全部。图2中的接口213联接任何注册于事务通知器212的100或101或10m或全部，及112或113或11n或或全部。图3是本发明的基于策略的全局分布式事务处理的事务记录和策略记录的元数据示意图。事务记录300包括事务标识符Id，事务状态，策略标识符Id，消息标识符Id或组消息标识符Id，开始时间戳，结束时间戳，以个或更多的本地事务标识符Id和参与应用程序的状态对。事务标识符Id是事务的全局唯一标识符。事务状态指定事务过程的状态，其中事务的合法状态将在图4中进行描述。策略标识符Id是302中的策略记录的参考301。消息标识符Id或组消息标识符Id是任何参与的应用程序接收的一个或一组消息的唯一标识符，并且该事务在一个处理周期中进行处理。来自消息流的相同消息被广播到同时订阅该消息流的多个消息消费应用程序。开始时间戳是事务开始的时间，结束时间戳是事务结束的时间。事务中的每个参与应用程序都保留一对状态和本地事务标识符Id。本地事务标识符Id是参与应用程序范围内的事务标识符。本地事务标识符Id将自动生成。通常，参与应用程序的本地事务资源管理器生成本地事务标识符Id。策略记录302包括策略标识符Id，规则集，由策略管理的一个或多个应用程序标识符Id，例如302中的应用程序Id1，应用程序Id2，应用程序Idn。规则集定义多个规则，每个规则确定准备事务，提交事务，使事务失败以及回滚事务的标准。规则可以完全由用户定义，也可以是预定义和可客户化。规则格式可以遵循任何行业标准，例如JSON，XML或DSL(特定域的语言)。
图4是全局事务和参与应用的状态转换图。事务以活跃(ACTIVE)状态开始，并且可以处于活跃(ACTIVE)，活跃/准备(ACTIVE/PREPARED)，活跃/失败(ACTIVE/FAILED)，提交(COMMITTED)和回滚(ROLLEDBACK) 任何合法状态。参与的应用程序以非活跃(INACTIVE)状态开始，可以处于非活跃(INACTIVE)、活跃(ACTIVE)、准备(PREPARED)、失败(FAILED)，提交(COMMITED)和回滚(ROLLEDBACK)的任何合法状态。提交状态或回滚状态标志着事务结束。
仅当每个参与的应用程序处于非活跃或活跃时，全局事务才处于活跃状态；
如果所有参与的应用程序处于非活跃状态或活跃状态或准备状态，其中至少一个应用程序处于准备状态，则全局事务处于活跃/准备状态。
如果所有参与的应用程序处于非活跃(INACTIVE)、活跃(ACTIVE)、准备(PREPARED)、回滚(ROLLEDBACK)或失败(FAILED)状态，且至少其中一个应用程序处于失败(FAILED)或回滚(ROLLEDBACK)状态，则全局事务处于活跃/失败(ACTIVE/FAILED)状态；
仅当所有参与的应用程序都处于提交(COMMITED)状态时，则全局事务处于提交状态；
仅当所有参与的应用程序都处于回滚(ROLLEDBACK)状态时，则全局事务处于回滚状态。
一个全局事务或参与的应用程序基于策略和由规则确定的操作从一个状态转换到另一个状态，其中如果任何一个参与的应用程序根据策略准备提交，则全局事务将活跃(ACTIVE)状态401转移到活跃/准备 (ACTIVE/PREPARED)状态403。如果任何故障发生或者参与的应用程序根据规则需要回滚，则全局事务从活跃(ACTIVE)状态401或从活跃/准备(ACTIVE/PREPARED)状态403转移到活跃/失败(ACTIVE/FAILED)410 状态；如果所有参与的应用程序准备提交和提交，则全局事务从活跃/准备 (ACTIVE/PREPARED)状态403转移到提交(COMMITTED)状态405；如果所有参与的应用程序回滚，则全局事务从活跃/失败(ACTIVE/FAILED)状态410转移到回滚(ROLLEDBACK)状态409。如果所有参与的应用程序回滚，则全局事务可以直接将活跃(ACTIVE)状态401移动到回滚 (ROLLEDBACK)状态409。
其中，参与的应用程序在接收到消息或开始处理之后从非活跃 (INACTIVE)状态421转移到活跃(ACTIVE)状态423；如果参与的应用程序基于策略满足准备提交并准备提交的条件，则参与的应用程序从活跃 (ACTIVE)状态423转移到准备(PREPARED)状态425；如果参与的应用程序基于策略满足提交并提交的条件，则参与的应用程序从准备(PREPARED)状态425转移到提交(COMMITTED)状态427；如果发生任何故障或者参与的应用程序根据策略需要回滚，则参与的应用程序从准备(PREPARED)状态 425或从活跃(ACTIVE)状态423移动到失败(FAILED)状态432；一旦参与的应用程序回滚，参与的应用程序从失败(FAILED)状态432转移到回滚 (ROLLEDBACK)状态431；如果参与的应用程序于策略需要回滚，则参与的应用程序直接从活跃(ACTIVE)状态423转移到(回滚ROLLEDBACK) 状态431。
在参与的应用程序准备提交之后的大多数情况下，参与的应用程序基于策略等待满足通过事务代理提交的条件；只有在当前全局事务提交或回滚后，才会启动与策略关联的新全局事务。取决于分布式系统的实施例，在一些情况下，一旦应用程序成功准备提交或基于策略执行本地提交，参与的应用可以发起新的全局事务。全局事务提交的排序由策略定义并由策略维护。
图5显示了策略记录500的示例，其包括n个应用程序，例如，应用程序 1、应用程序2、……和应用程序n，策略Id1，以及指向由五个规则502组成的策略的策略指针501。规则1定义最大事务边界时间为10分钟。如果全局事务无法在定义的最大事务边界时间内完成，则全局事务将过期并失败。如果任何参与的应用程序失败或回滚，则规则2定义全局事务失败。如果所有参与的应用程序准备好，则规则3提交全局事务。当全局事务失败时，规则4回滚所有参与的应用程序。当所有参与的应用程序都已提交时，规则5完成提交全局事务。
图6显示了事务记录的示例。表600包含六个不同的事务记录，其中第二列600中的事务记录0001描绘了与该事务0001相关联的策略标识符Id是01。事务中的消息标识符Id是1001。所有参与的应用程序，例如，应用程序1，应用程序2，应用程序n，已提交，处于提交(COMMITTED)状态。因此，第二列的事务状态行指示事务已结束并处于提交(COMMITTED)状态。开始时间戳和结束时间戳被记录。新的事务可以开始。
表600的第三列中的事务记录0002指示与该事务0002相关联的策略标识符Id是01。事务中的消息标识符Id是1002，并且每个参与的应用程序，例如应用程序1，应用程序2到应用程序n，准备或提交(处于准备(PREPARED) 或提交(COMMITTED)状态)。表600第三列的事务状态行指示事务已准备好(处于活跃(ACTIVE)/准备(PREPARED)状态)，事务仍处于活跃状态，并且一些参与的应用程序已提交，一些参与的应用程序处于准备(PREPARED) 状态。尚未提交的应用程序正在提交过程中，事务尚未完成，结束时间戳尚未记录下。在异步实施例中，事务通知器通知尚未提交执行本地提交的参与应用程序。一旦所有参与的应用程序成功提交并且事务代理在内存和/或存储中更新事务状态提交(COMMITTED)状态并完成事务。
表600的第四列中的事务记录0003指示与该事务0003相关联的策略Id 是01。事务中的消息标识符Id是1003。每个参与的应用或准备或或激活(处于活跃(ACTIVE)或准备(PRPEARED)状态)。第四列的第7行表示应用程序1的本地事务100003处于准备(PREPARED)状态，而第四列的第8行表示应用程序2的本地事务100003处于活跃(ACTIVE)状态。第四列的第二行(事务状态)指示事务仍处于活跃状态。一些参与的应用程序仍在进行中，尚未做好准备提交。处于活跃(PREPARED)状态的应用程序根据策略等待满足提交的条件。
表600的第五列中的事务记录0004指示与该事务0004相关联的策略Id 是01。事务中的消息标识符Id是1004。一个或多个参与的应用程序失败。表 600的第五列的第7行表示应用1的本地事务100004失败(处于失败(FAILED) 状态)，并且表600第五列的第8行表示准备了应用2的本地事务100004处于准备(PREPARED)状态。表600第五列的最后一行表示应用程序n的本地事务100004是活跃的。因此，全局事务失败(处于活跃(ACTIVE)/失败(FAILED)状态)。所有参与的应用程序都需要根据规则回滚到内存和/或存储中的操作前的原始状态。
第六列中的事务记录0005指示与该事务0005相关联的策略标识Id是01。事务中的消息标识符Id是1005。一个或多个参与的应用程序回滚。表600的第六列的第7行表示应用程序1的本地事务100005回滚(处于回滚 (ROLLEDBACK)状态)，表600的第六列的第8行表示准备应用程序2的本地事务100005处于准备(PREPARED)状态。表600的第六列的最后一行表示应用程序n的本地事务100005是活跃(处于活跃(ACTIVE)状态)。因此，全局事务处于活跃(ACTIVE)/失败(FAILED)状态。所有尚未回滚的参与应用程序都需要回滚到原始状态，然后事务代理会根据策略将事务状态更新ROLLEDBACK状态在内存和/或存储中。
表600的第七列中的事务记录0006表示与此事务0006关联的策略标识符 Id是01。事务中的消息标识符Id是1006。所有参与的应用程序都已回滚(处于回滚状态(PREPARED))。第七列的第2行指示事务已回滚(处于回滚 (PREPARED)状态)。现事务处理结束，新事务可以启动。
图7是显示多个参与应用程序(例如，参与应用程序700，参与应用程序 701和参与应用程序702)与基于策略的分布式全局事务系统中的不同组件交互的序列图的示例，包括事务代理703，事务记录704，策略管理器705和策略记录706。任何应用程序(例如，参与的应用程序1，指示线700所示)必须使用策略管理器705来登记到策略以便参与事务。全局事务可以分解为多个阶段，例如，开始阶段707，准备阶段708和提交阶段709。任何参与的应用程序或分布式系统在处理过程中都可能失败。故障的恢复过程如图11、图12 所示。
在开始阶段707中，每个参与的应用程序(例如700)使用其登记的策略 Id和应用程序接收的消息Id执行事务代理703以启动事务711。事务代理703 根据策略创建新事务或加入现有活跃的事务，参见717。如果事务代理决定创建事务，它将创建新的事务记录；如果事务代理决定加入现有的活跃事务，它将检索现有的事务记录。事务记录由事务记录表704中的策略标识符Id和消息标识符Id组合唯一标识。事务代理704使用策略管理器705如720所示检索策略记录706，以创建新的事务记录。事务代理使用应用程序Id将应用程序的状态更新为活跃(ACTIVE)，并将确认消息ACK返回到应用程序。一旦应用程序从事务代理接收到确认消息ACK，参见712，应用程序就开始处理消息并执行业务逻辑。如果不确认消息NACK，参见712，返回到应用程序，则应用程序无法启动或加入现有的事务。
在准备阶段708中，当参与的应用程序(例如700)基于策略准备好提交其操作时，参与的应用程序首先准备本地提交，然后准备提交全局事务713 以通过事务代理事务更新718事务记录。事务代理基于与事务相关联的策略来计算事务的状态。如果事务的结果状态是活跃(ACTIVE)/失败(FAILED)，则事务代理将不确认消息NACK，参见714，返回给应用程序。否则，事务代理将确认消息ACK，参见714，返回给应用程序。对于不确认消息NACK该应用程序回滚；对于确认消息ACK，应用程序继续提交。
在提交阶段708中，当基于策略全局事务准备好提交时，每个参与的应用程序(例如，700)执行本地提交，然后通过事务代理703提交全局事务715，事务代理更新事务记录719。事务代理703将确认消息ACK或不确认消息 NACK 716返回给应用程序。如果应用程序收到确认消息ACK，它将继续处理；否则需要恢复过程。一旦处于准备(PREPARED)状态的全局事务和/或一个或多个参与的应用程序完成提交，如果系统中的任何组件(包括事务管理器或策略管理)失败，或者任何参与的应用程序无法提交，则需要回滚或恢复过程。
图8描绘了基于策略的分布式全局事务系统中的参与应用程序的开始处理。框821是参与应用程序的处理流程，框822是事务代理程序的处理流程。参与应用程序801使用与策略相应的策略标识符Id和应用程序接收的消息标识符Id来启动事务802。应用程序执行事务代理830，处理803通过使用行业标准接口(例如，数据库系统支持的JDBC)用策略标识符Id和消息标识符 Id 804从事务记录数据库805中检索事务记录。判断处理806确定事务记录数据库是否包含与策略Id和消息Id相关联的任何活跃事务记录；如果没有找到这样的活跃事务记录，则处理转移到步骤807；否则转移至步骤810；处理807 使用策略记录数据库808中的策略Id来引用策略记录，并创建新的事务记录；处理809初始化事务记录并转移至步骤812；处理810基于策略评估事务记录的状态，在表811中列出可能的有效合法评估状态。处理812更新内存中的事务记录，将其持久保存到事务记录数据库/存储器，并返回处理参与的应用程序801，参与的应用程序801进入评估步骤815，评估处理815评估事务的状态是否健康；如果事务的状态是活跃(ACTVE)/失败(FAILED)，则评估处理815转移移到步骤816；否则，事务的状态是活跃(ACTIVE)，评估处理 815进入步骤818以继续处理剩余的业务逻辑；评估处理819评估在处理期间是否发生任何异常或错误，如果没有异常或错误发生，则该过程转到图9进一步处理；否则，该过程移动到步骤816，回滚事务817(参见图11)。
图9描绘了基于策略的分布式全局事务系统的请求-提交/准备-提交处理。 917是参与应用程序的处理流程，918是事务代理程序的处理流程。当参与应用程序901根据策略满足准备提交的条件时，参与应用程序901请求提交。处理902准备对本地资源的提交并更新应用程序的状态。判定处理903测试在准备本地提交期间是否发生异常或错误；如果发生任何异常或错误，则判定903 进入915处理，回滚参与的应用程序；否则，决策进入904事务代理。参与的应用程序执行事务代理904以准备全局事务905，事务代理906用事务Id从事务记录数据库907来检索事务记录。910基于策略评估事务的状态。表908列出了事务的可能有效合法状态。911更新事务记录在内存中，将其持久保存到事务数据库907中，然后将处理转移回参与的应用程序901，901将处理转移到913。913测试事务状态是否健康；如果事务的状态是活跃(ACTIVE)，则913进入到914以进行进一步处理；否则处理转移至915回滚事务(参见图 11)。
图10描绘了基于策略的分布式全局事务系统的提交处理。1004是参与应用程序的处理流程，1006是事务代理程序的处理流程。当全局事务基于策略准备好提交时，参与应用程序1001提交本地事务或资源1002，更新应用程序在内存中的状态，并执行事务代理1007以更新事务记录。事务代理1007执行 1008，用事务Id从事务记录数据库1010来检索与该应用程序相关联的当前事务记录。1009用应用程序的新状态根据图5中的策略评估事务状态，更新内存中的事务记录，并将其保存到事务记录数据库1010中。1009将事务转移回参与的应用程序1001并且处理结束。
图11描述了基于策略的分布式全局事务系统的回滚处理。1104是参与应用程序的处理流程，1105是事务代理的处理流程。当参与应用程序失败或事务管理器根据策略请求参与应用程序回滚时，参与应用程序1101回滚本地事务或本地资源1102并执行事务代理1106。事务代理1106用事务Id 1107从事务记录数据库1108中检索与此应用程序关联的当前事务记录。1109用应用程序的新状态根据图5中的策略评估事务状态。结果状态为活跃/失败或回滚 117。1110更新内存中的事务记录，并将其保存到事务记录数据库1108。1110将处理转移回参与的应用程序块1101。处理1103完成。
图12描述了基于策略的分布式全局事务系统的故障恢复处理。分布式系统可能以任何方式崩溃，任何参与的应用程序可能在处理过程中崩溃，例如，无法准备提交、无法提交、服务器系统可能崩溃、消息管理器可能崩溃、涉及分布式处理的网络连接可能会断开、任何未经处理的软件可能发生错误。任何故障都可能导致分布式系统的不一致。任何重新启动的参与应用程序都必须执行故障恢复过程，以将系统恢复到原始一致状态。图11由故障恢复处理流程的两部分组成。1213是参与应用程序的处理流程，1211是事务代理的处理流程。参与的应用程序1201在失败后重新启动。应用程序1201通过事务代理 1205执行故障恢复处理。处理1206用策略Id和应用程序Id从事务记录数据库1207中检索最新的活跃事务记录。这是系统失败时未完成的活跃事务。按照定义，事务记录是线程安全的。一次只有一个恢复进程更新事务记录。1208 根据图5中定义的策略评估事务记录的状态。合法状态为提交 (COMMITTED)、活跃/准备(ACTIVE/PREPARED)、活跃/失败 (ACTIVE/FAILED)和回滚(ROLLEDBACK)。如果从数据库中检索到的事务记录的状态与1208计算的状态不同，则表明系统存在不一致。1209用新状态更新事务记录，并将其保存到事务记录数据库1207。1209将处理返回到参与的应用程序1201。1201使用以下算法确定如何恢复参与的应用程序和故障系统：
如果事务的状态是活跃(ACTIVE)
每个参与申请的状态应为活跃(ACTIVE)或非活跃(INACTIVE)
1201前进到1202以继续处理
否则，如果事务的状态为提交(COMMITTED)或回滚(ROLLEDBACK)
应用程序的状态应为提交(COMMITTED)或回滚(ROLLEDBACK)
1201前进到1202以继续处理
否则事务状态为活跃(ACTIVE)/准备(PREPARED)
如果应用程序状态为准备(PREPARED)
1201前进到1204以执行提交
否则应用程序的状态是活跃(ACTIVE)或非活跃(INACTIVE)
1201前进到1202以继续处理
否则事务状态为活跃(ACTIVE)/失败(FAILED)
如果应用程序状态为失败(FAILED)或准备(PREPARED)
1201进入1023以执行回滚
否则应用程序的状态是回滚(ROLLEDBACK)
1201前进到1202以继续处理
否则应用程序的状态为非活跃(INACTIVE)或活跃(ACTIVE)
1201前进到块1202以继续处理
每个参与的应用程序执行故障恢复过程以保持分布式系统的全局一致性。
尽管前面对本发明优选实施例的描述已经示出，描述或说明了本发明的基本新颖特征或原理，但应理解的是，方法细节形式的各种省略，替换和变化，在不脱离本发明的精神的情况下，本领域技术人员可以做出如图所示的元件或装置及其用途。因此，本发明的范围不应限于前述描述。相反，本发明的原理可以应用于广泛的方法，系统和装置，以实现本文描述的优点并且实现其他优点或者也满足其他目的。

Claims (16)

1.一种基于策略管理的分布式全局事务处理系统，其特征在于，包括：
一个或多个可配置的策略记录，每个该策略记录存储事务的定义信息，二个或多个参与事务处理的应用程序的信息，以及一个或多个指定每个该应用程序在该事务处理中需要遵循的确保事务完整性的规则；
参与事务处理的应用程序通过计算机可执行程序实现，该应用程序为随时间生成消息的消息产生程序或是随时间从其订阅的消息产生程序接收消息的消息消费程序，且参与事务处理的该应用程序在更新事务的处理状态和/或事务的策略记录时，独立于参与该事务处理的其他应用程序；
消息管理器，用于随时间接收并存储该消息产生程序生成的消息，并将该消息分发给订阅该消息的消息消费程序；以及
事务状态记录，用于记录所参与的应用程序处理该事务处理的状态；
其中，每个参与应用程序基于事务策略启动新事务处理或加入现有事务处理，一个或多个消息消费程序处理其订阅的一个或多个消息，更新其在该事务状态记录中的状态，并检查该事务策略记录以确定其进行的下一个操作，这整个事务处理过程中每个参与应用程序处理独立于该其他应用程序。
2.如权利要求1所述的分布式全局事务处理系统，其特征在于，该事务处理规则包括：
对于一个全局事务处理，在由该事务处理策略记录定义的事务边界时间内，根据事务处理状态记录要求所有参与该事务处理的应用程序提交了事务处理操作，该全局事务才做好提交全局事务处理操作的准备；
每个参与该事务处理的应用程序根据该事务状态的记录做好提交该事务处理操作的准备，并更新其在该事务状态记录中的状态以，记录该应用程序已做好提交该处理操作的准备，该事务状态记录表示所有参与该事务处理的应用程序更新其在该事务状态记录中的状态并做好了提交事务处理操作的准备；
每个参与该事务处理的应用程序并在该事务边界时间内提交该处理操作并更新其在该事务状态记录中的状态。
3.如权利要求2所述的分布式全局事务处理系统，其特征在于，该策略的事务处理规则还包括：
当一个或更多的应用程序无法进行该事务处理，或在由该事务处理策略记录定义的事务边界时间内未能完成该事务处理，则确认该全局事务处理失败，当全局事务处理失败，每个参与该事务处理的应用程序要求回滚其事务处理；
当该全局事务处理失败时，已进行该事务处理的应用程序根据该事务状态记录，返回到进行该事务处理前的状态以完成回滚操作。
4.如权利要求1所述的分布式全局事务处理系统，其特征在于，该策略记录的事务处理规则还定义：
根据事务状态记录的检测，当一个或多个参与该事务处理的应用程序失败时，参与该事务处理的应用程序停止进行该事务处理并进行回滚操作。
5.如权利要求1所述的分布式全局事务处理系统，其特征在于，还包括事务状态通知器，当该事务状态记录被更新时，该事务状态通知器通知所有参与该事务处理的应用程序。
6.如权利要求1所述的分布式全局事务处理系统，其特征在于，每个参与该事务处理的应用程序基于该策略记录的规则执行故障恢复操作。
7.如权利要求1所述的分布式全局事务处理系统，其特征在于，还包括策略管理器，用于通过接收来自用户界面或API接口的输入，生成或编辑事务的策略记录的内容，该内容包括事务信息、规则和事务边界时间。
8.如权利要求1所述的分布式全局事务处理系统，其特征在于，还包括策略管理器，任何一个参与应用程序访问事务的策略记录，通过该策略管理器编辑该策略记录的部分或全部内容，该内容包括事务信息、规则和事务边界时间。
9.一种基于策略管理的分布式全局事务处理方法，其特征在于，包括：
使用一个或多个可配置的策略记录来存储事务信息，并指定一个或多个参与的应用程序包含在事务处理中，并定义每个参与的应用程序需要遵守的一个或多个规则，一个或多个规则在处理事务中确保事务的完整性，其中每个参与的应用程序由计算机程序实现，应用程序为随时间生成消息的消息生成程序或随时间从其订阅的消息生成程序接收消息的消息消费程序；
该一个参与应用程序在更新事务的处理状态和/或更新该事务的可配置策略记录时，独立于参与该事务处理的其他应用程序；
使用消息管理器随时间接收并存储一个或多个消息生成程序生成的消息，并将该消息分发给订阅该消息的义个或多个消息消费程序；
参与应用程序记录事务处理的状态于该事务处理的状态记录；
其中，每个参与应用程序基于策略在启动事务处理或加入事务处理，处理其订阅的消息，更新其在该事务状态记录中的处理状态，并检查策略记录以确定其进行的下一个操作时，异步执行并独立于该策略的其他参与应用程序。
10.如权利要求9所述的分布式全局事务处理方法，该事务处理规则包括：
对于一个全局事务处理，在由该事务处理策略记录定义的事务边界时间内，根据事务处理状态记录要求所有参与该事务处理的应用程序提交了事务处理操作，此全局事务才做好提交全局事务处理操作的准备；
每个参与该事务处理的应用程序根据该事务状态的记录做好提交该事务处理操作的准备，并更新其在该事务状态记录中的状态以，记录该应用程序已做好提交该处理操作的准备，该事务状态记录表示所有参与该事务处理的应用程序更新其在该事务状态记录中的状态并做好了提交事务处理操作的准备
每个参与该事务处理的应用程序并在该事务边界时间内提交该处理操作并更新其在该事务状态记录中的状态。
11.如权利要求9所述的分布式全局事务处理方法，其特征在于，该策略的事务处理规则还包括：
当一个或更多的应用程序无法进行该事务处理，或在由该事务处理策略记录定义的事务边界时间内未能完成该事务处理，则确认该全局事务处理失败，当全局事务处理失败，每个参与该事务处理的应用程序要求回滚其事务处理；
当该全局事务处理失败时，已进行该事务处理的应用程序根据该事务状态记录返回到进行该事务处理前的状态以完成回滚操作。
12.如权利要求9所述的分布式全局事务处理方法，其特征在于，该策略记录的事务处理规则还定义：
根据事务状态记录的检测，当一个或多个参与该事务处理的应用程序失败时，参与该事务处理的应用程序停止进行该事务处理并进行回滚操作。
13.如权利要求9所述的分布式全局事务处理方法，其特征在于，还包括事务状态通知器，当该事务状态记录被更新时，事务状态通知器通知所有参与该事务处理的应用程序。
14.如权利要求9所述的方法，其特征在于，每个参与该事务处理的应用程序基于该策略记录的规则执行故障恢复操作。
15.如权利要求9所述的分布式全局事务处理方法，其特征在于，还包括策略管理器，用于通过接收来自用户界面或API接口的输入，生成或编辑事务的策略记录的内容，该内容包括事务信息、规则和事务边界时间。
16.如权利要求9所述的分布式全局事务处理方法，其特征在于，还包括策略管理器，任何一个参与应用程序访问事务的策略记录，通过该策略管理器编辑该策略记录的部分或全部内容，该内容包括事务信息、规则和事务边界时间。
CN201910785928.8A 2018-12-21 2019-08-23 基于策略管理的分布式全局事务处理系统和方法 Pending CN111352704A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/228,769 US20200201834A1 (en) 2018-12-21 2018-12-21 Systems and methods of efficient extensions of relational tables in a database
US16/228,769 2018-12-21

Publications (1)

Publication Number Publication Date
CN111352704A true CN111352704A (zh) 2020-06-30

Family

ID=71097149

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910785928.8A Pending CN111352704A (zh) 2018-12-21 2019-08-23 基于策略管理的分布式全局事务处理系统和方法

Country Status (2)

Country Link
US (1) US20200201834A1 (zh)
CN (1) CN111352704A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113518384A (zh) * 2021-07-29 2021-10-19 中移（杭州）信息技术有限公司 分布式事务处理方法、装置、设备及计算机可读存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11249963B2 (en) * 2019-07-22 2022-02-15 Salesforce.Com, Inc. Maintaining foreign key references across domains
CN115510021B (zh) * 2022-06-29 2023-12-22 江苏昆山农村商业银行股份有限公司 一种构建数据仓库标准层的方法和系统

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6105147A (en) * 1997-04-16 2000-08-15 Compaq Computer Corporation Using process pairs as transaction-coordinated resource managers
CN101945056A (zh) * 2009-06-29 2011-01-12 软件Ag公司 基于策略的jms中间件群的系统和/或方法
CN102346460A (zh) * 2011-05-27 2012-02-08 运软网络科技(上海)有限公司 一种基于事务的服务控制系统及其控制方法
US20130160022A1 (en) * 2011-12-19 2013-06-20 International Business Machines Corporation Transaction manager for negotiating large transactions
CN103995868A (zh) * 2014-05-20 2014-08-20 科大国创软件股份有限公司 面向分布式系统的全局事务管理器及事务处理方法
US20160042023A1 (en) * 2014-05-29 2016-02-11 Splice Machine, Inc. Transaction execution commitment without updating of data row transaction status
CN105608086A (zh) * 2014-11-17 2016-05-25 中兴通讯股份有限公司 分布式数据库系统的事务处理方法及装置
US20160179875A1 (en) * 2014-12-18 2016-06-23 International Business Machines Corporation Reliability improvement of distributed transaction processing optimizations based on connection status
CN106775959A (zh) * 2016-12-06 2017-05-31 上海亿账通互联网科技有限公司 分布式事务处理方法和系统
US20170308563A1 (en) * 2016-04-21 2017-10-26 International Business Machines Corporation Temporal Logical Transactions

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6105147A (en) * 1997-04-16 2000-08-15 Compaq Computer Corporation Using process pairs as transaction-coordinated resource managers
CN101945056A (zh) * 2009-06-29 2011-01-12 软件Ag公司 基于策略的jms中间件群的系统和/或方法
CN102346460A (zh) * 2011-05-27 2012-02-08 运软网络科技(上海)有限公司 一种基于事务的服务控制系统及其控制方法
US20130160022A1 (en) * 2011-12-19 2013-06-20 International Business Machines Corporation Transaction manager for negotiating large transactions
CN103995868A (zh) * 2014-05-20 2014-08-20 科大国创软件股份有限公司 面向分布式系统的全局事务管理器及事务处理方法
US20160042023A1 (en) * 2014-05-29 2016-02-11 Splice Machine, Inc. Transaction execution commitment without updating of data row transaction status
CN105608086A (zh) * 2014-11-17 2016-05-25 中兴通讯股份有限公司 分布式数据库系统的事务处理方法及装置
US20160179875A1 (en) * 2014-12-18 2016-06-23 International Business Machines Corporation Reliability improvement of distributed transaction processing optimizations based on connection status
US20170308563A1 (en) * 2016-04-21 2017-10-26 International Business Machines Corporation Temporal Logical Transactions
US20170371911A1 (en) * 2016-04-21 2017-12-28 International Business Machines Corporation Temporal Logical Transactions
CN106775959A (zh) * 2016-12-06 2017-05-31 上海亿账通互联网科技有限公司 分布式事务处理方法和系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
徐进;黄勃;冯炯;: "基于消息通信的分布式系统最终一致性平台", 计算机应用, no. 04, 10 April 2017 (2017-04-10) *
王成良;李立新;叶剑;秦小龙;: "一种基于JMS的分布式异步事务处理模型设计", 信息工程大学学报, no. 02, 15 April 2010 (2010-04-15) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113518384A (zh) * 2021-07-29 2021-10-19 中移（杭州）信息技术有限公司 分布式事务处理方法、装置、设备及计算机可读存储介质
CN113518384B (zh) * 2021-07-29 2023-12-01 中移（杭州）信息技术有限公司 分布式事务处理方法、装置、设备及计算机可读存储介质

Also Published As

Publication number Publication date
US20200201834A1 (en) 2020-06-25

Similar Documents

Publication Publication Date Title
CN108459919B (zh) 一种分布式事务处理方法及装置
CN109739935B (zh) 数据读取方法、装置、电子设备以及存储介质
WO2018103318A1 (zh) 分布式事务处理方法和系统
US8880486B2 (en) Distributed database system utilizing an extended two-phase-commit process
WO2016180164A1 (zh) 一种分布式事务回滚方法及装置
EP2754284B1 (en) Idempotence for database transactions
US7640249B2 (en) System and method for transactional session management
US20200226011A1 (en) Policy-based distributed transactional processing in a distributed system
US7900085B2 (en) Backup coordinator for distributed transactions
JP3790589B2 (ja) 分散データベーストランザクションのコミットメント方法
US20130297566A1 (en) Recovering stateful read-only database sessions
KR101993432B1 (ko) 2-단계 커미트 호출들의 엄격한 순서화에 근거하여 트랜잭션 복구를 지원하는 시스템들 및 방법들
US9106480B2 (en) Performing computations in a distributed infrastructure
CN111352704A (zh) 基于策略管理的分布式全局事务处理系统和方法
US20110246822A1 (en) Transaction participant registration with caveats
CN112148436B (zh) 去中心化的tcc事务管理方法、装置、设备及系统
CN110413687B (zh) 基于节点互证校验的分布式事务故障处理方法及相关设备
US20120011100A1 (en) Snapshot acquisition processing technique
WO2015062200A1 (zh) 一种分布式事务提交故障的处理方法、装置和系统
US9858312B2 (en) Transaction compensation for single phase resources
US20230110826A1 (en) Log execution method and apparatus, computer device and storage medium
US11522966B2 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
US11960478B2 (en) Database system with transactional commit protocol based on safe conjunction of majorities
CN114579260A (zh) 一种事务处理方法及系统
WO2019196227A1 (zh) 平台整合的方法、装置、计算机设备和存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination