CN102135899A

CN102135899A - 一种事务控制方法及装置

Info

Publication number: CN102135899A
Application number: CN 201010105099
Authority: CN
Inventors: 徐永胜; 姜琰祥; 房厚波
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2010-01-26
Filing date: 2010-01-26
Publication date: 2011-07-27
Anticipated expiration: 2030-01-26
Also published as: CN102135899B

Abstract

本发明实施例提供一种处理事务的方法及装置，属于计算机通信技术领域，其中所述方法包括：在多服务调用过程中，当被调用的当前服务需要启动事务时，检测是否已有其它服务启动事务；若没有其它服务启动事务，则当前服务启动事务，并进行当前服务处理；在当前服务处理完毕后，提交启动的事务，并退出当前服务。通过本发明实施例所提供的方法及装置，可以保证处理的事务要么都提交，要么都回滚，有效的保证了事务处理的原子性与一致性。

Description

一种事务控制方法及装置

技术领域

本发明涉及计算机通信技术领域，特别涉及一种事务控制方法及装置。

背景技术

随着计算机通信技术的发展，金融、电信、交通等许多行业都开始通过计算机通信技术对行业各自的业务进行控制和处理。比如中间件技术的出现就很好的解决了客户端与服务器之间应用程序调用的麻烦，使得应用程序的开发变得简单。目前应用广泛的中间件产品为BEA公司的Tuxedo(Transaction for UNIX has been Extended for Distributed Operation，即被分布式操作扩展之后的UNIX事务***)，它是一种在企业和网络这样的分布式运算环境中开发和管理三层结构的客户/服务器型关键任务应用***的强有力工具。它具备分布式事务处理和应用通信功能，并提供完善的各种服务来建立、运行和管理关键任务应用***。开发人员能够用它建立跨多个硬件平台、数据库和操作***的可互操作的应用***，满足在分布式异构计算环境下运行大量应用的需求，从而使事务在全球范围内跨任何***，从面向客户的关键任务应用延伸到后台处理。

然而，现有技术中的中间件平台(比如Tuxedo)连接的设备较多，构成的***很庞杂，需要处理数以万计的各种事务，而在处理事务的过程中存在数次提交处理结果的问题，造成冲突，使得现有处理事务的机制无法保证事务操作的原子性与一致性，所以如何进一步提高事务处理的原子性与一致性已成为本领域技术人员长期以来迫切希望解决的技术问题。

发明内容

本发明实施例的目的在于提供一种事务控制方法及装置，通过本发明实施例所提供的方法及装置，可以保证处理的事务要么都提交，要么都回滚，有效的保证了事务处理的原子性与一致性。

为实现上述目的，本发明实施例提供一种事务控制方法，所述方法包括：

在多服务调用过程中，当被调用的当前服务需要启动事务时，检测是否已有其它服务启动事务；

若没有其它服务启动事务，则当前服务启动事务，并进行当前服务处理；

在当前服务处理完毕后，提交启动的事务，并退出当前服务。

为实现上述目的，本发明实施例还提供一种事务控制装置，所述装置包括：

检测单元，用于在多服务调用过程中，当被调用的当前服务需要启动事务时，检测是否已有其它服务启动事务，若检测出没有其它服务启动事务，则将检测出的没有其它服务启动事务的结果发送至启动单元；

启动单元，用于根据所述检测单元发送的结果来启动所述事务；

服务处理单元，用于在所述启动单元启动所述事务后，对当前服务进行处理；

提交单元，用于在所述服务处理单元对当前服务处理完毕后，提交被启动的事务；

服务退出单元，用于在所述提交单元提交被启动的事务之后，退出当前服务。

由于本发明实施例在整个多服务调用过程中，最多只启动一次事务，而且由启动事务的服务进行事务提交，使得所有服务所进行的操作要么都提交，要么都回滚，保证了事务的原子性与一致性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的事务控制方法的示意流程图。

图2为本发明另一实施例提供的事务控制方法的示意流程图。

图3为本发明实施例在缴费业务中进行事务控制的方法流程示意图。

