CN108701157B - 分布式事务处理***中有保证的提交结果 - Google Patents

分布式事务处理***中有保证的提交结果 Download PDF

Info

Publication number
CN108701157B
CN108701157B CN201780014395.2A CN201780014395A CN108701157B CN 108701157 B CN108701157 B CN 108701157B CN 201780014395 A CN201780014395 A CN 201780014395A CN 108701157 B CN108701157 B CN 108701157B
Authority
CN
China
Prior art keywords
transaction
global
local
commit
session
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.)
Active
Application number
CN201780014395.2A
Other languages
English (en)
Other versions
CN108701157A (zh
Inventor
C·科尔雷恩
S·H·罗艾斯科
T·J·利特尔
P·帕金森
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.)
Oracle International Corp
Original Assignee
Oracle International Corp
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 Oracle International Corp filed Critical Oracle International Corp
Publication of CN108701157A publication Critical patent/CN108701157A/zh
Application granted granted Critical
Publication of CN108701157B publication Critical patent/CN108701157B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • 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/23—Updating
    • G06F16/2308—Concurrency control
    • 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/0745—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 an input/output transactions management context
    • 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/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • 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/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing

Landscapes

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

Abstract

描述了用于为全局事务提供有保证的提交结果的技术，这些全局事务通过使用优化将提交处理推迟到资源管理器(诸如DBMS)来进行优化。“分布式事务处理：XA规范”标准规范对于由DBMS管理的事务的提交结果是不明确的，从而导致实现该标准的供应商的错误结果。所描述的技术在使用优化时提供有保证的提交结果，从而在事务管理器和资源管理器之间发生通信错误或超时的时候创建安全重放全局事务的机会，并消除到达应用和最终用户的不明确的事务结果。

Description