图4为本发明实施例提供的一种事务控制装置的功能结构框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供一种处理事务的技术，可以应用于分布式数据库场景中。这种技术可以在多服务调用过程中将所调用服务的结果一并提交，从而有效解决了各服务提交冲突的问题，保证了处理事务的原子性与一致性。其中这种多服务的调用可以是嵌套服务调用场景，当然也可以是其他的服务调用场景。所谓嵌套服务调用即是指在对当前服务处理时，通过调用其它服务协同来完成对当前服务进行处理的一种服务处理方式。比如在对服务A处理的进程中，若还需要通过其它服务B的协助完成对服务A的处理，则调用相应的服务B，服务B处理完成后返回服务A，使当前服务的处理得以继续进行，直至处理结束。在嵌套服务调用的过程中也可能存在多重嵌套，如，被调用的服务B如果还需要通过服务C来协助完成，则服务B进一步调用服务C，服务C处理完成后返回服务B，服务B进行继续处理，处理完成后返回服务A。

上述调用过程中，服务A的生命周期涵盖服务B，服务B的生命周期涵盖服务C。由于各服务生命周期不同，在目前的多服务调用过程中，存在事务控制丢失或事务分段等问题，导致整个事务的原子性得不到保证。

基于此，本实施例提供一种处理事务的方法，如图1所示，图1为本实施例的处理事务的方法的示意流程图，该流程包括如下步骤：

101.在多服务调用过程中，当被调用的当前服务需要启动事务时，检测是否已有其它服务启动事务。对于多服务调用的场景，由于有的服务本身不需要启动事务，比如查询服务，所以需要对被调用的服务的这一属性进行判断，确定其是否需要启动事务，具体确定过程为本领域的公知技术，这里不再赘述。

若当前调用的服务需要启动事务，则检测是否已有其它服务启动事务，本发明实施例中可以通过各服务共享的全局事务的状态来检测是否已有其它服务启动事务。具体的，可为各服务设置事务共享区，全局事务状态记录在该事务共享区中。其中，全局事务状态的默认状态为未启动状态，当有服务启动事务时，则将该全局事务的状态更新为启动状态。因此，通过检测全局事务的状态是否为已启动状态可以确定是否有其它服务已启动事务。

102.若没有其它服务启动事务，则当前服务启动事务，并进行当前服务处理。

如果全局事务的状态为默认的未启动状态，则表明还没有其它服务启动事务，当前服务进行启动事务，并将全局事务的状态从默认的未启动状态更新为已启动状态，以便于其他服务进行检测。

103.在当前服务处理完毕后，提交启动的事务，并退出当前服务。

由于存在多服务嵌套调用的情况，如，在当前服务的处理过程中，当前服务还要调用另一嵌套服务进行处理。此时，在退出嵌套服务时，嵌套服务并不进行事务提交，而是由启动该事务的当前服务在退出服务时进行提交。

本发明实施例通过设置各服务自身的事务状态来确定该服务是否启动了事务。具体的，可以将各服务自身的事务状态记录在事务共享区，各服务自身的事务状态的默认状态为未启动状态，当有服务启动事务时，将该服务自身的事务状态更新为启动状态。因此，在步骤102中，当前服务启动事务后，则将自身的事务状态更新为已启动状态；而在步骤103中，当前服务处理完毕后，则检测当前服务自身的事务状态，根据更新后的已启动状态，触发提交事务的操作。

本发明实施例通过检测事务的启动情况，确保整个多服务调用过程中，最多只启动一次事务，并基于谁启动谁提交的原则，在处理完该服务后，由启动事务的服务提交启动的事务，使得所有服务的处理结果要么都提交，要么都回滚，保证了事务处理的原子性与一致性。

如图2所示，图2为本发明实施例的事务控制方法的详细示意流程图，该流程包括如下步骤：

201.应用***根据处理的业务调用相应的服务，该被调用的服务被启动；

其中，应用***可以是基于TUXEDO的跨多个硬件平台、数据库和操作***的可互操作的应用***，如，电信行业的BOSS***。应用***处理的业务根据应用***的不同而有所不同，如BOSS***处理的业务为缴费业务、客户资料修改业务等。根据不同的业务，应用***调用的服务也不相同。

202.检测当前被调用的服务的属性，判断是否需要启动事务，若被调用的当前服务需要启动事务，则转入步骤203；反之，则转入步骤205。

通常情况下，如果被调用的服务需要对数据库进行修改操作，则该服务需要启动事务。

203.当被调用的当前服务需要启动事务时，从事务共享区中读取全局事务的状态，若全局事务的状态为未启动状态，则转入步骤204；若全局事务的状态为启动状态，转入步骤205。

其中，事务共享区用于存放全局事务的状态和每个服务的事务状态。全局事务的状态用于标记整个调用过程中的事务启动情况，全局事务的默认状态为未启动状态，当有服务启动事务时，全局事务的状态被更新为启动状态。当全局事务状态为已启动状态时，所有服务不能再启动服务，以保证整个调用过程中最多只启动一次事务；当全局事务的状态为未启动状态时，整个调用过程中的任何一个服务，根据其需要都可以启动事务，当该服务启动事务后，将全局事务状态设置为已启动状态，以便其它服务检测和使用当前全局事务状态。各服务的事务状态用于标记各服务自身的事务启动情况，其默认为未启动状态，当其对应的服务启动事务时，被更新为已启动状态。

204.启动事务，并更新事务共享区中的全局事务状态以及当前服务的事务状态。

205.对当前服务进行处理。

当被调用的当前服务不需要启动事务或检测出全局事务的状态为已启动状态时，则直接转入本步骤对当前服务进行处理。若当前服务需要启动事务且检测出全局事务的状态为已启动状态时，则在步骤204之后转入本步骤。需要说明的是对服务本身进行处理为本领域的公知技术，这里不再赘述。

206.在当前服务处理完毕后，从事务共享区中读取当前服务的事务状态，若当前服务的事务状态为启动状态，则转入步骤207；若当前服务的事务状态为未启动状态，则转入步骤208。

当步骤206中对当前服务处理完毕后，需要检测当前服务自身的事务状态，以确定当前服务是否启动了事务，从而确定是否提交事务。由于步骤204中当前服务在启动事务时，已将自身的事务状态更新为已启动状态，因此，基于谁启动谁提交的原则，当前服务根据检测结果，触发提交事务的操作。

207.提交启动的事务。

若在处理当前服务时，还调用了其它嵌套服务，则在提交事务时，将当前服务的处理结果以及当前服务调用的嵌套服务的操作结果一并提交。

208.退出当前服务。

可选的，在退出当前服务时，还可以进一步将该当前服务自身的事务状态从已启动状态更新为未启动状态，将全局事务的状态也从已启动状态更新为未启动状态。

上述步骤205中，在对当前服务处理的过程中，若当前服务还要调用另一嵌套服务进行处理，则进入对嵌套服务的处理，其中对嵌套服务的处理过程可参考上述步骤201-208，当退出嵌套服务时继续转入步骤205对当前服务进行处理。

为了使本领域技术人员更好的理解本实施例所述的方法，下面列举一示例进行辅助说明，需要声明的是，该示例仅仅是为了便于本领域技术人员理解本实施例，所以不能将本示例中的具体步骤理解为本方法仅有的实施方式，即不能将将本示例中的具体步骤理解为限制本发明的因素。

如图3所示，图3为一种缴费事务中服务的调用关系示意图，由图3可知，A服务可以调用B服务，B服务可以调用C服务，所以B服务可以看成是A服务的嵌套服务，C服务可以看成是服务B的嵌套服务，其中A服务为查询欠费账单，本身无需启动事务；B服务为销账，本身需启动事务；C服务为销账日志，本身需启动事务。预先设置的A服务自身的事务状态用A-status表示，同样B服务自身的事务状态用B-status表示，C服务自身的事务状态用C-status表示，缴费事务的全局事务状态用G-status表示，其中A、B、C各服务自身的事务状态都默认为未启动状态。当G-status＝T时，表示全局事务状态为已启动状态，当G-status＝F时，表示全局事务状态为未启动状态，其中，缴费事务的全局事务状态默认为G-status＝F。这些服务的事务状态以及全局事务状态可以记录在事务共享区中，该事务共享区是一个共享的存储区，该存储区可以是可擦写的存储器。