分布式事务处理***中有保证的提交结果
技术领域
本发明涉及电子数据库管理领域。
背景技术
客户端应用可能响应于发出提交(commit)命令集的请求而从资源管理器接收到错误(诸如超时错误)。通常，客户端应用通过会话与服务器交互。如果对与服务器的会话的访问丢失，则应用将只能生成指示通信已经失败的错误消息。应用将无法向其可能包括其它应用的用户通知服务器是否已执行任何所请求的命令(并且如果是的话，则执行是否导致任何数据修改)，或者甚至还有服务器是否继续执行从客户端应用断开的所请求的命令。
在没有以有保证和可扩展的方式确定命令的结果的情况下，在错误(诸如通信损失或超时或任何其它错误)之后，应用将不知道所请求的命令的执行发生了什么。应用或用户可能尝试重试命令，这可能会通过递交重复的执行请求而导致逻辑损坏。
本部分中所描述的方法是可以追求的方法，但不一定是先前已经构思或追求的方法。因此，除非另有指示，否则不应该认为本部分中所描述的任何方法仅仅因为它们被包含在本部分中而有资格作为现有技术。
附图说明
在某些实施例的附图中，其中相同的附图标记在通篇的图中指代对应的部分：
图1A是图示实施例中的分布式事务处理***(DTPS)的框图。
图1B图示了在实施例中用于在DTPS中处理全局分布式事务的示例步骤。
图2是描绘在实施例中用于管理本地事务中的命令的执行的处理的流程图。
图3是描绘在实施例中用于管理全局两阶段事务的处理的流程图。
图4是描绘在实施例中用于管理单个阶段事务的处理的流程图。
图5是描绘在实施例中用于管理只读优化全局事务的处理的流程图。
图6是描绘在实施例中用于管理可提升事务的处理的流程图。
图7是图示可以在其上实现本发明的实施例的计算机***的框图。
具体实施方式
在以下描述中，出于解释的目的，阐述了许多具体细节以便提供对本发明的透彻理解。但是，显而易见的是，可以在没有这些具体细节的情况下实践本发明。在其它情况下，结构和设备以框图形式示出，以避免不必要地模糊本发明。
总体概述
本方法描述确定全局事务的结果，特别是当管理全局事务的事务管理器(TM)使用针对全局事务的优化时。如本文所引用的，“事务”是被提交(即，使其永久)或回滚(rollback)的原子(atomic)工作单元。事务可以包括可以包含用户界面、数据检索和通信的许多计算任务。事务可以是本地的和/或全局的。“全局事务”是指在分布式事务处理***(DTPS)中由任何数量的RM(“资源管理器”)执行的需要以原子方式提交的工作单元。“本地事务”是指要在单个RM上执行的工作单元，其可以包括被发送用于在与RM的本地会话中执行的命令集，使得命令当/如果在本地会话中执行时，将导致本地会话中针对RM的一个或多个事务。在本地会话中执行该命令集可能有助于正在进行的全局事务。如本文所引用的，资源管理器(RM)是管理共享计算资源并通过在***上运行的服务向连接客户端应用(诸如TM)提供对共享资源的访问的***。
在一些实施例中，当使用优化时，事务管理器可能具有有限的能力来确定是否已执行命令(诸如全局事务的提交命令)、何时发生了错误(诸如通信错误或超时错误)。例如，一阶段(one-phase)提交操作不需要如果发生通信错误或超时通信错误或超时或超时，TM可以使操作回滚的准备阶段。类似地，可提升全局事务操作也在操作的事务被提升为全局事务之前缺少准备阶段。因此，一阶段提交操作以及可提升全局操作对可能导致用户沮丧、客户支持呼叫和机会丧失的不明确(ambiguous)错误(诸如通信错误或超时错误)带来了特定挑战。
优化的全局事务(本文也称为“优化”)是通过将事务的控制推迟到RM(诸如数据库管理***(DBMS))来避免全局事务管理的开销的那些事务。优化的全局事务的示例是单个阶段、只读、最后的资源优化和可提升的全局事务。现有的全局事务协议，诸如“分布式事务处理：XA规范(Distributed Transaction Processing:The XA Specification)”中描述的XA协议，在关于当通过RM使用本地提交优化时确定全局事务的提交结果方面是不明确的。从客户端应用的角度来看，当在事务重做被持久性写入之后生成的表示事务(本地或全局)完成的RM消息(本文称为“提交结果”)被客户端应用接收到时，事务被提交。虽然提交结果在完成事务的RM处是确定性的，但是提交结果的消息不是可持续的。在正常处理期间，当事务在RM处被成功提交时，提交消息被返回到确认提交的客户端应用。相反，如果事务被RM回滚，则被返回到客户端的提交结果消息表示事务的回滚。但是，当在递送提交结果消息期间发生错误(诸如***、网络或存储中断)时，客户端应用接收错误消息，并且不知道事务是否被提交。许多客户端应用错误地认为接收到错误表示RM处的事务失败，并重复事务中的命令从而导致重复提交。此外，提交结果中的不明确性可能导致向实现规范的***报告错误的提交结果。本文描述的技术解决了在使用全局事务及其优化时的不明确提交结果，并且还允许这种事务的安全重放。下面描述的图1B进一步图示了实施例中的不明确提交结果。
在实施例中，技术区分由事务管理器管理的会话中的全局事务和由资源管理器(诸如DBMS)管理的同一会话中的本地事务。当DBMS管理命令时，这些技术提供对命令结果的确定。当事务管理器(而非DBMS)正在协调事务时，这种本地管理控制失效。切换DBMS和TM之间的事务的控制和管理允许在发生通信错误或超时之后确定命令执行的结果。
分布式事务处理***
图1A描绘了实施例中的操作环境中的分布式事务处理***(DTPS)100。DTPS 100可以包括事务管理器(TM)120和连接到TM 120的多个资源管理器(RM)。作为一个示例，RM可以是数据库管理***(DBMS)130，其包括托管数据库146的数据库服务器140。数据库146可以与事务历史表142耦合，事务历史表142保持跟踪在数据库146上发生的所有事务。在下面的“数据库管理服务器”部分中提供了对DBMS的进一步描述。
在实施例中，DTPS 100可以包括其它类型的RM。RM的另一个示例RM 132可以是服务数据请求的基于SOAP的web服务，而RM 134可以是基于专有协议的数据访问点。为了管理与这些不同类型的RM的事务，TM 120可以利用管理与RM的分布式事务的特殊协议。在实施例中，这种协议是由Open
Figure BDA0001783453870000041
定义的并在“分布式事务处理：XA规范”中描述的XA协议，该协议的内容通过引用并入本文。
在实施例中，DTPS 100的客户端可以向TM 120发出各种数据请求，TM 120可以将这些请求转换为到RM的全局事务。客户端104或应用服务器110可以发出可能需要由多个RM原子地执行的数据操纵请求。响应于该请求，TM 120可以向一个或多个RM(诸如DBMS 130、RM 132和RM 134)发出全局事务以执行客户端的数据请求。TM 120可以包括存储在存储器中的一个或多个数据结构，这里描述为TM日志(log)126，用以存储要由TM在控制和恢复全局事务时使用的各种事务数据。
客户端与DTPS 100的交互可以通过示例来图示，其中应用服务器110托管航班预订web应用，DBMS 130管理航班预订数据库，并且RM 132处理支付的验证和处理。web应用的用户可以通过在web应用上选择航班并输入支付信息来预订航班。在处理用户递交的信息时，应用服务器110可以请求TM 120原子地执行数据操纵操作以在DBMS 130上为用户预订航班并用RM 132处理支付。为了确保该请求的原子性，TM 120可以使用XA协议向RM 132和管理数据库146的DBMS 130发出全局事务。
在另一个示例中，自助服务终端(kiosk)客户端104处的用户可能正在检查航班。由于这样的请求不需要支付信息，因此不需要利用RM 132的任何事务，客户端104可以直接建立与DBMS 130的会话并使用一个或多个SQL语句请求数据操纵操作。无论是使用单个RM还是多个RM，事务都可能需要原子性。例如，如果作为办理登机的一部分，用户还正在选择要办理登机的行李的数量，则对于一般航班办理登机的数据操纵和对于行李数量的数据操纵可能需要请求的原子执行。因此，客户端104可以绕过TM 120建立与DBMS 130的会话，并且通过本地事务发出数据操纵命令以确保执行中的原子性。
可替代地，客户端104仍然可以利用TM 120来完成相同的数据请求。TM 120可以利用具有单个DBMS 130源的全局事务用于执行请求。使用TM 120可以允许客户端104向用户供应包括利用RM 132来支付操作的选项。例如，可以向用户供应升级到头等舱或更改她的航班，这是可能涉及用户的附加支付的事务。另外，将TM 120用于单个资源全局事务简化了用于请求数据操纵的web应用逻辑，因为可以将相同类型的请求发送到TM 120以执行单个RM事务而不是多个RM事务。
分布式事务处理***的功能概述
图1B图示了在实施例中用于在分布式事务处理***中处理全局分布式事务的示例步骤。在步骤152中，客户端104通过请求开始与TM 120的事务来发起全局事务。在步骤160中，TM 120请求与客户端104已为其发起事务的RM的新连接。响应于步骤161中的请求，RM(诸如DBMS 130)对请求进行认证，并且如果成功，则在步骤162中向TM 120返回与有效事务控制(LTXID)的连接，如在本说明书的后面部分中更详细地描述的。与RM的连接的成功认证在TM和RM之间建立会话。因此，术语“会话”可互换地用于指代与RM的认证连接。
在步骤163中，TM 120分配用于全局事务的XID。在步骤164中，TM 120使用所分配的XID来启动利用RM(诸如DBMS 130)的全局事务。在步骤170中，一旦在DBMS 130上发起全局事务，DBMS 130就返回成功。在实施例中，作为全局事务发起的原子部分，使用本说明书的后面部分中描述的技术使本地事务控制失效。
在步骤154中，通过TM 120，客户端104发出如下所述的事务命令集以在DMBS 130上执行。反过来，在步骤172中，DBMS 130返回执行的状态。然后，TM 120可以在步骤166中使用所分配的XID结束全局事务。在成功结束事务之后，在步骤174中，DBMS 130返回成功。在实施例中，作为结束全局事务的原子部分，本地事务控制使用本说明书的后面部分中描述的技术而生效并在步骤174中作为成功消息的一部分被返回给TM。
在完成事务数据库命令集之后，在步骤156中，客户端104请求TM 120提交由事务命令集产生的变化。在步骤168中，基于下面描述的优化，TM 120可以确定不发出用于全局事务的任何准备命令，而是发出一阶段提交请求。
在TM 120发送提交请求之后，可能发生通信错误或超时，这可能阻止TM 120确定提交请求的结果。“通信错误或超时”(或简称“错误”)在本文中被定义为阻止RM客户端与RM通信并因此导致在RM客户端处缺少关于RM的状态信息的任何故障。通信错误或超时可能是由RM或RM客户端内的故障或连接RM客户端与RM的网络中的故障造成的。
示例180图示了在步骤168中的提交请求之后TM 120和DBMS 130之间的这种通信错误或超时。TM 120在步骤178中接收到错误，而没有步骤168的提交请求是否已被DBMS130成功执行的任何信息。事实上，提交可能已在步骤176中被成功执行。但是，如果TM 120在步骤159中向客户端104报告了不明确的错误，则客户端104可能向TM 120重新发出整个事务，这将导致相同的更改在DBMS 130上被应用两次的非期望状态。另一方面，如果步骤176中的提交没有发生但是客户端104假设尽管接收到错误但提交成功，则当实际上事务未被提交时，客户端104将错误地向用户报告事务已被提交。
如在本说明书的后面部分中更详细描述的，作为替代，DBMS 130可以解析提交结果并报告准确的提交结果。在实施例中，作为步骤176中的提交的原子部分，本地事务控制被检查并保持有效。在步骤191中，TM 120请求新连接，并且在步骤192中由DBMS 130成功使请求生效之后，在步骤193中，作为响应，接收与新本地事务控制的请求连接。在步骤194中，使用该新连接，TM 120请求在步骤168中用于请求提交的本地事务控制的提交结果。作为响应，在步骤195中DBMS 130使用下面描述的技术实施提交结果，并且DBMS 130在步骤196中将提交结果返回到TM 120。在TM 120接收到提交结果之后，TM 120在步骤158中向客户端104报告全局事务的状态。基于准确的结果信息，客户端104能够准确地响应通信错误或超时并采取补救动作。
管理DBMS上的本地事务
根据一个实施例，用于利用DBMS的客户端的本地事务的事务命令集可以由该DBMS管理以确保事务的幂等性(idempotence)。关于DBMS的“客户端”还可以包括全局事务的事务管理器(TM)。DBMS的本地事务管理在于2012年4月16日提交的申请号为8,984,170的美国专利“Idempotence for Database Systems”和于2012年7月31日提交的申请号为8,725,882的美国专利“Masking Server Outages from Clients and Applications”中描述，这些专利的全部内容通过引入并入本文。
在实施例中，当为连接到DBMS的客户端创建会话时，还创建新的逻辑事务句柄(handle)。为每个数据库会话分配逻辑事务句柄，并且逻辑事务句柄存在于DBMS上，且在客户端处保持副本。逻辑事务句柄唯一地定义事务命令集，并且用于确定最后一个事务命令是否被提交，并且如果最后一个事务命令确实被提交，则确定该提交是否完成。逻辑事务句柄是DBMS的幂等性语义的基础。
在实施例中，当发生与DBMS的通信错误时，可以使用逻辑事务句柄来确定事务命令集的提交结果。由于逻辑事务句柄在该会话上有效的下一个事务之前可用，因此在事务由DBMS而不是TM管理的情况下，客户端知道用于确定提交结果的逻辑事务句柄。虽然在一些实施例中，全局事务由TM管理并且TM确定结果，但是在使用性能优化的情况下，DBMS确定结果。在没有逻辑事务句柄的情况下，当在提交阶段发生通信错误或超时的时候，TM不再知道结果。
逻辑事务句柄的示例是逻辑事务标识符(“LTXID”)。LTXID是从客户端角度来看唯一地定义具体数据库本地事务的全局唯一标识符。在实施例中，本地事务的LTXID可以在会话内被创建并被保持在存储器中的用户会话结构中，并且然后可以由DBMS返回给客户端。在会话被认证时并且在事务可以开始之前，LTXID被返回给客户端。在DBMS而非TM的每次提交操作之后，新的LTXID被返回给客户端。因此，确保客户端在该会话中的任何事务之前具有LTXID。在实施例中，DBMS可以从会话中的客户端接收多个事务命令集。每个事务命令集可以对应于DBMS上的本地事务。如果提交了与接收到的命令集对应的本地事务，则LTXID作为该提交操作的一部分与本地事务相关联地存储在DBMS中的事务历史表中，诸如事务历史表142。然后LTXID可以针对会话中下一个接收到的事务命令集递增，并通过该提交操作被返回给客户端。然后，客户端为该会话中的本地事务保持下一个LTXID。如果存在已提交但对DBMS的事务请求尚未完成的本地事务，则存储的信息指示哪个命令集处于中间提交状态或嵌入提交状态。在相关的实施例中，DBMS将这样的信息存储在事务历史表中，该表包括在会话中提交的多个事务命令集中的每个事务命令集的条目。在一个实施例中，DBMS可以通过更新该会话的存储器中(in-memory)LTXID来更新存储器中信息以指示本地事务已经开始。当本地事务提交时，事务历史表被更新。
图2是描绘在实施例中用于管理本地事务中的命令的执行的处理的流程图。在方框201处，DBMS客户端(诸如TM)在DBMS对TM进行认证之后请求并获得来自DBMS的连接。DBMS创建具有有效状态的本地事务句柄，并以LTXID的形式将此本地事务句柄返回给客户端。在实施例中，如果发生通信错误，则LTXID使得客户端能够确定该连接处的下一个事务的提交结果。当客户端请求与DBMS的新事务时，客户端可以接收要使用的后续句柄。在实施例中，随着客户端发出各种命令，DBMS然后继续使本地事务句柄生效和失效。在实施例中，导致事务句柄的有效性更改的命令是原子操作，并且这些命令在与导致更改的调用相同的往返中被返回给客户端。
在方框202处，DBMS接收用于在会话中执行的命令集。例如，DBMS可以接收命名一系列要由DBMS执行的一个或多个SQL命令的请求。在方框204处，DBMS确定命令集中的命令(如果被执行)是否将启动至少一个本地事务。如果该命令不会启动本地事务，则在方框206处，DBMS确定该命令集是否包括任何其它命令。如果该命令将启动本地事务，则DBMS针对第二命令重新执行方框204。如果DBMS从未到达启动本地事务的命令，则在方框208处，DBMS完成该命令集的执行，而无需为该命令集注册或更新事务信息，诸如LTXID。在另一个实施例中，即使在该命令集中不存在本地事务，DBMS也存储对LTXID的临时存储器中更新，但是除非DBMS提交本地事务，否则临时更新不会被提交。
另一方面，如果DBMS确定命令集中的下一个命令(如果被执行)将启动本地事务，则在方框210处DBMS注册如果本地事务被提交则LTXID将被记录。DBMS继续执行该命令集，直到打开的本地事务在方框212处被提交为止。当提交时，如果之前LTXID尚未被存储，则LTXID被***到事务历史表中。否则，更新现有LTXID的条目。在一个实施例中，DBMS使用每次提交时更新的LTXID来保持跟踪该命令集内的每个提交的本地事务。在另一个实施例中，DBMS仅保持跟踪该命令集中是否存在至少一个提交的事务。在提交打开的事务之后，在方框214处，DBMS***或更新LTXID以指示打开的本地事务已经被提交。在提交之后，生成要使用的下一个LTXID，并将该LTXID返回给DBMS客户端。
在一个实施例中，DBMS客户端在客户端和DBMS之间的每次往返期间向DBMS发送命令集以供执行。在包含提交的任何命令集之后，更新该命令集的LTXID以反映本地事务的完成。下一个要使用的更新后的LTXID可以由DBMS保持在每个服务器侧会话上。更新后的LTXID被发送到客户端，并且可以保持在客户端的会话的连接对象中。例如，LTXID可以与通过执行事务命令集获得的任何结果一起被发送到客户端。如果事务命令集中没有本地事务提交，则客户端具有在当前事务命令集之前客户端发送以供执行的先前事务命令集的LTXID。
在一个实施例中，任何提交都导致LTXID的增加以及向DBMS客户端返回新的LTXID。如果包含提交的命令集已经提交和完成，则在事务历史表中记录的LTXID(即，先前的LTXID)具有包括该命令集“完成”的状态或结果。在这个实施例中，每次提交都导致更新同一会话中的最后一个LTXID。在另一个实施例中，每个完成的事务命令集都导致更新同一会话上的最后一个LTXID。
在一个实施例中，会话的当前LTXID描述了要在会话中提交的下一个事务。DBMS可以以某种可预测的方式(诸如通过递增先前的LTXID)根据当前LTXID计算先前的LTXID。当DBMS向客户端发送与先前LTXID相关联的事务已提交的通知时，DBMS将DBMS客户端传递给DBMS计划使用的下一个LTXID。
在实施例中，DBMS客户端可以通过新会话连接到DBMS并请求本地事务的信息。该请求可以例如通过使用由客户端先前接收到的LTXID来识别特定的本地事务。DBMS可以确定该请求是否识别了在原始会话中被接收以供执行的最新事务命令集，即，接收到的LTXID对应于原始会话的事务历史表中的最高LTXID。如果不是的话，则DBMS可以向客户端通知客户端未与DBMS同步。
在相关的实施例中，DBMS还可以确定对应于本地事务的特定命令集是否已经提交。并且如果有任何未提交的话，则DBMS可以通过阻止由该LTXID识别出的本地事务进行提交来强制执行任何未提交状态，从而保证未提交状态的结果。未提交状态包括任何状态，其中如果原始会话已成功完成，则本地事务将在原始会话中提交，但由于原始会话未完成，因此本地事务还未提交。强制执行未提交状态防止未提交状态以后一旦另一个会话将未提交状态视为未提交时就被提交。一旦被阻止，DBMS就可以向DBMS客户端通知该逻辑事务ID识别出的命令集尚未提交(或者识别出的事件尚未发生)。在另一个实施例中，DBMS可以使得在第二会话中执行特定命令集，从而导致在原始会话被阻止之后在新会话中第一次发生本地事务或事件。
在相同的实施例中或在各种其它实施例中，DBMS可以确定是否已经丢失一些会话状态更改，和/或是否已经丢失DBMS客户端的结果。如果本地事务已经提交但是在提交之后还有更多工作要做，则DBMS可以向客户端指示提交处于中间“嵌入”状态。客户端可以使用已提交的状态，并且根据是否需要完成状态可以选择是否继续。
在通信错误或超时之后，客户端或其它DBMS客户端(诸如监视实用程序)可以连接到DBMS。然后，使用来自先前连接中的LTXID，客户端可以测试最后一次本地事务的结果。如果该本地事务未提交，则DBMS可以阻止该LTXID，因此阻止在重放之前已处于活动状态的使用该LTXID的早期机上本地事务提交。如果LTXID已经被提交，则阻止LTXID的尝试返回已提交，或者如果LTXID先前被阻止，则重复提交结果的请求将继续返回未提交(UNCOMMITTED)。这个处理是完全确定性的。
下表示出了在DBMS处理本地事务时维护LTXID的几个示例。
Figure BDA0001783453870000121
Figure BDA0001783453870000131
在另一个实施例中，提供了具有一个输入参数LTXID的公共接口GET_LTXID_OUTCOME，并且返回两个参数–已提交(COMMITTED)–具有值TRUE(真)或FALSE(假)，以及USER_CALL_COMPLETED–具有值真或假，以及当(通过调用GET_LTXID_OUTCOME)请求LTXID的结果时，包括CLIENT_AHEAD和SERVER_AHEAD的错误的错误代码。如果命令集中的任何命令提交，则本地事务的结果被确定为COMMITTED＝TRUE。如果提交是最后一次调用并且不需要将附加结果返回给DBMS客户端，则本地事务的结果被确定为USER_CALL_COMPLETED＝TRUE。
使用GET_LTXID_OUTCOME获得LTXID的结果
Figure BDA0001783453870000132
在实施例中，逻辑事务标识符(LTXID)可以包括用于任何类型的数据库(包括容器数据库、可插拔数据库或独立数据库)的唯一字段，以便检测故障转移是针对相同的数据库还是不同的数据库。包含这些字段的逻辑事务标识符被称为是“全局唯一的”。在其它实施例中，逻辑事务标识符还可以包括用于实例、会话、版本和/或服务的唯一字段。在一个示例中，逻辑事务id被传递并保持或存储在
Figure BDA0001783453870000141
调用接口(“OCI”)会话句柄或ODBC或ODP.Net会话句柄中或在瘦JavaTM数据库连接(“JDBC”)驱动程序的连接对象中。DBMS客户端保持DBMS计划使用的下一个逻辑事务id的副本。
在一个实施例中，LTXID包括：
·版本
·数据库标识符
ο包括用于整合数据库的可插拔数据库标识符
·数据库实例标识符
·逻辑会话号(GUID)
·提交号
·服务标识符
·状态
在会话建立时自动指配逻辑会话号(GUID)。在一个实施例中，GUID是不能被应用读取的不透明的结构。在一个实施例中，GUID对于事务历史生命是唯一的。
提交号唯一地识别同一数据库的同一会话的本地事务内的本地事务。在一个实施例中，一旦提交了先前的事务，就通过递增同一会话上先前本地事务的LTXID的提交号来生成LTXID的提交号。
状态指示对应于LTXID的事务命令集是否是全局事务的一部分，并且因此由TM而非DBMS管理。在一个实施例中，当事务命令集由DBMS管理时状态可以具有值VALID(有效)，而当事务命令集是全局事务的一部分时，状态可以具有值INVALID(无效)。
全局事务
事务管理器(TM)可以利用一个或多个资源管理器(RM)发起全局事务来服务来自客户端的请求。在实施例中，TM可以发起利用RM(诸如DBMS)执行全局事务，并且可以生成一个或多个标识符以识别和管理全局事务。一个这样的标识符，全局事务的唯一标识符在本文中被称为全局事务标识符(GTRID)。TM可以使用全局事务的GTRID来管理与全局事务相关联的事务命令集的执行。作为全局事务的一部分在RM上执行的每个事务命令集在本文中被称为“事务分支(branch)”。全局事务内的每个事务分支可以由本文称为事务分支限定符(BQUAL)的另一个标识符识别。可以将GTRID和BQUAL组合在一起以唯一地识别利用RM的全局事务中的事务分支。为简单起见，识别事务分支的GTRID和BQUAL的组合在本文中被称为“XID”。在各种实施例中，XID可以包含被编码在其值中的附加信息，诸如指示生成XID的TM的类型的格式标识符。
在一个实施例中，当TM发出用于在RM上执行的全局事务的第一事务分支时，TM可以不利用BQUAL来识别第一事务分支。TM和RM可以仅利用全局事务的GTRID识别第一事务分支。在相关的实施例中，全局事务可以由全局事务中涉及的每个RM的单个事务分支组成。因此，TM可以类似地识别具有全局事务的GTRID的事务分支。
在各种实施例中，GTRID、BQUAL和XID可以由TM、TM的客户端、RM或其组合中的任何一个生成。生成组件可以将GTRID、BQUAL和XID传送到TM和其它组件。例如，如果TM的客户端生成全局事务的GTRID，则客户端可以将GTRID传送到TM，TM进而可以将GTRID传送到RM。TM可以存储和维护事务分支的GTRID、BQUAL和XID之间的任何关联和所有关联。但是，为了简单起见，无论事务分支标识符是否由GTRID、BQUAL、XID或其组合组成，事务分支标识符都在本文中被称为XID。
在实施例中，TM可以建立与RM的会话以执行全局事务的事务分支。使用TM日志，TM可以通过事务分支的XID提取RM上的事务分支的状态，并使用与XID对应的数据用于恢复全局事务。在会话建立之后，TM可以向RM发信号通知该会话用于全局事务。例如，在XA协议中，TM可以发出XAstart命令，该命令包含要执行的事务分支的XID。
在实施例中，在接收到针对全局事务的命令之后，RM可以使本地事务控制失效。响应于会话建立，在从诸如TM的客户端接收到任何命令之前，RM可以生成本地事务句柄，诸如上面针对DBMS描述的LTXID。RM可以假定与客户端建立的任何会话可能需要RM的本地事务控制。RM将生成的本地事务标识符发送到TM以供TM解析TM可能接下来发送的命令的提交结果。虽然TM独立于RM管理要为全局事务发送的命令，但是RM可以通过利用本地事务句柄继续跟踪命令。当RM确定接收到的命令是全局事务的一部分时，RM可以使其自己的命令的本地事务控制失效。
如本文所使用的“本地事务控制”是指RM在提交处理期间在通信错误或超时的情况下管理和控制事务命令集的提交结果。当RM实行本地事务控制时，RM独自确保事务集的幂等性，并且是在发生通信错误或超时的时候用于确定事务的提交结果的唯一来源。“使本地事务控制失效”在本文中是指RM对TM产生全局事务的提交结果的有保证确定。对于全局事务，TM协调决定以提交事务或回滚事务、协调故障恢复、并在通信错误或超时之后报告事务的提交结果。
在实施例中，作为使本地事务控制失效的一部分，RM可以使本地事务控制的本地事务管理句柄(诸如可以存储在RM的存储器中的LTXID)失效。在失效后，RM可以将失效的本地事务句柄返回给TM。在一个实施例中，响应于失效命令，将本地事务句柄返回给TM，作为对导致失效的操作的确认的一部分。在其它实施例中，可以从导致失效的命令异步地返回失效的本地事务句柄。类似地，如果TM命令导致本地事务句柄生效，则在一些实施例中，生效的句柄可以作为确认的一部分被返回给TM，并且在其它实施例中，生效的句柄可以异步地被返回给TM命令。在进一步实施例中，失效的事务句柄可以在下次返回途中被返回给客户端，其可以晚于失效命令发生。当TM接收到失效的本地事务句柄时，如果TM或任何其它客户端使用失效的本地事务句柄来请求本地事务的管理任务，则RM可以忽略这种请求或者返回错误消息。代替使用本地事务管理句柄来确定事务集中的命令集的提交结果，TM可以利用作为事务分支的一部分被发送给RM的XID。
在实施例中，TM的客户端可以使用不透明的事务句柄来获得当该用户调用向客户端返回故障时从客户端到TM的最后一次用户调用的结果。响应于客户端针对TM发送在RM上执行的命令，客户端可以从TM接收不透明的事务句柄。客户端可以使用接收到的句柄从TM请求关于事务的信息。不透明句柄可以包含TM与事务相关联的唯一标识符。因此，客户端可能没有提交的最后一个用户调用的已知结果，并且可以使用提供给客户端的句柄向TM请求操作。在另一个实施例中，不透明事务句柄可以包含由TM用于事务的事务句柄，诸如XID或LTXID。因此，在其它实施例中，如果提供了RM，则客户端可以使用LTXID直接从RM查询事务。
在实施例中，RM本身可以使用XID跟踪命令的执行。在另一个实施例中，RM继续使用失效的本地事务句柄来跟踪命令，但维持本地事务句柄和XID之间的映射。在这样的实施例中，映射可以存储在存储器或持久性存储装置中的RM的事务历史表中。存储器中存储将提高访问映射的性能。
在实施例中，DBMS可以通过更改本地事务的LTXID的状态使对与TM的本地事务的提交结果的访问失效。在接收到全局事务命令之后，DBMS可以将与TM的会话的LTXID的状态从有效改变为无效。LTXID可以仍然与每个响应一起被返回给TM，但LTXID内的状态将表示DBMS对本地事务控制的有效性。一旦失效，TM或TM的客户端就可以不使用LTXID用于获得事务的提交结果。如果客户端或TM确实使用失效的LTXID请求提交结果，则在一个实施例中DBMS可以返回错误，或者在另一个实施例中DBMS可以忽略请求。
在实施例中，在TM通过与DBMS建立的会话请求全局事务之后，TM可以请求在DBMS处执行数据库命令。数据库命令可以包括任何PL/SQL命令，诸如DML和DDL语句。一旦接收到命令，DBMS就可以将所请求的数据库命令的执行与事务分支的XID相关联。在一个实施例中，DBMS还可以继续将命令的执行与LTXID相关联。在这样的实施例中，可能已经使命令的LTXID与否则将在提交时将把该LTXID记录到事务历史的本地事务控制一起失效。但是，DBMS可以继续跟踪命令的执行，就像利用本地事务控制执行命令一样。
在实施例中，为了执行事务分支的数据修改命令，DBMS可以解析命令但不将命令执行到完成。相反，DBMS可以在接收到诸如准备命令的附加命令时调度命令以便完成，这将在下面讨论。在另一个实施例中，DBMS可以在事务中将数据修改命令解析并执行到预提交阶段，其中更改已经被成功应用但是可能在请求时被回滚。为了这样做，DBMS可以在DBMS的重做日志中记录对受影响的数据块的更改。DBMS可以以映射的形式维护事务的XID、命令和更改之间的关联，在本文中被称为“事务映射”。在一个实施例中，事务映射还可以包括命令、由命令导致的更改和本地事务的LTXID(与有效性状态无关)之间的映射，以及XID和LTXID之间的映射。在实施例中，这些可以维持在存储器中，并且如果事务提交则将这些记录到事务历史表中。
在实施例中，针对提交事务的事务映射存储在DBMS的事务历史表中。事务映射被存储一段时间，并且诸如TM的客户端可以使用本文描述的技术(诸如GET_LTXID_OUTCOME)来确定提交结果。在这个保留时段到期之后，条目可以被删除。一旦被删除，这些事务的提交结果就无法根据事务映射来确定。相反，返回错误；从来不是未提交的结果。在实施例中，保留时段可通过对DBMS的命令进行配置。
在实施例中，与尚未成功提交的活动事务相关的事务映射在会话句柄中维持在存储器中并且不在DBMS中持久性保存。如果会话由于错误而突然结束，在没有持久性保存事务映射的情况下，则尝试使用LTXID获取事务结果将导致DBMS将事务的提交结果强制为未提交状态。DBMS可以基于本文描述的技术相应地响应未提交。如本文所使用的，“强制提交结果”指的是，如果事务已被提交，则返回事务的已提交状态，或者如果事务尚未被提交，则通过阻止该事务在任何时候提交并返回未提交状态来强制事务处于未提交。与未成功提交的活动事务相关的事务映射在DBMS处的每个会话的事务控制结构中维护在存储器中。如果会话由于错误或超时而突然结束，则使用事务的LTXID访问提交结果的请求可能将提交结果强制为未提交状态，然后将这一结果记录到事务历史表中。
在一个实施例中，TM可以暂停和恢复DBMS上的事务分支的执行。TM可以发出命令以暂停DBMS上的全局事务的事务分支。事务分支的暂停表示TM将不再为该分支发出命令，直到恢复事务分支为止。DBMS可以完成已经接收到的事务分支的命令的执行，并且然后在提交该分支时保存与事务分支相关联的事务映射。由于在TM进一步通知之前不会接收到针对全局事务的进一步命令，因此DBMS可以使会话的LTXID生效。DBMS可以响应于导致生效的命令(诸如XAend)而返回有效的LTXID。在事务分支结束或暂停之后，如果在会话中接收到任何其它命令，则DBMS可以使用有效的LTXID来实行新的本地事务。
TM可以发出命令以恢复DBMS上的全局事务的暂停事务分支。这样的命令可以包括用于恢复全局事务分支的XID，使得DBMS可以将随后接收到的事务分支命令与先前暂停的事务相关联。然后，DBMS可以使与会话相关联的LTXID失效并继续执行事务分支命令。DBMS可以返回包含无效状态的LTXID以及对会话中事务分支命令的响应。
在实施例中，当TM完成对事务分支中的所有命令的执行请求时，TM利用DBMS结束事务分支。TM可以发出指示要在DBMS处结束的事务分支的XID的命令。例如，在XA协议中，DBMS可以接收具有XID的XAend命令以表示全局事务分支的结束。DBMS可以将识别出的事务分支标记为完成。然后，DBMS可以使本地事务控制生效并使与会话相关联的LTXID生效。如果在会话中接收到任何进一步的命令，则DMBS可以返回包含有效状态的LTXID。
DBMS可以接收多个事务分支作为全局事务的一部分以供执行。在一个实施例中，事务分支可以以2(两)种不同的模式运行：紧密耦合和松散耦合。紧密耦合的事务分支可以是默认模式，并且每个分支可以看到其它事务分支的未提交更改。紧密耦合的XA事务以严格的顺序执行而不是并行执行。因此，在一些实施例中，如果在启动新事务分支之前未明确地结束事务分支，则执行隐式XAend以结束先前的事务分支。另一方面，松散耦合的XA事务是独立的，并且可能看不到彼此的更改。
可以为所有事务分支启动全局事务，包括仅由只读命令组成的事务分支。为了避免生成重做，在实施例中，在第一次重做生成时注册全局事务的LTXID/XID记录。在DBMS作为本地事务的一部分提交之前，不能在事务历史表中写入任何记录。在包含数据更改命令的事务分支将生成重做记录之前，这种记录不会发生。对于本地事务句柄(LTXID)生效和失效在存储器中发生。在提交事务之后更新事务历史表。例如，XA协议的用例可以包括以下步骤：
1.XAstart(第一事务分支)
使LTXID失效并随XAstart ack(确认)一起返回
2.SQL语句
3.XAend(第一事务分支结束，事务映射未保存)
使LTXID生效并随XAend ack一起返回
4.XAstart(第二事务分支)
使LTXID失效并随XAstart ack一起返回
5.SQL语句
6.***XAend(第二事务分支结束)并随XAend ack一起返回
使LTXID生效并随XAstart ack一起返回
两阶段全局事务更改提交
在实施例中，TM可以使用两阶段提交协议来提交全局事务。当在事务中使用多于一个RM时，TM可以遵循两阶段提交协议，以便提交由准备阶段和提交阶段组成的全局事务。
在准备阶段，TM请求每个RM保证RM可以提交其事务的分支。TM可以向RM提供事务分支的XID以供准备。RM可以将要由事务修改的任何受影响的资源置于使得RM可以在TM随后请求提交时永久地做出任何更改或者在TM随后请求回滚时使任何更改无效的状态。例如，当RM是DBMS时，DBMS可以确定执行的事务分支可以被提交，然后DBMS可以在DBMS的重做日志中记录准备好的状态并且肯定地回复TM。否则，如果RM在为事务分支的提交准备更改时遇到任何问题，则RM可以回滚事务分支的执行命令并对TM进行否定回复。在一个实施例中，RM可以在任何点单方面回滚事务分支，直到准备阶段成功完成，并且可以对TM请求返回否定响应以准备事务分支。
在第二阶段，基于对来自RM的准备请求的响应，TM可以请求RM提交或回滚事务分支。为了保证更改的原子性提交，除非所有参与的RM在准备阶段肯定地回复，TM可以不发出任何提交命令。如果对于任何事务分支，RM已经对准备请求返回否定响应，则TM可以发出针对RM的事务分支的回滚请求。在另一个实施例中，TM可以请求RM回滚与所有RM的全局事务的所有事务分支。
在实施例中，如果在第二提交阶段在RM处发生通信错误或超时，则TM继续联系该RM，直到RM确认提交已被成功执行为止。如果在第一准备阶段发生通信错误或超时，则TM继续使用恢复命令联系该参与者，直到RM确认RM是已成功准备事务分支还是已回滚事务分支为止。排除启发式结果，可以使用本文描述的技术来确定两阶段事务的提交结果。
图3是描绘在实施例中用于管理全局两阶段事务的处理的流程图。在方框310处，TM从客户端接收要在一个或多个RM上执行的命令。例如，诸如航空公司预订web应用的客户端可以利用TM来进行用户请求的更改的幂等提交。web应用可以请求TM更新航空公司DBMS上的预订表以及处理与金融机构RM的金融事务。
在方框313处，TM请求与每个RM的连接，并且在RM对请求认证之后，RM向TM提供相应的连接以及以诸如LTXID的本地事务句柄形式的针对连接的有效的本地事务控制。在方框315处，TM分配XID以发起在多个RM上执行客户端请求的命令。使用XID，TM可以引用每个RM上的事务分支，并向RM发出命令用于执行和提交全局事务。在一个实施例中，TM可以将生成的XID与命令相关联地存储在TM日志中。在其它实施例中，不同的易失性和非易失性存储器结构可以用于存储XID。继续航空公司预订示例，TM可以生成全局事务的全局唯一标识符，诸如GTRID1。TM可以将事务划分为三个事务分支：一个分支用乘客信息更新航空公司DBMS，另一个分支用于座位分配和行李信息，并且第三个分支用于向金融机构借记，分别表示为XID1、XID2和XID3。
在方框320处，TM请求全局事务中的每个RM使用相应的连接来执行与相应的RM相关联的事务分支。在接收到命令之后，RM使针对连接的相应本地事务控制失效，并且可以使用全局事务控制来发起事务分支的事务。RM执行事务分支的工作。在一些实施例中，RM可以内部地继续使用本地事务句柄来管理本地存储器结构中的事务分支的执行。
在实施例中，TM可以利用RM暂停全局事务并且与RM断开连接。在从TM接收到暂停命令之后，RM使本地事务控制生效并返回具有接收到的命令的确认的生效事务句柄。然后TM可以使用不同的连接与RM重新连接，并且在成功之后，从RM接收针对连接的新事务控制，可能具有不同的LTXID。一旦RM接收到恢复执行暂停的事务分支的请求的命令，RM就使新的本地事务控制失效、返回具有接收到的命令的确认的失效事务句柄、用在命令中提供的XID识别暂停的事务分支、并且恢复事务分支的工作的执行。然后TM可以继续发送针对事务分支的命令，直到TM结束事务分支或再次暂停事务分支为止。
在方框323处，从TM接收到结束事务分支的命令之后，RM使针对连接的本地事务控制生效，并返回具有接收到的命令的确认的生效事务句柄。RM可以执行生效并且通过执行事务分支的结束以原子方式将本地事务控制返回到TM。在相关的实施例中，当DBMS是RM时，对于接收事务分支启动命令的会话使上述LTXID失效，并且当DBMS通过会话接收到事务分支的暂停或结束时，使上述LTXID重新生效。
继续航空公司预订示例，web应用可以包括四页向导：第一页显示关于可用航班的信息用于选择，第二页允许用户输入用于所选航班的她的信息，第三页描述行李选项和座位分配的选择，并且第四页允许用户输入用于所选航班的支付信息。一旦TM接收到航班选择请求，TM就连接到航空公司DBMS以锁定用户的所选航班。TM建立与航空公司DBMS的会话并接收会话的有效LTXID，即LTXID1。TM通过会话发出具有XID1的XAstart命令，并且在接收之后，航空公司DBMS使会话的LTXID1失效并将XID1记录在事务历史表中。由于LTXID1失效，因此即使TM或TM的客户端(航空公司web应用)尝试使用LTXID1查询或回滚本地事务，DBMS也将拒绝该请求。
在执行命令之后，TM发出具有暂停指令的XAend命令，该指令暂停DBMS的全局事务并使会话的LTXID重新生效。TM可以与会话断开连接，并且如果这样的话，则会话可以由其它客户端使用。当TM从应用接收到乘客信息相关的命令时，TM可以通过新会话重新连接到航空公司DBMS以发出命令。TM发出具有XID1的XAstart，其使新会话的LTXID(LTXID2)失效。响应于执行数据修改命令以将乘客信息与航班信息相关联的请求，航空公司DBMS将更改记录在重做日志中而不是对数据库进行任何永久性更改(在全局事务的提交时使更改永久)。然后，TM通过发出XAend命令来结束XID1事务分支。当航空公司DBMS接收到XAend命令时，航空公司DBMS使处于使用中的会话的LTXID重新生效。TM可以类似地执行XID2事务分支用于更新用户的行李和座位分配信息以及金融事务的XID3事务。
继续图3，在方框325处，TM从客户端接收提交全局事务的请求。如果TM已与RM断开连接，则TM请求与每个断开连接的RM的连接，并且在RM对请求进行认证之后，RM向TM提供连接以及以本地事务句柄(诸如LTXID(图3中未示出))的形式提供针对每个连接的有效的本地事务控制。否则，TM与RM连接，然后TM保持生效的本地事务句柄，并且可以使用该连接用于进一步的命令。在方框330处，TM向RM发送准备命令用于准备要在后续命令上提交的事务分支。在接收到要准备的TM命令之后，RM使本地事务控制失效，并返回具有接收到的命令的确认的失效事务句柄。在响应于准备命令或在后续本地(非全局事务)命令之后，可以使控制重新生效。然后，RM中的每一个可以将在该RM上执行的事务分支设置为要明确被提交的状态，或者如果发生错误，则可以如上所述回滚更改。
在方框335处，如果任何RM在准备阶段遇到错误，则给TM的错误消息详述准备命令已经不成功并且失败的事务分支命令已经回滚。然后，在方框340处，TM可以向全局事务中的其它事务分支的所有RM发出回滚命令。然后，TM可以向客户端报告错误和全局事务状态。在一些实施例中，TM可以使用来自TM日志的信息重新发送准备。在其它实施例中，TM回滚所有事务分支并向客户端报告失败。
继续航班预订示例，TM将针对XID1和XID2的XAprepare命令发送到航空公司DBMS，并且将针对XID3的XAprepare命令发送到金融机构RM。航空公司DBMS可能遇到通信错误或超时，并且针对XID1和XID2的XAprepare命令向TM返回错误消息。TM可以重试并重新发送XAprepare命令。通信错误或超时可能导致航空公司DBMS的主数据库服务器故障转移到备用数据库服务器。航空公司DBMS响应于接收到准备命令，验证针对XID1和XID2的数据库更改是否在备用数据库服务器的重做日志中。如果是的话，则航空公司DBMS将成功的消息返回给TM。否则，如果错误仍然存在，则航空公司DMBS可以回滚来自XID1和XID2的任何更改并返回错误消息。如果通信错误或超时仍然存在或错误消息被返回，则TM可以向金融机构RM发出XArollback，并向航班预订应用报告由于航空公司DBMS的问题因此全局事务已回滚。航班预订应用可以向用户报告预订不成功并且用户未被收取预订费用。
在通信错误或超时之后，如果航空公司DBMS确认针对XID1和XID2的数据库更改已被记录在航空公司DBMS的重做日志中，则航空公司DMBS可以返回针对XID1和XID2的重新发出的XAprepare命令的成功消息，并且TM可以继续全局事务的提交。在接收到要准备的TM命令之后，RM使相应的本地事务控制LTXID失效，并利用XAprepare确认返回失效的本地事务句柄。除非该会话已终止，否则TM将使用相同的会话用于XAcommit。
继续图3，如果在方框335处未接收到准备用于提交的事务分支的错误，则TM在方框360处请求RM提交事务分支。在接收到要提交的TM命令之后，RM以原子方式处理命令、使相应的本地事务控制失效，或者如果使用了(与准备命令)相同的会话，则本地事务句柄保持失效。RM在对请求的确认响应中将失效的本地事务控制返回给TM。
在方框370处，如果发生任何错误，则TM将发出XArecover命令。在方框375处，如果响应于XArecover命令，RM确定事务分支尚未提交，则RM在提交之前重建最后一个状态；向TM通知事务分支提交失败；并且该处理转到方框360，以便TM重新请求RM利用XAcommit命令提交事务分支。否则，如果事务分支已提交，则该处理转到方框390。
响应于通信错误或超时，TM或TM的客户端可以不使用失效的本地事务控制来确定两阶段全局事务的结果。在方框323、330和360处接收到全局事务命令时，RM已经使本地事务控制失效。即使TM已经接收到失效的事务处理句柄并将其继续传递给客户端，包括句柄的请求也将被RM拒绝。相反，TM可以依赖于图3中描述的全局事务管理命令和技术来确定两阶段事务的提交结果。
在方框375处，如果受影响的RM已经重建最后一个稳定状态(其中事务分支被成功准备)，则该处理转到方框360来重新发送提交请求。在成功提交所有事务分支之后，当客户端仍然连接时，TM在方框390处向客户端报告成功。在其它实施例中，客户端可能已经自此断开连接。但是，客户端仍然可以使用由TM提供给客户端的不透明句柄来获得提交结果。客户端可能不知道句柄包含XID或LTXID。
继续航班预订示例，TM通过为每个分支发出XAcommit命令来请求航空公司DBMS提交XID1和XID2事务分支。在接收到XAcommit命令之后，航空公司DBMS使会话的LTXID失效。因此，即使发生通信错误或超时，TM也可以不使用接收到的用于会话的LTXID来获得航空公司DBMS处的XAcommit命令的结果。
相反，在重新建立与航空公司DBMS的连接之后，TM可以发出指定XID1和XID2的XArecover命令。响应于XArecover命令，航空公司DBMS返回XID1和XID2事务分支的状态。例如，如果从通信错误或超时的恢复导致航空公司DBMS回滚XID1事务分支，则航空公司DBMS将返回XID1的回滚状态。在接收到XID1的回滚状态之后，TM可以使用XArollback命令回滚航空公司DBMS上的XID2和金融机构RM上的XID3。然后，TM可以向航班预订应用报告，并且进而向用户报告事务已经失败并且用户没有被收取预订费用。
在成功提交XID1、XID2和XID3事务分支之后，TM可以将全局事务的成功报告给web应用，并且web应用进而可以向用户报告她的预订成功。
单阶段优化
在一些实施例中，TM可能不需要使用两阶段协议来在RM上提交全局事务。全局事务可能仅包括利用单个RM的单个事务分支。例如，客户端可以请求TM在单个事务分支中在单个RM处执行命令，或者TM可以确定由客户端针对单个RM请求的命令可以在单个事务分支中执行。由于这种全局事务仅包括单个事务分支，因此TM可以不向RM发出针对全局事务的准备命令。相反，TM可以使用RM上的本地事务控制来管理RM上的全局事务。在通信错误或超时的情况下，TM可以利用由RM返回的本地事务句柄(诸如LTXID)来确定RM处所请求命令的结果。
图4是描绘在实施例中用于管理单阶段事务的处理的流程图。在方框410处，TM从客户端接收要在单个RM处执行的命令，并且作为响应，可以向客户端提供不透明事务句柄。在方框413处，TM请求与每个RM的连接，并且在RM对请求进行认证之后，RM向TM提供相应的连接以及以本地事务句柄(诸如LTXID)的形式提供针对连接的有效的本地事务控制。在方框415处，TM分配XID以在RM上发起客户端请求的命令的执行，并将XID与不透明事务句柄相关联。使用XID，TM可以向RM发出执行和提交全局事务的命令。在一个实施例中，TM可以将生成的XID与命令相关联地存储在TM日志中。在其它实施例中，不同的易失性和非易失性存储器结构可以用于存储XID。
在方框420处，TM使用与RM的认证连接建立与RM的会话，并请求RM执行事务分支。在接收到命令之后，RM使针对连接的相应本地事务控制失效，并且可以使用全局事务控制来发起事务分支的事务。RM可以使本地事务控制失效，并将失效的本地事务句柄返回给TM作为对发起事务分支的执行的命令(诸如XAstart命令)的确认的一部分。RM执行事务分支的工作。在一些实施例中，RM可以在内部继续使用本地事务句柄来管理本地存储器结构中的事务分支的执行。
在实施例中，TM可以暂停与RM的全局事务并且与RM断开连接。在从TM接收到暂停命令之后，RM使本地事务控制生效并返回具有接收到的暂停命令的确认的生效事务句柄。然后TM可以使用不同的连接与RM重新连接，并且在成功之后，从RM接收针对连接的新事务控制，可能具有不同的LTXID。一旦RM接收到恢复执行暂停的事务分支的请求的命令，RM就使新的本地事务控制失效、返回具有接收到的命令的确认的失效事务句柄、用在命令中提供的XID识别暂停的事务分支、并且恢复事务分支的工作的执行。然后TM可以继续发送用于事务分支的命令，直到TM结束事务分支或再次暂停事务分支为止。
在方框423处，从TM接收到结束事务分支的命令之后，RM使针对连接的本地事务控制生效。RM可以通过执行事务的结束以原子方式执行生效，并且可以将生效的本地事务句柄以原子方式返回到TM作为对生效命令(诸如XAend)的确认的一部分。在相关的实施例中，当DBMS是RM时，对于接收事务分支启动命令的会话使上述LTXID失效，并且当DBMS通过会话接收到事务分支命令的暂停或结束时，使上述LTXID重新生效。
作为使用单阶段优化的命令执行的示例，航空公司预订web应用可以请求TM仅更新航空公司DBMS中现有预订的座位分配。TM可以为全局事务生成全局唯一标识符，诸如XID1。TM可以与航空公司DBMS建立会话以执行命令来更新航空公司DBMS中的座位分配信息。在会话建立之后，TM接收由航空公司DBMS生成的用于通过会话执行的命令的本地事务管理的LTXID1。然后，TM利用XID1发出XAstart，这会使会话的LTXID1失效并向航空公司DBMS发出命令以更新座位分配。航空公司DBMS执行命令并将得到的更改记录到重做日志中，而无需对数据库进行任何永久性更改(在提交全局事务之后，更改将变得永久)。然后TM通过发出XAend命令来结束XID1事务分支，并且LTXID1重新生效以用于可以与航空公司DBMS使用相同会话或连接的其它命令的本地事务管理。每当LTXID的状态更改时，新的状态可以响应于更改状态的命令在相同的往返途径中被返回。
继续图4，在框430处，TM从客户端接收提交全局事务的请求。与两阶段协议不同，TM不发出准备命令，而是为事务发出本地提交命令。如上所述，准备命令用于确保全局事务中的每个RM准备好提交事务分支。但是，当使用单个RM时，不需要在RM之间进行协调用于事务命令提交。单个RM可以在内部保证单个事务分支的数据一致性。因此，TM可以跳过准备阶段并向单个RM发出提交命令。
为了这样做，TM可以在方框413处重用与RM相同的认证连接，在这种情况下，客户端已经保持生效的本地事务句柄(或其偏移)，或者TM可以请求新连接，在这种情况下，RM将生成新的本地事务句柄作为认证的一部分，并向TM返回有效的本地事务控制作为创建新连接的原子部分(图4中未示出)。由于没有XAprepare，因此用于发送提交命令的连接具有有效的本地事务控制句柄LTXID，并且该LTXID可以用于确定提交结果。LTXID仅用于在TM未接收到提交结果而是接收到不明确错误时确定提交结果。
使用包含有效LTXID的已建立会话，TM可以在方框440处请求RM提交事务。在接收到提交命令之后，RM不使本地事务控制失效，而是保留控制和本地事务句柄有效。作为相同操作的一部分，RM可以原子地将有效的事务句柄返回给TM。因此，如果返回错误而不是提交结果，则TM(本身或响应于使用不透明事务句柄的客户端请求)可以使用已经保持在TM处的事务句柄来请求提交结果。
如果在方框470处发生错误(诸如通信错误或超时)，则事务分支的XID不能用于检索事务分支的提交状态，因为在没有准备命令的情况下提交命令已经被发出。但是，由RM处理的任何事务(无论是否由全局事务发起)都在RM处通过本地事务句柄(诸如LTXID)使用RM的本地事务控制进行跟踪。因此，在方框475处，TM可以使用为提交会话接收到的本地事务句柄(只要句柄是有效的)在RM处强制提交结果。
在方框470处或在方框480处，如果RM响应与事务分支对应的本地事务已经被提交，则TM可以在方框490处向客户端报告成功。否则，在方框480处，响应于TM查询，在强制提交结果之后，RM可以响应该事务处于未提交状态。
在实施例中，TM可以支持对失败的客户端请求的自动重放。如果这是TM的本地事务，并且从强制结果返回的结果是未提交，并且TM被配置用于重放，则TM可以重放来自客户端的生成原始全局事务的完整请求。继续图4，如果响应于方框475处的强制提交，RM通知TM事务未被提交，则该处理转到方框485以确定是否应该由TM执行重放。TM基于TM是否支持重放来确定TM是否应该执行客户端请求的重放。在相关的实施例中，除了支持重放之外，TM还可以基于TM已经针对相同客户端请求执行的重放的次数来确定是否要重放。在这样的实施例中，TM可以具有包含在TM向客户端报告请求不成功之前TM应该执行的重放的最大次数的配置。如果对于此事件已经超过最大重放次数，则TM将结果向客户端报告。如果TM确定重放客户端请求，则TM可以在方框485处重试整个请求。重放可以包括执行从方框415开始的方框中开始描述的动作的处理。如果该处理在方框485处不继续重放，则在方框490处，TM可以向客户端报告该事务处于未提交状态。
否则，如果使用本地事务，则TM强制提交结果并且返回成功的提交结果，并且这是请求中的最后一次调用，TM可以在方框490处向客户端返回成功提交状态。
继续航空公司预订更新示例，航班预订应用可以请求TM提交航空公司DBMS中的座位分配的更新。TM使用相同的会话或与航空公司DBMS建立会话来执行事务的提交命令。当是相同的会话时，TM已经持有LTXID。如果是新会话，则TM接收由航空公司DBMS生成的LTXID2，用于在会话认证时通过会话执行的命令的本地事务管理。然后，TM可以发出带有TMONEPHASE标志的XAcommit命令以提交XID1事务。如果XAcommit命令成功，则LTXID递增，并且递增后的LTXID与提交结果一起被返回到客户端。LTXID状态在返回时是有效的。
相反，如果提交不是被成功返回，则在航空公司DBMS处发生强制航空公司DBMS对提交命令不响应的通信错误或超时。通信错误或超时导致TM响应于XAcommit命令而接收到错误。作为通信错误或超时的结果，航空公司DBMS可能或可能没有提交事务。TM接收到不明确的错误，而不是已知的结果。一旦航空公司DBMS返回线上，TM就可能强制事务的提交结果。TM与航空公司DBMS建立新会话，然后从用于提交操作的会话中获得新的LTXID。通过新建立的会话，TM利用LTXID2(用于失败会话的本地事务句柄)发出GET_LTXID_OUTCOME。响应于GET_LTXID_OUTCOME命令，航空公司DBMS在事务历史表中强制LTXID2的提交结果。基于记录中的数据，航空公司DBMS向TM通知是否已提交XID1事务。如果已提交XID1事务分支，则TM向航班预订应用报告已成功执行座位分配更新。如果未提交，则该强制保证事务保持未提交。如果事务分支未被提交，则TM可以向航班预订应用报告座位分配更新不成功。TM也可以向web应用通知事务不成功。由于强制操作保证了未提交状态，因此TM可以在航空公司DBMS处重新发出整个请求作为新的全局事务分支。
只读优化
用于全局事务的两阶段提交协议的另一种优化是只读优化。在使用只读优化的实施例中，如果事务分支被确定为由只读命令(诸如SELECT(选择)查询)组成，则TM可以利用RM省略事务分支的提交阶段。响应于来自TM的准备请求，RM可以向TM通知事务分支是只读的，并且因此已经被完全提交。因此，当准备命令返回只读时，TM可以不发出任何提交，并且可以不需要使用本地事物控制或全局事务控制，因为未发出任何提交。
在相关的实施例中，TM还可以利用单个RM执行具有多个事务分支的一阶段提交全局事务。RM可以通过检查与同一全局事务(相同的GTRID)相关联的XID的事务历史表来确定多于一个事务分支已经在RM处执行命令。当多于一个事务分支用RM时，RM可以从TM仅接收单个提交命令来提交所有分支，因为为同一全局事务的每个事务分支接收单独的提交命令对于RM是多余的。为了避免事务进入不确定状态，并且为了消除用于提交到除最后一个分支以外的所有分支的往返行程以及为了消除在最后一个分支处的准备，RM可以选择不参与全局事务中除最后一个事务分支以外的所有事务分支。响应于来自TM的每个非最后一个(non-last)事务的准备命令，RM可以在内部执行准备事务分支所需的所有命令。然后，RM可以向TM返回事务分支是只读的，即使事务分支可能包含数据库修改命令(非只读命令)。对非最后一个事务分支的这种响应可以允许TM放弃为这些事务分支发出冗余的提交命令，并且仅使用单阶段、本地提交来提交最后一个分支。
TM还可以确定没有其它事务分支用全局事务的任何其它RM执行：全局事务是用单个RM的。基于这个确定加上除最后一个事务分支以外的所有事务分支被RM指定为只读，TM可以确定数据完整性没有问题。因此，TM可以为所有其它分支发出准备，并且为最后一个事务发出一阶段提交，而不在最后一个分支处首先发出准备命令。因此，类似于上述单阶段优化，没有为最后一个事务分支执行准备阶段。此外，没有为非最后一个事务分支发出单独的提交，并且非最后一个事务分支可能仅在成功接收到最后一个事务分支的提交命令时才被提交。因此，在关于最后一个事务分支的提交命令的错误的情况下，TM可能无法使用诸如全局XID的全局事务控制来确定事务的状态。但是，TM可以使用已经保持在TM处的用于提交会话的本地事务句柄(LTXID)来使用强制协议获得事务的可靠结果。
图5是描绘在实施例中用于管理只读优化全局事务的处理的流程图。在方框501处，TM从客户端接收要在RM处执行的全局事务的事务分支的命令。在一些实施例中，在从客户端接收到命令之后，TM可能不知道所有事务分支都针对单个RM，因为客户端可能尚未请求TM执行全局事务中的其它事务分支。在方框502处，TM请求与RM的连接，并且在RM对请求进行认证之后，RM向TM提供相应的连接以及以本地事务句柄(诸如LTXID)的形式提供针对连接的有效的本地事务控制。在方框503处，TM为事务分支的命令分配XID以在RM上发起客户端请求的命令的执行。使用所分配的XID，TM可以向RM发出命令用于执行和提交全局事务。在一个实施例中，TM可以将所生成的XID与TM日志中的命令相关联地存储。在其它实施例中，不同的易失性和非易失性存储器结构可以用于存储XID。
在方框505处，TM使用与RM的认证连接建立与RM的会话，并请求RM执行事务分支。在接收到命令之后，RM使连接的相应本地事务控制失效，并将失效的本地事务句柄返回给TM作为对发起执行事务分支的命令(诸如XAstart命令)的确认的一部分。RM可以使用全局事务控制来发起事务分支的事务，并且在一些实施例中，可以使用事务分支的XID跟踪诸如事务历史表的本地存储器结构中的事务分支的执行。
在实施例中，类似于两阶段全局事务，TM可以暂停与RM的全局事务并且与RM断开连接。在从TM接收到暂停命令后，RM使本地事务控制生效并返回具有对接收到的暂停命令的确认的生效的事务句柄。然后TM可以使用不同的连接与RM重新连接，并且在成功后，从RM接收针对连接的新事务控制，可能具有不同的LTXID。一旦RM接收到恢复对执行暂停的事务分支的请求的命令，RM就使新的本地事务控制失效、返回具有对接收到的命令的确认的失效事务句柄、并利用命令中提供的XID识别暂停的事务分支。然后，TM可以继续为事务分支发送命令，直到TM结束事务分支或再次暂停事务分支为止。
在方框507处，在从TM接收到结束事务分支的命令后，RM使针对连接的本地事务控制生效。RM可以将生效的本地事务句柄返回给TM作为对生效的命令(诸如XAend)的确认的一部分。在相关的实施例中，当DBMS是RM时，上述LTXID对于接收到启动执行事务分支命令的命令的会话失效，并且当事务分支被从TM到DBMS的命令暂停或结束时，上述LTXID重新生效。可以针对全局事务的多个事务分支重复方框501至507。
在方框510处，TM从客户端接收提交全局事务的请求。在实施例中，全局事务可以由多个事务分支组成，并且除了可能最后一个之外，所有事务分支都需要在提交之前准备。TM一次一个地遍历所有事务分支，直到在方框515处TM确定只有最后一个事务分支尚未准备为止。对于全局事务的非最后一个事务分支，在方框517处，TM可以建立与RM的会话来准备事务分支。在会话建立后，TM可以获取该会话上存在的本地事务句柄。然后TM可以向RM发出针对事务分支的准备命令。
在方框520处，RM确定是否存在已在RM处为全局事务执行但仍等待来自TM的准备命令的任何其它事务分支。因为如果存在同一全局事务的此类事务分支等待，则RM通过其对当前事务分支的只读答复，有效地将全局事务的多个事务分支整合到该RM的单个事务分支中。因此，如果在RM处存在等待准备命令的其它事务分支，则在一些实施例中处理前进到方框525并且然后前进到方框530，或者在其它实施例中，处理直接前进到方框530。
在方框525处，RM使会话的本地事务控制失效，并以失效的本地事务句柄的形式将失效的本地事务控制返回给TM。因此，TM或客户端可以不使用会话的本地事务句柄来管理与执行后续提交命令的RM相关联的任何改变。在其它实施例中，当在方框520之后处理前进到方框530时，RM可以保留本地事务控制有效。在这样的实施例中，RM可以防止自身使用本地事务控制来管理全局事务。
在一些实施例中，当本地事务句柄不能用于确定全局事务命令的成功时，如果在TM接收到准备命令的状态之前发生通信错误或超时，则TM可以重新发出准备命令。
在方框530处，如果事务分支确实仅包含只读命令，则RM可以执行命令到完成而无需从TM接收提交命令(由于命令是只读的，因此不需要提交)。否则，如果事务分支包括非只读命令，则RM可以将事务分支的更改置于该更改可以在来自TM的最后一个命令上提交或者回滚的状态。
在方框530处，RM对于具有非只读命令的事务分支向TM返回只读，以便节省TM对附加通信的需要(并因此节省RM、TM和网络的资源)。由于TM不为只读事务分支发送提交命令，因此通过用只读状态响应，RM可以允许TM跳过除最后一个事务分支以外的所有事务的提交命令。由于RM在方框520处已确定在同一全局事务中存在至少另一个事务分支，因此RM可以使用最后一个事务分支的提交命令来提交事务分支。在实施例中，RM将当前事务分支的提交推迟到为利用RM的最后一个事务分支接收到的提交命令。如果命令无法将RM处的提交结果的状态返回给TM，或者返回带有表示故障的错误代码，则该提交命令可能产生不明确的提交结果。
但是，在实施例中，如果在方框520处RM确定TM已发送准备命令的当前事务分支是RM处针对全局事务的唯一事务分支，则事务可能不符合只读优化的条件，然后处理前进到方框523，其中准备命令由RM执行并且本地事务句柄失效并且与准备命令执行的状态一起返回到TM。然后，该处理转到方框515以处理下一个事务分支。在一个实施例中，当前事务分支是RM处全局事务的唯一事务分支，如果当前事务仅由只读命令组成，则RM仍然可以向TM返回只读状态。在这样的实施例中，RM将把当前事务分支的命令执行到完成，并且TM可以不向RM发出当前事务的提交命令，而是发出忘记分支的命令，诸如XAforget。方框515至530的处理可以对所有事务分支重复，直到在方框515处TM确定当前事务分支是准备全局事务的最后一个事务分支为止(TM的客户端已在方框510处请求提交全局事务，并且该处理已到达全局事务中的最后一个事务分支)。如果是的话，则在方框535处TM确定在全局事务中是否涉及多于一个RM。如果全局事务中涉及多于一个RM，则该处理前进到方框537，并且使用如图3中所述的两阶段提交继续准备和提交最后一个事务分支。
在方框535处，TM可以确定全局事务仅由已被返回给TM以表示所有先前的事务分支都是只读的单个RM组成。由于全局事务的除最后一个事务分支以外的所有事务分支都是只读的，因此TM还可以确定不存在数据完整性问题。因此，在方框540处，TM可以在不发出最后一个事务分支的准备命令的情况下发出提交命令(一阶段提交命令)。
TM保持针对其发出提交的会话的本地事务控制句柄(LTXID)。在一个实施例中，RM可以通过在提交之前强制提交结果并且从RM接收确定性结果(已提交或未提交)来确定本地事务控制是有效的，TM保持有效的LTXID。RM可以基于表示与来自TM的提交命令一起接收到的一阶段提交事务的标志保留本地事务控制有效，因此可以确定当前事务之后的下一个事务的状态。
在方框570处可能发生错误(诸如通信错误或超时)。然后，TM可能无法接收在方框540处发送的提交命令的状态。由于仅最后一个分支被提交，因此在方框575处，TM或客户端可以使用用于提交的会话上存在的事务句柄来强制在该最后一个分支上的本地事务结果(已提交，或者如果尚未提交则未提交)。
在方框570处或在方框580处，如果RM响应已提交事务分支，则TM可以在方框590处向客户端报告成功。否则，在方框580处，响应于TM查询，RM可以强制提交结果，使得结果是确定性的，并且然后响应事务分支处于未提交状态。在一个实施例中，如果RM响应事务分支处于未提交状态，则TM可以向客户端返回事务尚未被提交。这是因为未提交的状态已被强制，并且永远不能从这个状态更改。
在另一个实施例中，TM可以被配置为将全局事务向RM自动重放一次或多次。因此，当RM在方框580处向TM通知通过强制提交结果事务分支处于未提交状态时，TM可以在方框585处类似于方框485确定向RM重放全局事务。如果事务被重放，则该处理转到方框505。如果在585处该处理没有继续重放，则TM可以向客户端报告事务处于未提交状态。在每次重放尝试之间，必须强制提交结果，因此先前的重放尝试不可能导致不明确的错误。强制提交结果确保确切存在一个客户端请求的命令的提交(最后一个)，或者重放被放弃并将未提交的状态被返回给TM和客户端。在将未提交状态返回给客户端之前，可以在事务管理器处预先配置重放尝试的数量。
为了图示只读优化，提供了使用TM来更新航空公司DBMS的航空公司预订web应用的示例。web应用的用户可以使用奖励里程为她的现有预订请求头等舱升级。因此，用户事务涉及更改座位预订以及用航空公司DBMS更新奖励里程账户余额。TM可以接收这两个请求作为用于更新航空公司DBMS的单独命令集：首先，更新以更改现有预订的座位预订，以及第二，更新包含奖励里程信息的表格。
响应于web应用的第一个请求，TM然后为全局事务生成全局唯一标识符GTRID1，并为用于更新座位分配的第一个事务分支分配XID1。然后，TM建立与航空公司DBMS的会话，其中存在LTXID1以通过会话本地地管理事务。一旦TM利用XID1发出XAstart，然后DBMS就使本地事务控制的LTXID1失效，并将该失效的句柄(LTXID)返回给客户端。在接收到来自TM的更新座位信息的命令后，航空公司DBMS执行命令并将更改记录在重做日志中，而不是对数据库进行任何永久性更改(在提交本地事务后，更改成为永久性的)。然后，通过TM发出XAend命令结束事务分支XID1。在接收到XAend命令后，LTXID1重新生效并且响应于XAend命令被返回给TM。然后，航空公司DMBS可以使用该LTXID用于可以使用与DBMS相同的会话或连接的其它命令的本地事务控制。
然后，TM基于GTRID1分配XID2，以执行命令来更新奖励里程信息作为第二事务分支的一部分。类似地，在从TM接收到事务分支后，航空公司DBMS使与航空公司DBMS的会话的现有本地事务句柄LTXID2失效，并且响应于启动分支的命令而将其传递回TM。然后航空公司DBMS执行用于更新奖励里程的命令，而不使更改永久化。在接收到XID2的XAend命令后，航空公司DBMS使LTXID2重新生效并且响应于命令而将生效的LTXID2返回给TM。
在用户请求后，航班预订应用可以请求TM提交对座位分配的更新以及对航空公司DBMS中用户的奖励里程账户的更新。作为响应，TM建立与航空公司DBMS的会话以执行与GTRID1全局事务相关联的事务分支的准备命令。在会话建立后，TM保持该会话的LTXID3。无论何时创建该会话，都由航空公司DBMS为本地事务管理生成LTXID。会话可以是新创建的或从连接池借用的。
然后TM可以发出XAprepare命令来准备XID1事务分支。当使用只读优化时，虽然响应于准备命令，XID1具有非只读命令(更新座位分配)，但是响应于XID1的XAprepare命令，航空公司DBMS返回事务分支是只读的(XA_RDONLY)。此数据库会话上的LTXID保持处于有效状态，或者如果它不是有效的则被设置为有效，并在准备命令返回时被返回给客户端。
在为下一个事务分支XID2发送XAprepare命令之前，TM可以检查GTRID1全局事务的TM日志。从日志中，TM确定XID2事务分支是GTRID1全局事务的最后一个事务分支。TM进一步确定GTRID1全局事务中的所有事务分支XID1和XID2都与单个RM(即航空公司DBMS)一起。由于前一个且唯一的其它分支已返回只读XA_RDONLY，因此TM确定直接进行提交XID2分支，而不发出XAprepare命令来准备事务分支。因此，TM使用已经与该数据库会话相关联的本地事务句柄LTXID4与航空公司DBMS建立会话。然后，TM为XID2事务分支发出XAcommit，其中设置了TMONEPHASE标志。
在从TM接收到XAcommit命令后，航空公司DBMS继续提交XID2的更改(对航空公司DBMS上的用户里程的更新)。LTXID被递增。这是该会话上的下一个事务的下一个LTXID5。然后，航空公司DBMS用成功来响应XAcommit命令，并且新的LTXID5与对命令的响应一起被返回。
如果代替返回提交的结果，存在通信错误或超时，则TM可能不从航空公司DBMS接收到XAcommit命令已成功的响应。为了确定TM是否可以确定XAcommit命令的状态，TM可以检查中断会话的事务句柄的有效性状态。由于LTXID4事务句柄在先前完成的操作(诸如准备和XAend)中是有效的，因此TM可以与航空公司DBMS建立新会话，以使用强制提交来确定XAcommit命令的状态。当TM成功连接到航空公司DMBS并建立新会话时，TM通过会话发出带有LTXID4(失败会话的本地事务句柄)的GET_LTXID_OUTCOME。响应于GET_LTXID_OUTCOME命令，航空公司DBMS强制LTXID4的结果-响应于该命令，事务被提交或者被强制为未提交。强制是至关重要的，因为提交结果必须是确定性的，即未提交或已提交。航空公司DBMS向TM返回事务(XID)已提交或未提交。然后TM可以向航班预订应用报告结果。
在另一个示例中，当航空公司DBMS向TM返回事务未提交时，TM可以发起航空公司预订应用请求的自动重放。当TM接收到请求时，TM将来自航空公司DBMS的请求与XID相关联地存储。当原始事务由于错误而失败并且使用上述技术的恢复使得事务处于未提交状态时，TM可以使用失败事务的XID来检索请求并且然后在新事务中重新执行请求。TM可以重放多次直到成功为止，或者重放次数达到预先配置的阈值。在实施例中，在每次重放尝试之间，提交结果被强制，因此确切地存在单个成功重放，即，最后一次重放被提交，否则如果没有重放成功，则将未提交结果返回给TM，TM将进一步通知客户端。
可提升的全局事务
在实施例中，TM可以初始地向RM发出命令作为本地事务的一部分，然后将事务“提升”为全局事务。提升本地事务在本文中是指处理，TM通过该处理将对与资源管理器的事务的管理从仅由资源管理器管理作为本地事务转换为由可能涉及附加资源管理器的TM管理的全局事务的处理。
当事务中仅涉及单个RM时，TM可以使用本地事务向RM发出事务命令集。然后，事务可以由RM的本地事务管理来管理。只要确定来自客户端的事务命令集是针对单个RM，TM就可以放弃使用全局事务的开销，并如上所述使用本地事务来执行事务命令集。
在某个时候，客户端可以请求执行附加命令作为相同事务的一部分，但该事务是与不同的第二RM的。响应于该请求，TM可以发出命令以将第一RM上的本地事务提升为全局事务。在接收到提升请求后，第一RM可以使本地事务控制和句柄失效。但是，第一RM可以继续将事务作为全局事务跟踪。TM可以利用多个RM发起对事务的控制并将事务作为全局事务进行管理。然后，TM可以为第二RM执行客户端请求的命令作为全局事务的一部分。TM可以继续在第一RM和第二RM上准备和提交全局事务作为具有本文描述的优化的两阶段协议。在第一RM之后，提升的全局事务中可能涉及任何数量的附加RM。
在其它相关的实施例中，本文描述的一个或多个优化可以应用于管理提升的全局事务。例如，TM可以发出可能在第二RM上引起多个事务分支的命令，使得第二RM可以将事务分支视为“只读”，并且可以根据“只读优化”部分中描述的技术来管理事务分支。
图6是描绘在实施例中用于管理可提升事务的处理的流程图。在方框610处，TM接收一个或多个命令作为由RM执行的事务命令集的一部分。在方框615处，TM确定到目前为止是否仅单个原始RM被请求执行作为事务命令集的一部分的命令。首先，客户端可能正在请求TM仅在原始RM处执行事务集中的命令。如果是的话，则在方框617处，TM利用原始RM使用本地事务。TM建立与原始RM的会话，并使用与该数据库会话相关联的本地事务句柄。当事务最终提交时，TM可以将本地事务句柄与提交结果一起记录在TM日志中。客户端可以访问提交结果。
在方框620处，TM使用本地事务请求在原始RM处执行接收到的命令。在一个实施例中，TM可以在不解析命令的情况下识别所请求的命令是否正在提交事务。TM可以在RM已请求命令执行之前和之后检查本地事务句柄(LTXID)。如果事务句柄更改，则所请求的命令会提交一个或多个事务。由于原始RM使用本地事务来管理命令的执行，因此本地事务句柄在整个执行期间保持有效。原始RM将TM视为连接到RM以执行命令的通用客户端，并使用句柄在事务历史表中跟踪本地事务提交历史。但是，如果本地事务控制先前已失效，则RM使本地事务控制句柄生效并向TM返回有效的本地事务控制句柄。对在方框620处执行接收到的命令的本地事务管理在以上“管理DBMS上的本地事务”部分中描述。
在实施例中，当事务命令集中的命令使用另一个新的RM以供执行时，本地事务管理被提升为全局事务管理。因此，如果在方框615处接收到被确定为使用另一个新RM的命令，则该处理转到方框630以提升原始本地事务。在方框630处，TM为新的全局事务分配XID，该新的全局事务也包括在原始RM处的原始本地事务。在方框635处，TM请求原始RM将本地事务管理提升为全局事务管理，并使用XID来发起全局事务。
在实施例中，如果在方框621处在提升之前发生任何错误，诸如TM和原始RM之间的通信中的通信错误或超时，则在方框622处可以使用本地事务管理来强制事务的提交状态。使用在“管理DBMS上的本地事务”部分中描述的技术，在方框622处，TM可以使用本地事务句柄(诸如LTXID)在与RM的连接恢复之后获得事务的提交结果。基于在方框623处的接收状态，在方框624处TM可以将提交状态返回到客户端或者重放客户端请求。如果在方框623处执行重放，则该处理前进到方框617，其中新的本地事务用于将客户端请求命令重新提交给原始RM。
在方框640处，响应于提升请求，原始RM可以利用TM将本地事务转换为全局事务的事务分支。
在将本地事务管理提升为全局事务之后，或者如果在方框630-640处原始RM上的本地事务已经被提升，则该处理转到方框645。在方框645处，然后根据对于两阶段提交事务或任何适用的优化所描述的技术(参考在“只读优化”部分中描述的技术)来管理提升的事务。然后，根据本文描述的类似全局事务技术，由TM处理在方框610处TM从客户端接收到的任何附加命令。
为了图示可提升事务，提供了具有用于更改座位分配的多页向导的航空公司预订应用的示例。取决于用户先前的座位分配，航空公司预订可能需要或可能不需要向用户收取更改费用。例如，如果用户先前预订了经济舱座位但是请求具有额外腿部空间的座位，则用户可能被要求支付额外费用或者可能使用她的奖励里程。但是，如果用户正在同一类座位内更换座位，则座位分配可能不需要其它更新。对于这一示例，用户的座位分配和里程账户存储在航空公司DBMS上，而支付处理由金融机构资源管理器执行。
在向导的第一页上，用户通过选择除已分配座位之外的新座位来更改她的座位分配，并提交页面。响应于提交页面，航空公司预订请求TM执行事务的座位分配更改部分。由于TM接收到的命令仅针对航空公司DBMS，因此TM继续与航空公司DBMS建立会话，而不为接收到的事务命令集创建全局事务。TM保持已建立会话的LTXID1。TM将请求发送到航空公司DBMS。在接收后，航空公司DBMS执行命令并在重做日志中记录更改而不提交命令(不刷新重做日志)。仅当提交发生时，航空公司DBMS才会记录到事务历史表。每次成功提交导致LTXID递增，并且递增的LTXID被返回给TM。如果发生中断会话的通信错误或超时，则TM重新建立连接并接收新的LTXID。如果新LTXID不等于LTXID1(和/或是其递增)，则提交已成功。否则，TM使用LTXID1通过发出带有LTXID1作为参数的GET_LTXID_OUTCOME命令获取本地事务的状态。该命令使航空公司DBMS强制提交结果并向TM返回事务处于已提交状态还是未提交状态。相反，如果原始LTXID1已更改并且TM现在具有另一个LTXID(LTXID2)，则请求已发出至少一个提交。如果TM使用上述技术确定航空公司DBMS尚未提交已发出的提交，则TM可以从航空公司DBMS上的航空公司预订应用重放请求。
在向导的下一页上，如果用户已选择需要升级的座位，则用户可以是付款选项。对于付款，可以给用户选择用用户的奖励里程或金钱或两者来支付。如果用户选择两种支付方法，则应用请求TM更新用户在航空公司DBMS上的奖励余额，以及在金融机构RM处借记用户的账户作为更新座位分配的相同事务的一部分。
如果用户不使用TM的情况下继续请求，则事务保持为(座位分配和奖励里程更新)在相同事务中不涉及TM因此不存在提升的本地事务。在接收到奖励里程账户更新命令后，航空公司DBMS执行命令并更新重做日志。由于这是相同的本地事务，因此航空公司DBMS在该会话LTXID1上使用LTXID，以将提交操作记录到事务历史表。然后LTXID递增并被返回给准备好用于该会话上的下一个事务的客户端。
如果发生错误导致与RM的通信丢失而没有接收到结果，则在与RM重新建立会话后，TM可以发出具有LTXID1的GET_LTXID_OUTCOME，以强制本地事务的提交结果。该命令强制航空公司DBMS返回事务的已提交或未提交结果。
如果没有发生错误，则航空公司预订应用继续进行事务并请求TM代表用户请求利用金融机构RM的支付事务作为相同事务的一部分。由于金融机构RM是与航空公司DBMS不同的RM，因此需要生成全局事务，其包括在航空公司DBMS处执行的命令作为生成的全局事务的事务分支。为了这样做，TM为全局事务生成XID：XID1用于航空公司DBMS处的座位和奖励里程更新，并且XID2用于金融机构RM处更新的支付。然后，TM更新TM日志记录以反映命令的新XID。
然后，TM向航空公司DBMS发送命令，以将与LTXID1相关联的事务命令集提升到具有XID1的全局事务分支。作为响应，DBMS使LTXID失效并将其作为提升请求的一部分返回。
然后，TM与金融机构RM建立会话，并发出具有XID2的XAstart命令以执行用户付款的命令。在请求执行命令之后，TM然后可以发出具有XID2的XAend命令以关闭与金融机构RM的全局事务。为了准备XID2分支以供提交，TM向金融机构RM发出XAprepare命令。
一旦为所有分支发出的XAprepare命令从金融机构RM返回成功，TM就可以提交全局事务。每个XAprepare返回具有失效状态的LTXID。TM向航空公司DBMS发出具有XID1的XAcommit命令，并且向金融机构RM发出具有XID2的XAcommit命令。在接收到XAcommit命令后，航空公司(通过刷新重做日志)提交与事务分支相关联的更改。此会话上的LTXID保持无效，因为这是两阶段提交。对结果的任何请求可以由TM处理。
在提升之后使用本文讨论的用于全局事务及其优化的结果确定技术来处理TM和航空公司DBMS或金融机构RM之间的通信中的任何错误。例如，如果在TM发出XAcommit命令之前发生错误，则TM可以向航空公司DBMS和金融机构RM两者发出XArollback。如果在成功的XAprepare命令之后发生错误，则TM可以针对未提交的更改发出XArollback或发出XArecover。TM在提升之后可以不使用本地事务句柄，因为作为两阶段提交协议的一部分，XAprepare和XAcommit命令已使本地事务句柄失效。
本地事务管理状态更改的功能示例
在实施例中，可以基于如表1中描述的相同会话上针对全局事务发出的命令来使与DBMS的会话的本地事务管理控制生效或失效。表1中的LTXID是会话的本地事务句柄。表1中的列对应于全局事务命令，这些命令在通过会话发送时，影响本地事务控制的有效性。该表使用XA协议命令，但是，用于全局事务的确切协议或协议的组合对于本文描述的技术不是至关重要的。表1中的行对应于通过会话利用的全局事务管理的类型，诸如本文描述的优化。表中的每个单元表示当DBMS接收在行中所述的类型的事务中的列中所述的全局事务命令时的实施例。对于表1中的每个单元，示出了本地事务的有效性状态。在对应于每个单元的实施例中的本地事务句柄可以具有被设置为表1的对应单元中描述的值的状态值。
表1-本地事务控制有效性
Figure BDA0001783453870000461
Figure BDA0001783453870000471
在针对XAcommit命令的实施例中(参见表1中的XAcommit行)，其中生成新的LTXID，新的LTXID可以通过递增LTXID被生成。因此，不会引起在每个一阶段提交时记录LTXID的性能成本，因为仅运行次数和时间戳被更新。在相关的实施例中，可以通过递增LTXID的提交次数来递增LTXID以生成新的LTXID。
在实施例中，如果在表1的列中描述的全局事务命令之后，通过同一会话接收到非事务命令，则先前失效(无效)的会话的本地事务句柄LTXID对于该会话生效(有效)。这允许下一个事务重用数据库连接。
数据库管理***
数据库管理***(DBMS)管理数据库。DBMS可以包括一个或多个数据库服务器。数据库包括存储在持久性存储器机制(诸如一组硬盘)上的数据库数据和数据库字典。数据库数据可以存储在一个或多个数据容器中。每个容器包含记录。每个记录内的数据被组织成一个或多个字段。在关系DBMS中，数据容器被称为表，记录被称为行，并且字段被称为列。在面向对象的数据库中，数据容器被称为对象类，记录被称为对象，并且字段被称为特性。其它数据库体系架构可以使用其它术语。
用户通过向数据库服务器提交使数据库服务器对存储在数据库中的数据执行操作的命令与DBMS的数据库服务器进行交互。用户可以是运行在客户端计算机上与数据库服务器进行交互的一个或多个应用。本文中多个用户也可以被统称为用户。
如本文所使用的，“查询”是指数据库命令，并且可以处于符合数据库语言的数据库语句的形式。在一个实施例中，用于表达查询的数据库语言是结构化查询语言(SQL)。存在许多不同版本的SQL，一些版本是标准的，并且一些是专有的，并且存在各种扩展。数据定义语言(“DDL”)命令被发布到数据库服务器以创建或配置数据库对象，诸如表、视图或复杂数据类型。SQL/XML是在对象-关系数据库中操纵XML数据时使用的SQL的常见扩展。虽然本文使用术语“SQL”描述本发明的实施例，但是本发明不仅仅限于该特定的数据库查询语言，并且可以与其它数据库查询语言和构造结合使用。
客户端可以通过建立数据库会话(本文中被称为“会话”)向数据库服务器发出一系列请求，诸如对执行查询的请求。会话包括为客户端建立的到数据库服务器(诸如数据库实例)的特定连接，客户端可以通过该连接发出一系列请求。数据库服务器可以维护关于会话的会话状态数据。会话状态数据反映会话的当前状态，并且可以包含为其建立会话的用户的身份、由用户使用的服务、对象类型的实例、语言和字符集数据、关于会话的资源使用的统计数据、由会话内执行软件的进程生成的临时变量值、以及光指针(cursor)和变量以及其它信息的存储。会话状态数据还可以包含为会话配置的执行计划参数。
多节点数据库管理***由共享对相同数据库的访问的互连节点组成。通常，节点经由网络互连并且以变化的程度共享对共享存储装置的访问，例如，对一组盘驱动器和存储在该组盘驱动器上的数据块的共享访问。多节点数据***中的节点可以是经由网络互连的一组计算机(例如，工作站、个人计算机)的形式。可替代地，该节点可以是网格的节点，其中网格由节点组成，这些计算节点以服务器刀片的形式与机架上的其它服务器刀片互连。
多节点数据库***中的每个节点托管数据库服务器。诸如数据库服务器的服务器是计算资源的分配和集成软件组件的组合，其中计算资源诸如存储器、节点和用于在处理器上执行集成软件组件的节点上的处理，软件和计算资源的组合专用于代表一个或多个客户端执行特定的功能。
可以将来自多节点数据库***中的多个节点的资源分配为运行特定数据库服务器的软件。软件和来自节点的资源分配的每个组合是在本文中被称为“服务器实例”或“实例”的服务器。数据库服务器可以包括多个数据库实例，这些数据库实例中的一些或全部在包括单独服务器刀片的单独计算机上运行。
硬件概述
根据一个实施例，本文所描述的技术由一个或多个专用计算设备实现。专用计算设备可以是硬连线的以执行该技术，或者可以包括诸如被持久性地编程以执行该技术的一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)的数字电子设备，或者可以包括被编程为按照固件、存储器、其它存储装置或者组合中的程序指令来执行该技术的一个或多个通用硬件处理器。这种专用计算设备还可以合并定制的硬连线逻辑、ASIC或FPGA与定制的编程来实现该技术。专用计算设备可以是台式计算机***、便携式计算机***、手持式设备、联网设备或者结合硬连线和/或程序逻辑来实现该技术的任何其它设备。
例如，图7是图示可以在其上实现本发明的实施例的计算机***700的框图。计算机***700包括总线702或者用于传送信息的其它通信机制，以及与总线702耦合用于处理信息的硬件处理器704。硬件处理器704可以是例如通用微处理器。
计算机***700还包括耦合到总线702用于存储信息和要由处理器704执行的指令的主存储器706，诸如随机存取存储器(RAM)或其它动态存储设备。主存储器706还可以用于在要由处理器704执行的指令执行期间存储临时变量或其它中间信息。这种指令当存储在处理器704可访问的非暂态存储介质中时，使计算机***700成为被定制以执行指令中所指定的操作的专用机器。
计算机***700还包括耦合到总线702以用于为处理器704存储静态信息和指令的只读存储器(ROM)708或者其它静态存储设备。提供了诸如磁盘或光盘的存储设备1210，并且存储设备710耦合到总线702以用于存储信息和指令。
计算机***700可以经总线702耦合到诸如阴极射线管(CRT)的显示器712以用于向计算机用户显示信息。包括字母数字和其它键的输入设备714耦合到总线702，用于向处理器704传送信息和命令选择。另一种类型的用户输入设备是光标控件716，诸如鼠标、轨迹球或者光标方向键，用于向处理器704传送方向信息和命令选择并且用于控制显示器712上的光标移动。这种输入设备通常具有在两个轴(第一个轴(例如x)和第二个轴(例如y))中的两个自由度，这允许设备在平面内指定位置。
计算机***700可以使用定制硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现本文所描述的技术，定制硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑与计算机***结合，使得计算机***700成为或者将计算机***700编程为专用机器。根据一个实施例，由计算机***700响应于执行被包含在主存储器706中的一条或多条指令的一个或多个序列的处理器704而执行本文的技术。可以从诸如存储设备710的另一个存储介质将这种指令读取到主存储器706中。执行被包含在主存储器706中的指令的序列使得处理器704执行本文所述的处理步骤。在替代实施例中，硬连线的电路***可以代替软件指令或者与软件指令组合使用。
如在本文所使用的，术语“存储介质”是指存储使机器以特定方式操作的数据和/或指令的任何非暂态介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘或磁盘，诸如存储设备710。易失性介质包括动态存储器，诸如主存储器706。存储介质的常见形式包括例如软盘、柔性盘、硬盘、固态驱动器、磁带，或者任何其它磁性数据存储介质、CD-ROM、任何其它光学数据存储介质、具有孔图案的任何物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其它存储器芯片或盒式磁带。
存储介质与传输介质截然不同但是可以与传输介质结合使用。传输介质参与在存储介质之间传送信息。例如，传输介质包括同轴线缆、铜线和光纤，包括包含总线702的引线。传输介质还可以采取声波或光波的形式，诸如在无线电波和红外线数据通信中产生的那些波。
各种形式的介质可以参与把一条或多条指令的一个或多个序列携带到处理器704以供执行。例如，最初可以在远端计算机的磁盘或固态驱动器上携带指令。远端计算机可以将指令加载到该远端计算机的动态存储器中并且使用调制解调器经电话线发送指令。位于计算机***700本地的调制解调器可以在电话线上接收数据并且使用红外线发射器将数据转换成红外线信号。红外线检测器可以接收在红外线信号中携带的数据并且适当的电路***可以将数据放在总线702上。总线702将数据携带到主存储器706，处理器704从该主存储器706检索并执行指令。由主存储器706接收的指令可以可选地在被处理器704执行之前或之后被存储在存储设备710上。
计算机***700还包括耦合到总线702的通信接口718。通信接口718提供耦合到网络链路720的双向数据通信，其中网络链路720连接到本地网络722。例如，通信接口718可以是综合业务数字网络(ISDN)卡、线缆调制解调器、卫星调制解调器或者提供到对应类型的电话线的数据通信连接的调制解调器。作为另一个示例，通信接口718可以是提供到兼容的局域网(LAN)的数据通信连接的LAN卡。也可以实现无线链路。在任何这种实现中，通信接口718发送和接收携带表示各种类型信息的数字数据流的电信号、电磁信号或光信号。
网络链路720通常通过一个或多个网络向其它数据设备提供数据通信。例如，网络链路720可以通过本地网络722提供到主机计算机724或者到由互联网服务提供商(ISP)726操作的数据装置的连接。ISP 726进而通过现在通常被称为“互联网”728的全球分组数据通信网络提供数据通信服务。本地网络722和互联网728两者都使用携带数字数据流的电信号、电磁信号或光信号。通过各种网络的信号以及在网络链路720上并通过通信接口718的信号是传输介质的示例形式，其中该信号将数字数据携带到计算机***700或者从计算机***700携带数字数据。
计算机***700可以通过(一个或多个)网络、网络链路720和通信接口718发送消息和接收数据，包括程序代码。在互联网示例中，服务器730可以通过互联网728、ISP 726、本地网络722和通信接口718传送对应用程序的所请求的代码。
接收到的代码可以在其被接收时由处理器704执行，和/或存储在存储设备710或其它非易失性存储装置中以供以后执行。
在前述说明书中，已经参考许多具体细节描述了本发明的实施例，这些具体细节可以因实施而异。因此，说明书和附图被认为是说明性的而不是限制性的意义。本发明的范围的唯一且排他的指示以及申请人所预期作为本发明的范围的内容，是从本申请产生的一组权利要求的以该组权利要求产生的具体形式的书面范围和等效范围，该组权利要求包括任何后续的校正。
云计算概述
本文描述的技术使用一个或多个处理解决方案来实现，这些方案的示例包括分布式***、集群计算***和云计算***。在实施例中，分布式事务处理***(DTPS)100是云计算***的一部分。云计算***实现以下中的一个或多个：云存储、云处理、云通信和任何其它种类的云计算服务。进一步地，云计算***可以在按使用量付费(pay-for-what-you-use-as-you-use-it)的模式下、在固定的订阅模型等下进行操作。在这种实施例中，归因于DTPS 10c0或本说明书内其它实体的功能的任何部分(或全部)可经由在云计算***处暴露的接口来控制。
在前述说明书中，已经参考许多具体细节描述了本发明的实施例，这些具体细节可以因实施而异。因此，说明书和附图被认为是说明性的而不是限制性的意义。本发明的范围的唯一且排他的指示以及申请人所预期作为本发明的范围的内容，是从本申请产生的一组权利要求的以该组权利要求产生的具体形式的书面范围和等效范围，该组权利要求包括任何后续的校正。