全局事务状态初始G-status＝F，表示全局事务未启动。当用户操作A服务时，由于A服务是一种查询服务，所以A服务不需启动事务，所以在操作完A服务后，A服务自身的事务状态仍为A-status＝F。根据A服务的查询结果调用B服务，由于B服务的服务属性需要启动事务，所以检测缴费事务的全局事务状态为G-status＝F，说明还没有其它服务启动事务，满足启动事务的条件，由服务B启动事务，并将G-status＝F更新为G-status＝T，更新B-status＝F为B-status＝T。在B服务进行销账处理时还需调用C服务来进一步完成相应的处理内容，由于C服务的服务属性也需要启动事务，所以检测缴费事务的全局事务状态为G-status＝T，表示已有其它服务启动事务，无需再次启动事务，不更新C服务状态，即C-status＝F。C服务的处理完成后，检查C服务自身的事务状态为C-status＝F，所以不提交C服务的处理结果(即调用C服务的结果)，C服务退出后返回B服务，B服务根据C服务的操作结果完成自身服务处理，检查B服务自身的事务状态为B-status＝T，说明本次事务是由B服务启动的，可以由B服务提交所有服务的处理结果。B服务将自身的处理结果以及C服务的操作结果一并提交，并将G-status＝T修改为G-status＝F，B-status＝T修改为B-status＝F。从B服务退出后，在A服务中可以查询对缴费事务处理后的结果。

需要对上述示例说明的是服务之间的调用时通过下发交易码来实现的，该交易码为相应的命令字，不同的交易码对应的命令字不同，接收到交易码的服务即被激活，从而可以执行相应服务的操作。

通过本实施例可以清楚看出A服务的生命周期是从A1开始到A2结束；B服务的生命周期是从B1开始到B2结束；C服务的周期是从C1开始到C2结束。在B服务和C服务都需要启动事务的情况下，本发明实施例的方案中只允许了B服务启动事务，并由B服务对启动的事务进行提交，避免了现有技术由于无多服务调用的事务控制机制，而导致由B服务启动事务，C服务提交事务的情况出现，造成的C2B2期间事务控制丢失的问题，以及出现B服务、C服务分别启动事务，并分别进行事务提交的情况，导致在C2B2期间出错时，C1C2期间的操作无法回滚的问题。

上述方法实施例可以在跨平台、多服务、交易复杂、***庞大、接口众多的应用***中实现，如，电信行业中的BOSS***。该***可以基于XA接口框架的TUXEDO中间件平台三层开发和应用结构。实现上述方法实施例的装置可以是该***中的一个独立设备，也可以集成到该***现有的设备上，下面对该***中实现上述功能的装置进行说明。

如图4所示，图4为本发明实施例的事务控制装置的功能结构框图，该装置可以包括：检测单元401、启动单元402、服务处理单元403、提交单元404、服务退出单元405。其中：

检测单元401，用于在多服务调用过程中，当被调用的当前服务需要启动事务时，检测是否已有其它服务启动事务，若检测出没有其它服务启动事务，则将检测出的没有其它服务启动事务的结果发送至启动单元402。其中，检测单元401可以具体用于根据各服务共享的全局事务状态检测是否已有其它服务启动事务。该功能的具体实现可参考方法实施例部分，这里不再赘述。

启动单元402，用于根据检测单元401发出的结果来启动事务。当没有其它服务启动事务时，启动单元402进行事务启动；反之，启动单元402不进行事务启动。

服务处理单元403，用于在启动单元402启动事务后，对当前服务进行处理。

提交单元404，用于在服务处理单元403对当前服务处理完毕后，提交被启动的事务。

服务退出单元405，用于在提交单元404提交被启动的事务之后，退出当前服务。

上述各单元的具体实现可参考方法实施例部分，这里不再赘述。

可选的，检测单元401若检测出已有其它服务启动事务，则将检测出的已有其它服务启动事务的结果发送至所述服务处理单元403；服务处理单元403则直接根据检测单元401发送的结果对当前服务进行处理。

在服务处理单元403对当前服务处理完毕后，如果当前服务没有启动事务，则服务退出单元405直接退出服务。

具体的，在服务处理单元403对当前服务处理完毕后，可由检测单元401进一步检测当前服务自身的事务状态，若当前服务自身的事务状态为已启动状态，则检测单元401将检测出的当前服务自身的事务状态为已启动状态的结果发给所述提交单元404，触发提交单元404进行事务提交；若检测出当前服务自身的事务状态为未启动状态，则检测单元401将检测出的当前服务自身的事务状态为未启动状态的结果发给服务退出单元405，触发服务退出单元405退出当前服务。

可选的，该装置还可以包括：

共享单元406，用于存储各服务共享的全局事务状态以及各个服务自身的事务状态。本发明实施例中的事务共享区可以由事务控制装置以外的设备来实现，也可以由事务控制装置中的共享单元406来实现，其中，该共享单元406可以是各服务均可读写的存储介质。