Claims (33)

1.一种方法，包括：
在通过与全局事务的数据库服务器的多个数据库会话用所述数据库服务器发起的一个或多个本地事务内：
在特定数据库会话内，对于所述全局事务的特定本地事务，从事务管理器接收执行所述全局事务的提交命令的请求；
接收对在不同数据库会话内的提交命令的结果的请求；
通过确定针对所述特定本地事务的特定本地事务控制是有效的，确定所述数据库服务器保证对所述全局事务的提交命令的结果的确定；以及
响应于确定所述特定本地事务控制是有效的，返回所述全局事务的提交命令的结果。
2.如权利要求1所述的方法，其中对所述提交命令的结果的请求包括所述特定本地事务的本地事务句柄。
3.如权利要求2所述的方法，其中确定针对所述特定本地事务的所述特定本地事务控制是有效的包括分析所述特定本地事务的所述本地事务句柄的状态信息。
4.如权利要求1所述的方法，还包括：
在所述特定数据库会话内接收对所述全局事务的特定全局事务分支的全局启动事务请求；
响应于接收到所述全局启动事务请求，使所述特定本地事务控制失效。
5.如权利要求1所述的方法，还包括：
在所述特定数据库会话内接收对所述全局事务的特定全局事务分支的全局结束事务请求；
响应于接收到所述全局结束事务请求，使所述特定本地事务控制生效。
6.如权利要求1所述的方法，还包括：
在所述特定数据库会话内接收对所述全局事务的特定全局事务分支的全局准备事务请求；
响应于接收到所述全局准备事务请求，使所述特定本地事务控制失效。
7.如权利要求1所述的方法，还包括：
利用有效的本地事务控制通过所述特定数据库会话接收对所述全局事务的全局提交事务请求；
确定所述全局提交事务请求指定一阶段提交优化；以及
响应于确定所述全局提交事务请求指定所述一阶段提交优化，用所述特定数据库会话的本地事务句柄在所述数据库服务器上提交所述全局事务。
8.如权利要求7所述的方法，还包括：
响应于确定所述全局提交事务请求指定所述一阶段提交优化，将所述特定数据库会话的所述本地事务句柄与所述有效的本地事务控制相关联地存储在所述数据库服务器上作为该提交的一部分，并且然后递增并向所述数据库服务器返回新的有效的本地事务句柄，以由后续事务使用。
9.如权利要求7所述的方法，还包括：
在所述特定本地事务内接收到对所述全局事务的特定全局事务分支的全局提交事务请求之前，接收对所述全局事务的第一全局事务分支的全局准备事务请求；
确定为所述第一全局事务分支执行的命令是只读的；
响应于接收到对所述第一全局事务分支的所述全局准备事务请求，返回指示所述第一全局事务分支是只读的数据。
10.如权利要求1所述的方法，还包括：
在第一数据库会话中接收在第一本地事务内执行第一提交命令的本地事务请求；
响应于接收到所述本地事务请求，使针对所述第一本地事务的第一本地事务控制生效。
11.如权利要求10所述的方法，其中使针对所述第一本地事务的第一本地事务控制生效是用所述第一提交命令原子地执行的。
12.如权利要求10所述的方法，还包括：
响应于所述第一本地事务中的错误，在与所述第一数据库会话不同的第二数据库会话中发出对所述第一提交命令的结果的请求；
确定针对所述第一本地事务的所述第一本地事务控制是有效的还是无效的；以及
响应于确定第一本地事务控制是有效的，返回所述第一本地事务的提交命令的结果。
13.如权利要求10所述的方法，还包括：
在所述特定本地事务内接收将所述第一本地事务提升为所述全局事务的请求；
响应于提升请求，
将所述第一本地事务提升为所述全局事务，以及
使针对所述全局事务的所述特定本地事务控制失效。
14.如权利要求13所述的方法，还包括：
接收对所述第一本地事务已经被提升到的所述全局事务的全局准备事务请求；
响应于接收到所述全局准备事务请求，使针对所述特定本地事务的所述特定本地事务控制失效。
15.如权利要求13所述的方法，还包括：
接收对所述第一本地事务已经被提升到的所述全局事务的全局提交事务请求；
响应于接收到所述全局提交事务请求，如果所述特定本地事务控制是有效的，则使所述特定本地事务控制失效。
16.如权利要求2所述的方法，其中所述提交命令的结果与所述本地事务句柄相关联地存储在所述数据库服务器中，作为所述全局事务的提交命令的原子操作。
17.一种方法，包括：
利用一个或多个资源管理器建立与全局事务的资源管理器的会话，其中所述一个或多个资源管理器包括所述资源管理器；
响应于建立与所述资源管理器的会话，通过所述会话利用所述资源管理器从所述资源管理器接收与本地事务相关联的本地事务句柄；
发出提交命令以提交在所述全局事务的所述资源管理器上执行的一个或多个事务命令集；
建立与所述资源管理器的新会话；
确定所述本地事务句柄是有效的；
响应于确定所述本地事务句柄是有效的，使用所述本地事务句柄，在与所述会话不同的所述新会话内请求所述提交命令的结果；
响应于请求，接收所述全局事务的提交命令的提交结果。
18.如权利要求17所述的方法，其中所述资源管理器是数据库服务器，并且所述会话是与所述数据库服务器的数据库会话。
19.如权利要求17所述的方法，其中所述提交命令指定一阶段提交优化。
20.如权利要求17所述的方法，还包括：
在建立与所述资源管理器的所述会话之前，针对第一本地事务建立与所述资源管理器的第一会话；
响应于建立与所述资源管理器的所述第一会话，通过所述第一会话利用所述资源管理器从所述资源管理器接收与所述第一本地事务相关联的第一本地事务句柄；
在所述第一本地事务内发出一个或多个第一事务命令集以供所述资源管理器执行。
21.如权利要求20所述的方法，还包括：
在所述第一会话中发出在所述第一本地事务内执行所述一个或多个第一事务命令集的第一提交命令的本地事务请求；
响应于发出所述本地事务请求，在所述第一会话的所述第一本地事务内接收执行所述第一提交命令的错误；
确定所述第一本地事务句柄是有效的；
使用所述第一本地事务句柄，在与所述第一会话不同的第二会话中请求所述第一提交命令的结果；以及
响应于请求，接收所述第一本地事务的所述第一提交命令的提交结果。
22.如权利要求20所述的方法，还包括：
通过所述会话在所述本地事务内请求所述资源管理器将所述第一本地事务提升为所述全局事务；
响应于请求，接收包括成功状态和对于所述全局事务已经失效的所述第一本地事务句柄的响应以及对提升请求已经成功的确认，所述成功状态指示在所述全局事务的所述资源管理器上执行的所述一个或多个事务命令集包括所述第一本地事务内的一个或多个第一事务命令集。
23.如权利要求17所述的方法，还包括：
在建立与所述资源管理器的所述会话之前，建立与所述全局事务的所述资源管理器的第一会话；
响应于建立与所述资源管理器的所述第一会话，通过所述第一会话利用所述资源管理器从所述资源管理器接收与第一本地事务相关联的第一本地事务句柄；
发出以下中的一个：
针对所述全局事务的全局事务分支的全局启动事务请求，或
针对所述全局事务的全局事务分支的全局准备事务请求，或
针对所述本地事务到所述全局事务的提升请求；
在与所述资源管理器的第二数据库会话中发出提交命令；
使用所述第一本地事务句柄，在所述第二数据库会话内请求所述提交命令的结果；
响应于请求，接收所述第一本地事务句柄已经失效的错误。
24.如权利要求23所述的方法，其中响应于接收到所述提交命令的错误，发生对所述提交命令的结果的请求。
25.如权利要求17所述的方法，还包括：
从客户端计算设备接收对事务管理器在所述资源管理器上执行所述一个或多个事务命令集的请求；
响应于从所述客户端计算设备接收到所述请求，将客户端事务句柄返回给所述客户端计算设备；
从所述客户端计算设备接收对状态的请求，所述对状态的请求包括所述客户端事务句柄；
基于所述客户端事务句柄，强制与所述客户端事务句柄对应的所述全局事务的提交结果；
基于强制所述提交结果，生成并向所述客户端计算设备发送所述提交结果。
26.如权利要求25所述的方法，其中所述全局事务的提交命令的提交结果是未提交。
27.如权利要求17所述的方法，其中所述全局事务的提交命令的提交结果是未提交，并且所述方法还包括：响应于接收到未提交的提交结果，自动地重放所述全局事务。
28.如权利要求27所述的方法，其中重放所述全局事务还包括：
利用包括所述资源管理器的所述一个或多个资源管理器，针对新全局事务建立与所述资源管理器的第二会话；
响应于建立与所述资源管理器的所述第二会话，通过所述第二会话利用所述资源管理器从所述资源管理器接收与第二本地事务相关联的第二本地事务句柄；
请求所述资源管理器使用针对一个或多个第一事务命令集的所述本地事务句柄来确定所述一个或多个第一事务命令集的提交结果；
响应于从所述资源管理器接收到未提交的结果，使用所述第二会话将所述一个或多个事务命令集向所述资源管理器重新发出；然后
重新发出命令以提交重新发出的在所述全局事务的所述资源管理器上执行的一个或多个事务命令集。
29.如权利要求27所述的方法，还包括自动重复重放，直到已经达到预先配置的重放次数或者事务管理器接收到具有所述一个或多个事务命令集的后续全局事务的成功提交结果为止。
30.如权利要求29所述的方法，还包括：
在重放之前，响应于从客户端计算设备接收到在所述资源管理器上执行所述一个或多个事务命令集的请求，将客户端事务句柄返回给所述客户端计算设备；
基于响应于所述重放而接收到的提交命令的状态，生成并向所述客户端计算设备发送客户端状态。
31.存储指令的一种或多种非暂态存储介质，所述指令在由一个或多个计算设备执行时，使得执行如权利要求1-30中任一项所述的方法。
32.一种包括用于执行如权利要求1-30中任一项所述的方法的组件的装置。
33.一种***，包括：
处理器；以及
存储器，耦合到所述处理器并且所述存储器包括存储在其上的指令，所述指令在由所述处理器执行时，使得所述处理器执行如权利要求1-30中任一项所述的方法。
CN201780014395.2A 2016-01-28 2017-01-27 分布式事务处理***中有保证的提交结果 Active CN108701157B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/009,660 2016-01-28
US15/009,660 US10339127B2 (en) 2016-01-28 2016-01-28 Guaranteed commit outcome in a distributed transaction processing system
PCT/US2017/015507 WO2017132621A1 (en) 2016-01-28 2017-01-27 Guaranteed commit outcome in a distributed transaction processing system