状态更新单元407，用于在启动单元402启动事务后，将共享单元406中的全局事务的状态从默认的未启动状态更新为启动状态，并将当前服务自身的事务状态从默认的未启动状态更新为已启动状态。

可选的，状态更新单元407还可以用于在提交单元404提交被启动的事务时，将所述共享单元406中全局事务的状态更新为未启动状态，并将当前服务自身的事务状态更新为未启动状态。

需要说明的是本实施例中的部分单元的功能也可以通过一主控芯片实现，但主控芯片实现相应功能涉及到的逻辑关系与上述单元相同，所以并不能将此看成是与本实施例的区别，任何涉及与本实施例相同逻辑关系建立的硬件功能结构都在本发明的保护范围之内。

本实施例的优点在于，本实施例所述的装置可以有效解决处理事务过程中服务不同阶段提交产生的冲突问题，在处理整个事务的操作的生命周期中，只通过一个服务提交调用各个服务的结果，有效的保证了处理事务的原子性和一致性，大大提高了处理事务的准确性及可靠性，适用于数据量大，数据库布局分散的分布式数据库场景。比如可以适应XA接口框架的TUXEDO中间件平台，从而在金融、交通以及电信等行业中进行涉及多服务调用或嵌套服务调用的事务处理。

最后，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，包括如下步骤：

所述的存储介质可以为，如：ROM/RAM、磁碟、光盘等。

当然，以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的逻辑和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种事务控制方法，其特征在于，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述检测是否已有其它服务启动事务具体为通过各服务共享的全局事务的状态检测是否已有其它服务启动事务。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：在当前服务启动事务时，将所述全局事务的状态从默认的未启动状态更新为启动状态。

4.根据权利要求1-3任意一项所述的方法，其特征在于，所述方法还包括：

设置各服务自身的事务状态，所述各服务自身的事务状态的默认状态为未启动状态。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

当前服务启动事务时，将当前服务自身的事务状态从默认的未启动状态更新为已启动状态；

当所述服务处理完毕后，检测当前服务自身的事务状态，根据更新后的已启动状态，触发所述提交事务的操作。

6.根据权利要求4所述的方法，其特征在于，所述方法还包括：

若已有其它服务启动事务，则直接进行当前服务处理，并在当前服务处理完毕后，检测当前服务自身的事务状态，根据默认的未启动状态，触发退出当前服务的操作。

7.根据权利要求1-3任一项所述的方法，其特征在于，所述提交启动的事务包括：将所述当前服务的处理结果以及所述当前服务调用的嵌套服务的处理结果一并提交。

8.一种事务控制装置，其特征在于，所述装置包括：

启动单元，用于根据所述检测单元发送的结果来启动事务；

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

共享单元，用于存储各服务共享的全局事务状态以及各个服务自身的事务状态；

所述检测单元具体用于根据各服务共享的所述全局事务状态检测是否已有其它服务启动事务。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

状态更新单元，用于在所述启动单元启动事务后，将所述共享单元中的全局事务的状态从默认的未启动状态更新为启动状态，并将当前服务自身的事务状态从默认的未启动状态更新为已启动状态。

11.根据权利要求10所述的装置，其特征在于，

所述检测单元，还用于在检测是否已有其它服务启动事务时，若检测出已有其它服务启动事务，则将检测出的已有其它服务启动事务的结果发送至所述服务处理单元；

服务处理单元，还用于根据所述检测单元发送的结果对当前服务进行处理。

12.根据权利要求11所述的装置，其特征在于，

所述检测单元，还用于在所述服务处理单元对当前服务处理完毕后，检测当前服务自身的事务状态，若当前服务自身的事务状态为已启动状态，则将检测出的当前服务自身的事务状态为已启动状态的结果发给所述提交单元；

所述提交单元具体用于根据接收到的所述当前服务自身的事务状态为已启动状态的结果提交被启动的事务。

13.根据权利要求12所述的装置，其特征在于，

所述检测单元，还用于在检测出当前服务自身的事务状态为未启动状态时，将当前服务自身的事务状态为未启动状态的结果发给所述服务退出单元；

所述服务退出单元，还用于根据接收到的所述当前服务自身的事务状态为未启动状态的结果退出当前服务。

14.根据权利要求13所述的装置，其特征在于，

状态更新单元，还用于在所述提交单元提交被启动的事务时，将所述共享单元中的全局事务的状态更新为未启动状态，并将当前服务自身的事务状态更新为未启动状态。