Publications (2)

Publication Number Publication Date
CN108701157A CN108701157A (zh) 2018-10-23
CN108701157B true CN108701157B (zh) 2022-03-01

Family

ID=58057251

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201780014395.2A Active CN108701157B (zh) 2016-01-28 2017-01-27 分布式事务处理***中有保证的提交结果

Country Status (4)

Country Link
US (1) US10339127B2 (zh)
EP (1) EP3408763B1 (zh)
CN (1) CN108701157B (zh)
WO (1) WO2017132621A1 (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105900059B (zh) 2014-01-21 2019-06-07 甲骨文国际公司 用于在应用服务器、云或其它环境中支持多租户的***和方法
KR102437664B1 (ko) * 2014-09-26 2022-08-29 오라클 인터내셔날 코포레이션 멀티테넌트 어플리케이션 서버 환경에서 트랜잭션 복구를 위한 시스템 및 방법
US10585873B2 (en) 2017-05-08 2020-03-10 Sap Se Atomic processing of compound database transactions that modify a metadata entity
CN110019112B (zh) 2017-08-25 2023-10-31 阿里巴巴集团控股有限公司 数据事务处理方法、装置以及电子设备
US12007941B2 (en) 2017-09-29 2024-06-11 Oracle International Corporation Session state tracking
US11188516B2 (en) * 2018-08-24 2021-11-30 Oracle International Corproation Providing consistent database recovery after database failure for distributed databases with non-durable storage leveraging background synchronization point
US11334445B2 (en) 2018-10-19 2022-05-17 Oracle International Corporation Using non-volatile memory to improve the availability of an in-memory database
US11936739B2 (en) * 2019-09-12 2024-03-19 Oracle International Corporation Automated reset of session state
US11652892B2 (en) 2019-09-30 2023-05-16 Oracle International Corporation Automatic connection load balancing between instances of a cluster
CN112988883B (zh) * 2019-12-16 2023-03-10 金篆信科有限责任公司 数据库的数据同步方法、装置以及存储介质
FR3110723B1 (fr) * 2020-05-21 2022-05-13 Amadeus Mise à jour de session de base de données asynchrone
CN113296897B (zh) * 2020-07-21 2023-12-26 阿里巴巴集团控股有限公司 一种分布式事务的处理方法、装置、设备和机器可读介质
US11741007B2 (en) * 2021-01-15 2023-08-29 Neo4J Sweden Ab Memory guards for continuous load-adaptive processing of transactions in databases
US12038912B2 (en) * 2022-10-14 2024-07-16 Oracle International Corporation Transaction manager library for automatic enlisting of distributed XA participants

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101699439A (zh) * 2009-11-16 2010-04-28 中兴通讯股份有限公司 一种数据库的事务提交方法和装置
CN103546440A (zh) * 2012-07-16 2014-01-29 上海宝信软件股份有限公司 一种客户端发起事务的事务实现方法和***
CN103995868A (zh) * 2014-05-20 2014-08-20 科大国创软件股份有限公司 面向分布式***的全局事务管理器及事务处理方法
CN104793988A (zh) * 2014-01-20 2015-07-22 阿里巴巴集团控股有限公司 跨数据库分布式事务的实现方法和装置
CN105183544A (zh) * 2015-09-17 2015-12-23 中国科学院计算技术研究所 一种非阻塞式容错的分布式事务提交方法及***

Family Cites Families (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3392236B2 (ja) 1994-11-04 2003-03-31 富士通株式会社 分散トランザクション処理システム
US6275843B1 (en) 1994-12-22 2001-08-14 Unisys Corporation Method and apparatus for processing multiple service requests within a global transaction by a single server application program instance
WO1996027157A1 (fr) 1995-02-28 1996-09-06 Ntt Data Communications Systems Corporation Systeme associatif decentralise et traitements de journaux et de reprise dans celui-ci
US6041357A (en) 1997-02-06 2000-03-21 Electric Classified, Inc. Common session token system and protocol
US5966706A (en) 1997-02-19 1999-10-12 At&T Corp Local logging in a distributed database management computer system
US6490610B1 (en) 1997-05-30 2002-12-03 Oracle Corporation Automatic failover for clients accessing a resource through a server
US5983225A (en) 1998-01-26 1999-11-09 Telenor As Parameterized lock management system and method for conditional conflict serializability of transactions
US6182186B1 (en) 1998-06-30 2001-01-30 Sun Microsystems, Inc. Method and apparatus that utilizes lock states to lock resources
US6272675B1 (en) 1998-10-01 2001-08-07 Unisys Corporation Development system for automatically enabling a server application to execute with an XATMI-compliant transaction manager managing transactions within multiple environments
US6625601B1 (en) 1999-01-07 2003-09-23 Compaq Information Technologies Group, L.P. Escrow-locking multithreaded process-pair resource manager dictionary
US6801914B2 (en) 1999-03-15 2004-10-05 Microsoft Corporation Persistent client-server database sessions
US6529921B1 (en) 1999-06-29 2003-03-04 Microsoft Corporation Dynamic synchronization of tables
US7290056B1 (en) 1999-09-09 2007-10-30 Oracle International Corporation Monitoring latency of a network to manage termination of distributed transactions
US6732175B1 (en) 2000-04-13 2004-05-04 Intel Corporation Network apparatus for switching based on content of application data
US6442552B1 (en) 2000-06-30 2002-08-27 Hewlett-Packard Company Method and apparatus for implementing three tier client asynchronous transparency
US6922792B2 (en) 2000-10-27 2005-07-26 Eternal Systems, Inc. Fault tolerance for computer programs that operate over a communication network
US20020087366A1 (en) 2000-12-30 2002-07-04 Collier Timothy R. Tentative-hold-based protocol for distributed transaction processing
US7539746B2 (en) 2001-02-01 2009-05-26 Emc Corporation Highly available transaction failure detection and recovery for electronic commerce transactions
US6850938B1 (en) 2001-02-08 2005-02-01 Cisco Technology, Inc. Method and apparatus providing optimistic locking of shared computer resources
US7849173B1 (en) 2001-12-31 2010-12-07 Christopher Uhlik System for on-demand access to local area networks
US7949702B2 (en) 2002-01-09 2011-05-24 International Business Machines Corporation Method and apparatus for synchronizing cookies across multiple client machines
US20040015600A1 (en) 2002-02-21 2004-01-22 Ashutosh Tiwary Workload post-processing and parameterization for a system for performance testing of N-tiered computer systems using recording and playback of workloads
US6963996B2 (en) 2002-04-30 2005-11-08 Intel Corporation Session error recovery
JP4406604B2 (ja) 2002-06-11 2010-02-03 アシシュ エイ パンドヤ Ｔｃｐ／ｉｐ、ｒｄｍａ、及びｉｐストレージアプリケーションのための高性能ｉｐプロセッサ
US7631107B2 (en) 2002-06-11 2009-12-08 Pandya Ashish A Runtime adaptable protocol processor
US7558883B1 (en) * 2002-06-28 2009-07-07 Microsoft Corporation Fast transaction commit
US7103597B2 (en) 2002-10-03 2006-09-05 Mcgoveran David O Adaptive transaction manager for complex transactions and business process
WO2004055674A1 (ja) 2002-12-18 2004-07-01 Fujitsu Limited 分散トランザクション処理装置、分散トランザクション処理プログラム、分散トランザクション処理方法および分散トランザクション処理システム
US7281050B2 (en) 2003-04-08 2007-10-09 Sun Microsystems, Inc. Distributed token manager with transactional properties
US7082432B2 (en) 2003-04-24 2006-07-25 Sun Microsystems, Inc. Specifying transaction manager type at various application levels
US7743083B2 (en) 2003-04-24 2010-06-22 Oracle America, Inc. Common transaction manager interface for local and global transactions
US7228455B2 (en) 2003-05-09 2007-06-05 Oracle International Corporation Transaction branch management to ensure maximum branch completion in the face of failure
US7100076B2 (en) 2003-05-09 2006-08-29 Hewlett-Packard Development Company, L.P. Minimum latency reinstatement of database transaction locks
US7346905B2 (en) 2003-06-10 2008-03-18 International Business Machines Corporation Apparatus and method for maintaining resource integrity without a unified transaction manager in a software environment
US7739252B2 (en) 2003-07-14 2010-06-15 Oracle America, Inc. Read/write lock transaction manager freezing
CN100547583C (zh) 2003-08-14 2009-10-07 甲骨文国际公司 数据库的自动和动态提供的方法
US7260589B2 (en) 2003-12-04 2007-08-21 International Business Machines Corporation High performance support for XA protocols in a clustered shared database
US7340452B2 (en) 2003-12-16 2008-03-04 Oracle International Corporation Parallel single cursor model on multiple-server configurations
US7168001B2 (en) 2004-02-06 2007-01-23 Hewlett-Packard Development Company, L.P. Transaction processing apparatus and method
US20050186975A1 (en) 2004-02-10 2005-08-25 Yach David P. Apparatus, and associated method, for facilitating initiation of synchronization of database copies connected by way of a radio air interface
US8615601B2 (en) 2004-05-21 2013-12-24 Oracle International Corporation Liquid computing
US7725432B2 (en) 2004-05-21 2010-05-25 Bea Systems, Inc. Logging last resource system
US7490089B1 (en) 2004-06-01 2009-02-10 Sanbolic, Inc. Methods and apparatus facilitating access to shared storage among multiple computers
US7502824B2 (en) 2004-08-12 2009-03-10 Oracle International Corporation Database shutdown with session migration
US7415470B2 (en) 2004-08-12 2008-08-19 Oracle International Corporation Capturing and re-creating the state of a queue when migrating a session
US7587400B2 (en) 2004-08-12 2009-09-08 Oracle International Corporation Suspending a result set and continuing from a suspended result set for transparent session migration
US8055711B2 (en) 2004-10-29 2011-11-08 Emc Corporation Non-blocking commit protocol systems and methods
US9323922B2 (en) 2005-01-06 2016-04-26 Oracle International Corporation Dynamically differentiating service in a database based on a security profile of a user
US7376675B2 (en) 2005-02-18 2008-05-20 International Business Machines Corporation Simulating multi-user activity while maintaining original linear request order for asynchronous transactional events
US7761435B2 (en) 2005-04-29 2010-07-20 Sap Ag External persistence of session state information
US7853698B2 (en) 2005-04-29 2010-12-14 Sap Ag Internal persistence of session state information
US8145627B2 (en) 2005-06-10 2012-03-27 Hewlett-Packard Development Company, L.P. Use of connectivity analysis to assist rule-based optimizers
US7430559B2 (en) 2005-09-21 2008-09-30 Microsoft Corporation Generalized idempotent requests
US7640242B2 (en) 2006-03-24 2009-12-29 Oracle International Corp. Light weight locking model in the database for supporting long duration transactions
US7996837B2 (en) 2006-05-03 2011-08-09 Oracle International Corporation Recovery mechanism for transactions
US7877373B2 (en) 2006-06-30 2011-01-25 Oracle International Corporation Executing alternative plans for a SQL statement
US8176022B1 (en) 2006-08-26 2012-05-08 Radames Garcia Locking protocol using dynamic locks and dynamic shared memory
US8024299B2 (en) 2006-10-20 2011-09-20 Oracle International Corporation Client-driven functionally equivalent database replay
US7984015B2 (en) 2006-10-20 2011-07-19 Oracle International Corporation Database workload capture and replay architecture
US7890458B2 (en) 2006-10-20 2011-02-15 Oracle International Corporation Capturing database workload while preserving original transactional and concurrency characteristics for replay
US20080098003A1 (en) 2006-10-20 2008-04-24 Oracle International Corporation Database workload replay remapping infrastructure
US7890457B2 (en) 2006-10-20 2011-02-15 Oracle International Corporation Transactionally consistent database workload replay
US7634512B2 (en) 2006-10-20 2009-12-15 Oracle International Corporation Migrating temporary data of a session
US8392483B2 (en) 2006-11-20 2013-03-05 Matrikon Inc. Ontological database design
US8768890B2 (en) 2007-03-14 2014-07-01 Microsoft Corporation Delaying database writes for database consistency
US8326816B2 (en) 2010-05-06 2012-12-04 Oracle International Corporation Fine grain synchronization for database replay
US7904434B2 (en) 2007-09-14 2011-03-08 Oracle International Corporation Framework for handling business transactions
US7970737B2 (en) 2008-01-11 2011-06-28 Oracle International Corporation Recovery administration of global transaction participants
US7882173B2 (en) 2008-06-30 2011-02-01 International Business Machines Corporation Interactive remote command execution over a stateless client/server network protocol
US8433680B2 (en) 2008-07-01 2013-04-30 Oracle International Corporation Capturing and restoring database session state
US20100030818A1 (en) 2008-07-31 2010-02-04 Yahoo! Inc. System and method for applying once a transaction delivered in a message published asynchronously in a distributed database
US8224850B2 (en) 2008-08-13 2012-07-17 Motorola Mobility, Inc. Method and system for determining users that satisfy desired conditions
US8296358B2 (en) 2009-05-14 2012-10-23 Hewlett-Packard Development Company, L.P. Method and system for journaling data updates in a distributed file system
US20100318394A1 (en) 2009-06-15 2010-12-16 Microsoft Corporation Executing transactions as an atomic unit
US8556724B2 (en) 2009-09-30 2013-10-15 Zynga Inc. Apparatuses, methods and systems for an online game manager
EP2363806A1 (en) 2010-03-03 2011-09-07 Software AG Connection handler and method for providing applications with heterogeneous connection objects
US8584124B2 (en) 2010-04-20 2013-11-12 Salesforce.Com, Inc. Methods and systems for batch processing in an on-demand service environment
US8442962B2 (en) 2010-12-28 2013-05-14 Sap Ag Distributed transaction management using two-phase commit optimization
US8868514B2 (en) 2011-01-07 2014-10-21 Microsoft Corporation Transaction support for distributed data
US8725882B2 (en) * 2011-09-09 2014-05-13 Oracle International Corporation Masking database outages from clients and applications
US8549154B2 (en) 2011-09-09 2013-10-01 Oracle International Corporation Recovering stateful read-only database sessions
US8924346B2 (en) 2011-09-09 2014-12-30 Oracle International Corporation Idempotence for database transactions
US8984170B2 (en) 2011-09-09 2015-03-17 Oracle International Corporation Idempotence for database transactions
US9600371B2 (en) 2011-09-09 2017-03-21 Oracle International Corporation Preserving server-client session context
US10210175B2 (en) 2012-09-28 2019-02-19 Oracle International Corporation Techniques for lifecycle state management and in-database archiving
GB2513532A (en) 2012-12-05 2014-11-05 Ibm Distributed transaction routing
GB2517932B (en) * 2013-09-04 2021-05-05 1Spatial Group Ltd Modification and validation of spatial data
US9418364B2 (en) 2013-10-25 2016-08-16 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for distributed transactions in a data communication network
US9361190B2 (en) * 2014-04-24 2016-06-07 International Business Machines Corporation Recovery of a transaction after XA end
US10242027B2 (en) * 2014-08-15 2019-03-26 Hewlett-Packard Development Company, L.P. Three phase commit for a distributed file system
US10430402B2 (en) * 2015-01-16 2019-10-01 Red Hat, Inc. Distributed transaction with dynamic form

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101699439A (zh) * 2009-11-16 2010-04-28 中兴通讯股份有限公司 一种数据库的事务提交方法和装置
CN103546440A (zh) * 2012-07-16 2014-01-29 上海宝信软件股份有限公司 一种客户端发起事务的事务实现方法和***
CN104793988A (zh) * 2014-01-20 2015-07-22 阿里巴巴集团控股有限公司 跨数据库分布式事务的实现方法和装置
CN103995868A (zh) * 2014-05-20 2014-08-20 科大国创软件股份有限公司 面向分布式***的全局事务管理器及事务处理方法
CN105183544A (zh) * 2015-09-17 2015-12-23 中国科学院计算技术研究所 一种非阻塞式容错的分布式事务提交方法及***

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Inferring a Serialization Order for Distributed Transactions;Khuzaima Daudjee；Kenneth Salem;《Proceedings of the 22nd International Conference on Data Engineering》;20060403;全文 *
面向内存数据网格的分布式事务保障机制;刘朝辉；王伟;《计算机科学与探索》;20131216;全文 *

Also Published As

Publication number Publication date
CN108701157A (zh) 2018-10-23
WO2017132621A1 (en) 2017-08-03
EP3408763A1 (en) 2018-12-05
US20170220621A1 (en) 2017-08-03
US10339127B2 (en) 2019-07-02
EP3408763B1 (en) 2022-09-07

Similar Documents

Publication Publication Date Title
CN108701157B (zh) 分布式事务处理***中有保证的提交结果
CN107787490B (zh) 分布式数据库网格中的直接连接功能
US9591103B2 (en) Transactional and non-transactional data for maintaining session state
US10250693B2 (en) Idempotence for database transactions
EP1062569B1 (en) Isolation levels and compensating transactions in an information system
EP2825957B1 (en) Systems and methods for supporting inline delegation of middle-tier transaction logs to database
CN111259083A (zh) 分布式事务处理方法及装置
US20130066949A1 (en) Idempotence for database transactions
US6061708A (en) System and method for supporting mixed-phase transactions in an object-oriented environment
US20150074070A1 (en) System and method for reconciling transactional and non-transactional operations in key-value stores
US20160294726A1 (en) System and method for reducing communications overhead in a distributed transactions environment by modifying implementation of the transaction end function
US20060149791A1 (en) Database-driven distributed recovery
WO2021237190A1 (en) Distributed transaction execution in distributed databases
US11176115B2 (en) Dependency locking
WO2023111910A1 (en) Rolling back database transaction
US11392562B2 (en) Hybrid client transaction mode for key value store
US20240126745A1 (en) Database-native automatic compensation for sagas
Wang et al. Ad Hoc Transactions through the Looking Glass: An Empirical Study of Application-Level Transactions in Web Applications
Design HP Reliable Transaction Router Application Design Guide

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
GR01 Patent grant
GR01 Patent grant