跨数据库分布式事务的实现方法和装置.pdf

本申请公开了一种跨数据库分布式事务的实现方法，包括：接收分布式事务的启动请求，并为所述分布式事务分配事务标识；接收被分配事务标识的分布式事务的针对数据库操作的操作请求或操作请求集合；针对每个操作请求，获取所述数据库操作的目标数据库信息，并遵循ACID原则将所述数据库操作发送到所述目标数据库执行；待所有的数据库操作执行完毕，清除所述分布式事务。本申请同时提供一种跨数据库分布式事务的实现装置。采用本申请提供的方法能够实现轻量级、易于维护、并且满足ACID原则的跨数据库分布式事务。

1.  一种跨数据库分布式事务的实现方法，其特征在于，包括：
接收分布式事务的启动请求，并为所述分布式事务分配事务标识；
接收被分配事务标识的分布式事务的针对数据库操作的操作请求或操作请求集合；
针对每个操作请求，获取所述数据库操作的目标数据库信息，并遵循ACID原则将所述数据库操作发送到所述目标数据库执行；
待所有的数据库操作执行完毕，清除所述分布式事务。

2.  根据权利要求1所述的跨数据库分布式事务的实现方法，其特征在于，所述获取所述数据库操作的目标数据库信息具体是指，根据所述数据库操作指定的目标数据库和/或表的名称，查找预先设置的数据库描述信息，从中获取与所述目标数据库和/或表的名称对应的目标数据库信息。

3.  根据权利要求1所述的跨数据库分布式事务的实现方法，其特征在于，所述遵循ACID原则将所述数据库操作发送到所述目标数据库执行，包括：
获取所述数据库操作的类型；
解析所述数据库操作，获取所述数据库操作影响的行标识；
获取所述行标识对应的行的当前访问状态；
根据所述行标识对应的行的当前访问状态和所述数据库操作的类型，判断是否需要等待所述行标识对应的行的访问结束；若是，则执行等待，等到所述行标识对应的行的访问结束，再执行下述步骤；若否，继续执行下述步骤；
根据所述数据库操作的类型，判断是否需要获取对所述行标识对应的行的访问控制，若是，则为所述行标识对应的行添加访问控制后执行下述步骤；若否，执行下述步骤；
将所述数据库操作发送给所述目标数据库执行；
向所述分布式事务的请求方返回所述数据库操作的执行结果。

4.  根据权利要求3所述的跨数据库分布式事务的实现方法，其特征在于，执行所述将所述数据库操作发送给所述目标数据库执行的步骤后，如果没有在预先设定的时间内收到目标数据库返回的执行结果，则通过主动访问目标数据库的方式获取所述数据库操作的执行结果。

5.  根据权利要求3所述的跨数据库分布式事务的实现方法，其特征在于， 所述数据库操作的类型包括：新增操作、更新操作、删除操作或查询操作。

6.  根据权利要求5所述的跨数据库分布式事务的实现方法，其特征在于，所述解析所述数据库操作，获取所述数据库操作影响的行标识，包括：
如果所述数据库操作的类型为新增操作，则为所述新增操作分配一个唯一标识该行的行标识，并将所述行标识添加到新增操作中；
否则，执行下述步骤：
将所述数据库操作解析为采用相同条件的获取行标识的查询操作；
将所述查询操作发送给所述目标数据库执行；
接收所述目标数据库返回的行标识，将返回的行标识作为所述数据库操作影响的行标识。

7.  根据权利要求5所述的跨数据库分布式事务的实现方法，其特征在于，所述根据所述行标识对应的行的当前访问状态和所述数据库操作的类型，判断是否需要等待所述行标识对应的行的访问结束，具体是指：
如果所述数据库操作的类型是新增操作或者查询操作，则判定为不需要等待所述行标识对应的行的访问结束；
如果所述数据库操作的类型是更新操作或者删除操作，则进一步判断所述行标识对应的行当前是否没有被当前分布式事务之外的事务所访问，或者虽被当前分布式事务之外的事务访问但没有被锁定，若是，则判定为不需要等待所述行标识对应的行的访问结束；否则，判定为需要等待所述行标识对应的行的访问结束。

8.  根据权利要求5-7任意一项所述的跨数据库分布式事务的实现方法，其特征在于，所述根据所述数据库操作的类型，判断是否需要获取对所述行标识对应的行的访问控制，具体是指：
如果所述数据库操作的类型为新增操作、更新操作或者删除操作，则判定为需要获取对所述行标识对应的行的访问控制。
相应的，所述为所述行标识对应的行添加访问控制，具体是指，为所述行标识对应的行添加允许执行查询操作但不允许执行新增操作、更新操作和删除操作的过程锁。

9.  根据权利要求8所述的跨数据库分布式事务的实现方法，其特征在于， 在所述将所述数据库操作发送给所述目标数据库执行的步骤之前，执行下述操作：如果所述数据库操作的类型为查询操作，并且所述行标识中存在被当前分布式事务之外的事务锁定的行，则采用下述步骤重新构造查询操作：
获取所述被锁定的行当前执行的数据库操作的类型；
如果所述被锁定的行当前执行的数据库操作的类型为新增操作，将所述被锁定的行标记为不满足查询条件；
如果所述被锁定的行当前执行的数据库操作的类型为更新操作或者删除操作，则进一步判断所述被锁定的行在执行当前的更新操作或者删除操作之前是否满足所述查询操作的条件，若是，则记录满足所述查询操作的条件的行；否则，将所述被锁定的行标记为不满足查询条件；
生成剔除了所述不满足查询条件的行标识的查询操作；
相应的，所述将所述数据库操作发送给所述目标数据库执行是指，将重新构造的查询操作发送给所述目标数据库执行。
相应的，所述向所述分布式事务的请求方返回所述数据库操作的执行结果是指，将所述查询操作的执行结果，与已记录的满足所述查询操作的条件的行合并，并将合并后的结果返回给所述分布式事务的请求方。

10.  根据权利要求9所述的跨数据库分布式事务的实现方法，其特征在于，所述方法还包括：
将所述分布式事务的相关信息和所述分布式事务包括的数据库操作的相关信息写入与所述分布式事务标识对应的内存数据中。

11.  根据权利要求10所述的跨数据库分布式事务的实现方法，其特征在于，所述分布式事务的相关信息包括：所述分布式事务的事务标识、执行状态、和超时设置；
所述分布式事务包括的数据库操作的相关信息包括：目标数据库信息、影响的行标识、更新操作或删除操作执行前的行的内容、锁状态、执行状态、主动验证时间差、数据库操作语句和数据库操作的类型。

12.  根据权利要求11所述的跨数据库分布式事务的实现方法，其特征在于，所述清除所述分布式事务包括：
对所述分布式事务锁定的行执行解除锁定操作；
删除所述分布式事务标识及与所述分布式事务相关的内存数据。

13.  根据权利要求1-12任一所述的跨数据库分布式事务的实现方法，其特征在于，所述方法还包括：
获取数据库操作的执行结果，若所述分布式事务中的任一数据库操作未能执行成功，则对所述分布式事务中的已经成功执行的其他数据库操作执行回退操作，恢复到所述分布式事务执行前的状态。

14.  根据权利要求1-12所述的跨数据库分布式事务的实现方法，其特征在于，所述方法还包括：
判断所述分布式事务的持续时间，如果所述持续时间大于预先设定的时间，则触发异常处理程序进行处理。

15.  根据权利要求13所述的跨数据库分布式事务的实现方法，其特征在于，所述方法还包括：
将所述分布式事务的执行过程以及所述分布式事务对目标数据库所做的修改写入日志文件中。

16.  根据权利要求15所述的跨数据库分布式事务的实现方法，其特征在于，所述方法还包括：
读取所述日志文件，并根据所述日志文件中记录的分布式事务的信息，对尚未完成的分布式事务中的已经成功执行的数据库操作执行回退操作。

17.  一种跨数据库分布式事务的实现装置，其特征在于，包括：
事务启动单元，用于接收分布式事务的启动请求，并为所述分布式事务分配事务标识；
操作接收单元，用于接收被分配事务标识的分布式事务的针对数据库操作的操作请求或操作请求集合；
操作执行单元，用于针对每个操作请求，获取所述数据库操作的目标数据库信息，并遵循ACID原则将所述数据库操作发送到所述目标数据库执行；
事务清除单元，用于待所述分布式事务执行完毕后，清除所述分布式事务；
事务恢复单元，用于读取所述日志文件，并根据所述日志文件中记录的分布式事务的信息，对尚未完成的分布式事务执行回滚操作。

跨数据库分布式事务的实现方法和装置
技术领域
本申请涉及分布式事务处理领域，具体涉及一种跨数据库分布式事务的实现方法。本申请同时提供一种跨数据库分布式事务的实现装置。
背景技术
随着互联网的发展和用户需求的不断变化，各种应用业务越来越复杂。为了给业务提供更好的支撑，底层系统越来越多，服务越来越集中，层次也越来越深。对于一次业务请求，不再是通过访问某一个业务子系统中的数据库就可以完成，通常需要两个或者两个以上的业务子系统的协作，而不同的子系统使用不同的数据库，也就是说，在一次请求中，可能需要访问多个目标数据库中的数据，而且要求访问操作满足高实时性的需求。
在多个跨数据库业务请求并发的情况下，如果采用非同步操作的方式，容易导致整个目标数据库系统数据的不一致，为了解决这一问题，通常需要在中间层的系统中设计重试机制来保证数据一致和完整性，不仅降低了业务请求的处理效率，同时也增加了成本。在这样的背景下，为了满足多业务跨数据库的并发访问需求，出现了分布式事务的概念。
所谓事务，是数据库中的一个操作单元，在该操作单元中所有的操作要么都成功，要么都失败，执行结果不可逆转，事务具备四个基本的特性：原子性、一致性、隔离性、持久性，也简称为事务的ACID特性。而分布式事务则是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。因为分布式事务跨多个数据库资源，故要求分布式事务满足ACID属性对于维护所有数据库资源上的数据一致性是很重要的，因此评价事务是否支持分布式调用，主要看其分布式调用过程中是否满足事务的ACID原则。
为了实现分布式事务，现有技术通常使用两阶段提交协议。阶段一：事务协调者询问所有的事务参与者（例如：各个目标数据库）是否可以提交各自的操作，各个事务参与者根据自己的资源状况，向事务协调者发送是否可以提交 的应答。阶段二：当所有事务参与者在第一阶段反馈的都是肯定应答，那么协调者才会发起本阶段，即，通知所有事务参与者正式提交事务，所有参与者提交完毕会再次通知协调者。为了实现分布式事务，必须使用一种协议在分布式事务的各个参与者之间传递事务上下文信息，例如：IIOP（Internet Inter-ORB Protocol互联网内部对象请求代理协议）协议，不同开发商开发的事务参与者也必须支持同一种标准协议，才能实现分布式的事务。
具体到实现，现有技术通常采用CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）制定的一种标准的面向对象的应用程序体系规范，解决分布式处理环境中软件系统的互联。CORBA标准主要分为三个部分：接口定义语言（IDL）、对象请求代理（ORB）以及ORB之间的互操作协议IIOP。采用CORBA体系结构，在异构分布环境下为不同机器上的应用提供了互操作性，并无缝地集成了多种对象系统，通过将分布式对象技术与事务处理技术结合起来，利用两阶段提交协议和恢复日志等技术，从而保证分布式事务的ACID性质。
上述现有技术采用的分布式事务框架，需要搭建较为复杂的分布式处理中心，而且要求分布式处理中心和目标服务器或目标数据库系统必须配置用于实现分布式操作的各类复杂协议，一方面比较臃肿，不利于维护和使用，另一方面也无法为不同的业务提供轻量级的可定制化的服务。
发明内容
本申请提供一种跨数据库分布式事务的实现方法，以解决现有分布式事务的实现框架过于复杂、不便于维护的问题。本申请另外提供一种跨数据库分布式事务的实现装置。
本申请提供一种跨数据库分布式事务的实现方法，包括：
接收分布式事务的启动请求，并为所述分布式事务分配事务标识；
接收被分配事务标识的分布式事务的针对数据库操作的操作请求或操作请求集合；
针对每个操作请求，获取所述数据库操作的目标数据库信息，并遵循ACID原则将所述数据库操作发送到所述目标数据库执行；
待所有的数据库操作执行完毕，清除所述分布式事务。
可选的，所述获取所述数据库操作的目标数据库信息具体是指，根据所述数据库操作指定的目标数据库和/或表的名称，查找预先设置的数据库描述信息，从中获取与所述目标数据库和/或表的名称对应的目标数据库信息。
可选的，所述遵循ACID原则将所述数据库操作发送到所述目标数据库执行，包括：
获取所述数据库操作的类型；
解析所述数据库操作，获取所述数据库操作影响的行标识；
获取所述行标识对应的行的当前访问状态；
根据所述行标识对应的行的当前访问状态和所述数据库操作的类型，判断是否需要等待所述行标识对应的行的访问结束；若是，则执行等待，等到所述行标识对应的行的访问结束，再执行下述步骤；若否，继续执行下述步骤；
根据所述数据库操作的类型，判断是否需要获取对所述行标识对应的行的访问控制，若是，则为所述行标识对应的行添加访问控制后执行下述步骤；若否，执行下述步骤；
将所述数据库操作发送给所述目标数据库执行；
向所述分布式事务的请求方返回所述数据库操作的执行结果。
可选的，执行所述将所述数据库操作发送给所述目标数据库执行的步骤后，如果没有在预先设定的时间内收到目标数据库返回的执行结果，则通过主动访问目标数据库的方式获取所述数据库操作的执行结果。
可选的，所述数据库操作的类型包括：新增操作、更新操作、删除操作或查询操作。
可选的，所述解析所述数据库操作，获取所述数据库操作影响的行标识，包括：
如果所述数据库操作的类型为新增操作，则为所述新增操作分配一个唯一标识该行的行标识，并将所述行标识添加到新增操作中；
否则，执行下述步骤：
将所述数据库操作解析为采用相同条件的获取行标识的查询操作；
将所述查询操作发送给所述目标数据库执行；
接收所述目标数据库返回的行标识，将返回的行标识作为所述数据库操作 影响的行标识。
可选的，所述根据所述行标识对应的行的当前访问状态和所述数据库操作的类型，判断是否需要等待所述行标识对应的行的访问结束，具体是指：
如果所述数据库操作的类型是新增操作或者查询操作，则判定为不需要等待所述行标识对应的行的访问结束；
如果所述数据库操作的类型是更新操作或者删除操作，则进一步判断所述行标识对应的行当前是否没有被当前分布式事务之外的事务所访问，或者虽被当前分布式事务之外的事务访问但没有被锁定，若是，则判定为不需要等待所述行标识对应的行的访问结束；否则，判定为需要等待所述行标识对应的行的访问结束。
可选的，所述根据所述数据库操作的类型，判断是否需要获取对所述行标识对应的行的访问控制，具体是指：
如果所述数据库操作的类型为新增操作、更新操作或者删除操作，则判定为需要获取对所述行标识对应的行的访问控制。
相应的，所述为所述行标识对应的行添加访问控制，具体是指，为所述行标识对应的行添加允许执行查询操作但不允许执行新增操作、更新操作和删除操作的过程锁。
可选的，在所述将所述数据库操作发送给所述目标数据库执行的步骤之前，执行下述操作：如果所述数据库操作的类型为查询操作，并且所述行标识中存在被当前分布式事务之外的事务锁定的行，则采用下述步骤重新构造查询操作：
获取所述被锁定的行当前执行的数据库操作的类型；
如果所述被锁定的行当前执行的数据库操作的类型为新增操作，将所述被锁定的行标记为不满足查询条件；
如果所述被锁定的行当前执行的数据库操作的类型为更新操作或者删除操作，则进一步判断所述被锁定的行在执行当前的更新操作或者删除操作之前是否满足所述查询操作的条件，若是，则记录满足所述查询操作的条件的行；否则，将所述被锁定的行标记为不满足查询条件；
生成剔除了所述不满足查询条件的行标识的查询操作；
相应的，所述将所述数据库操作发送给所述目标数据库执行是指，将重新构造的查询操作发送给所述目标数据库执行。
相应的，所述向所述分布式事务的请求方返回所述数据库操作的执行结果是指，将所述查询操作的执行结果，与已记录的满足所述查询操作的条件的行合并，并将合并后的结果返回给所述分布式事务的请求方。
可选的，所述方法还包括：
将所述分布式事务的相关信息和所述分布式事务包括的数据库操作的相关信息写入与所述分布式事务标识对应的内存数据中。
可选的，所述分布式事务的相关信息包括：所述分布式事务的事务标识、执行状态、和超时设置；
所述分布式事务包括的数据库操作的相关信息包括：目标数据库信息、影响的行标识、更新操作或删除操作执行前的行的内容、锁状态、执行状态、主动验证时间差、数据库操作语句和数据库操作的类型。
可选的，所述清除所述分布式事务包括：
对所述分布式事务锁定的行执行解除锁定操作；
删除所述分布式事务标识及与所述分布式事务相关的内存数据。
可选的，所述方法还包括：
获取数据库操作的执行结果，若所述分布式事务中的任一数据库操作未能执行成功，则对所述分布式事务中的已经成功执行的其他数据库操作执行回退操作，恢复到所述分布式事务执行前的状态。
可选的，所述方法还包括：
判断所述分布式事务的持续时间，如果所述持续时间大于预先设定的时间，则触发异常处理程序进行处理。
可选的，所述方法还包括：
将所述分布式事务的执行过程以及所述分布式事务对目标数据库所做的修改写入日志文件中。
可选的，所述方法还包括：
读取所述日志文件，并根据所述日志文件中记录的分布式事务的信息，对尚未完成的分布式事务中的已经成功执行的数据库操作执行回退操作。
相应的，本申请还提供一种跨数据库分布式事务的实现装置，包括：
事务启动单元，用于接收分布式事务的启动请求，并为所述分布式事务分 配事务标识；
操作接收单元，用于接收被分配事务标识的分布式事务的针对数据库操作的操作请求或操作请求集合；
操作执行单元，用于针对每个操作请求，获取所述数据库操作的目标数据库信息，并遵循ACID原则将所述数据库操作发送到所述目标数据库执行；
事务清除单元，用于待所述分布式事务执行完毕后，清除所述分布式事务。
可选的，所述操作执行单元采用如下方式获取所述数据库操作的目标数据库信息：根据所述数据库操作指定的目标数据库和/或表的名称，查找预先设置的数据库描述信息，从中获取与所述目标数据库和/或表的名称对应的目标数据库信息。
可选的，所述操作执行单元包括：
目标数据库查询子单元，用于根据所述数据库操作指定的目标数据库和/或表的名称，查找预先设置的数据库描述信息，从中获取与所述目标数据库和/或表的名称对应的目标数据库信息；
操作类型获取子单元，用于获取所述数据库操作的类型；
行标识获取子单元，用于解析所述数据库操作，获取所述数据库操作影响的行标识；
访问状态获取子单元，用于获取所述行标识对应的行的当前访问状态；
等待子单元，用于根据所述行标识对应的行的当前访问状态和所述数据库操作的类型，判断是否需要等待所述行标识对应的行的访问结束；若是，则执行等待，等到所述行标识对应的行的访问结束，再执行下述步骤；若否，继续执行下述步骤；
访问控制子单元，用于根据所述数据库操作的类型，判断是否需要获取对所述行标识对应的行的访问控制，若是，则为所述行标识对应的行添加访问控制；
操作执行子单元，用于将所述数据库操作发送给所述目标数据库执行；
结果返回子单元，用于向所述分布式事务的请求方返回所述数据库操作的执行结果。
可选的，所述操作执行单元还包括：
操作超时处理子单元，用于当没有在预先设定的时间内收到目标数据库返回的执行结果时，通过主动访问目标数据库的方式获取所述数据库操作的执行结果。
可选的，所述操作类型获取子单元获取的操作类型包括：新增操作、更新操作、删除操作或读取操作。
可选的，所述行标识获取子单元包括：
行标识分配子单元，用于当所述数据库操作的类型为新增操作时，为所述新增操作分配一个唯一标识该行的行标识，并将所述行标识添加到新增操作中；
行标识查询子单元，用于将所述数据库操作解析为采用相同条件的获取行标识的查询操作，并将所述查询操作发送给所述目标数据库执行，将所述目标数据库返回的行标识作为所述数据库操作影响的行标识。
可选的，所述等待子单元具体用于，当所述数据库操作的类型是新增操作或者查询操作时，不执行等待；当所述数据库操作的类型是更新操作或者删除操作时，如果所述行标识对应的行当前没有被当前分布式事务之外的事务访问，或者虽被当前分布式事务之外的事务访问但没有被锁定，则不执行等待，否则执行等待。
可选的，所述访问控制子单元具体用于，当所述数据库操作的类型为新增操作、更新操作或者删除操作时，为所述行标识对应的行添加允许执行查询操作但不允许执行新增操作、更新操作和删除操作的过程锁。
可选的，所述操作执行单元还包括：
查询操作重构子单元，用于当所述数据库操作的类型为查询操作、并且所述行标识中存在被当前分布式事务之外的事务锁定的行时，重新构造查询操作。
所述查询操作重构子单元包括：
锁定行操作类型获取子单元，用于获取所述被锁定的行当前执行的数据库操作的类型；
查询条件验证子单元，用于当所述被锁定的行当前执行的数据库操作的类型为新增操作时，将所述被锁定的行标记为不满足查询条件；当所述被锁定的行当前执行的数据库操作的类型为更新操作或者删除操作、并且所述被锁定的行在执行当前的更新操作或者删除操作之前满足所述查询操作的条件时，记录满足所述查询操作的条件的行，否则，将所述被锁定的行标记为不满足查询条 件；
查询操作生成子单元，用于生成剔除了所述不满足查询条件的行标识的查询操作；
相应的，所述操作执行子单元具体用于将重新构造的查询操作发送给所述目标数据库执行。
相应的，所述结果返回子单元具体用于，将所述查询操作的执行结果，与已记录的满足所述查询操作的条件的行合并，并将合并后的结果返回给所述分布式事务的请求方。
可选的，所述装置还包括：
数据写入单元，用于将所述分布式事务的相关信息和所述分布式事务包括的数据库操作的相关信息写入与所述分布式事务标识对应的内存数据中。
可选的，所述事务清除单元包括：
解除锁定子单元，用于对所述分布式事务锁定的行执行解除锁定操作；
数据清除子单元，用于删除所述分布式事务标识及与所述分布式事务相关的内存数据。
可选的，所述装置还包括：
回滚单元，用于获取数据库操作的执行结果，当所述分布式事务中的某个数据库操作未能执行成功时，对所述分布式事务中的已经成功执行的其他数据库操作执行回滚操作，恢复到所述分布式事务执行前的状态。
可选的，所述装置还包括：
异常处理单元，用于判断所述分布式事务的持续时间，如果所述分布式事务未能在预先设定的时间内完成，则触发异常处理程序执行回滚操作。
可选的，所述装置还包括：
日志管理单元，用于将所述分布式事务的执行过程以及所述分布式事务对目标数据库所做的修改写入日志文件中。
可选的，所述装置还包括：
事务恢复单元，用于读取所述日志文件，并根据所述日志文件中记录的分布式事务的信息，对尚未完成的分布式事务执行回滚操作。
与现有技术相比，本申请具有以下优点:
采用本申请提供的跨数据库分布式事务的实现方法，通过在目标数据库系统中使用唯一的行标识，并采用访问控制机制对分布式事务的访问操作进行统一管理，避免了对目标数据库的非同步操作导致数据不一致的问题，实现了轻量级的、易于维护、并且满足ACID原则的跨数据库分布式事务。
本申请提供的一种优选实施方式，通过对分布式事务中的写操作（包括新增操作、更新操作和删除操作）加过程锁，即：允许其他分布式事务读取所述写操作影响的行但是不能对所述行执行写操作，同时还采用了重构查询语句、合并查询结果的方式，避免读取其他事务尚未提交的过程数据，从而在实现跨数据库分布式事务的“读提交”隔离级别的同时，也取得较好的并发性效果。
附图说明
图1为本申请的跨数据库分布式事务的实现方法的实施例的流程图；
图2为本申请的跨数据库分布式事务的实现装置的实施例的示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。
在本申请中，提供了一种跨数据库分布式事务的实现方法，同时还提供了一种跨数据库分布式事务的实现装置，在下面的实施例中逐一进行详细说明。
请参考图1，其为本申请的一种跨数据库分布式事务的实现方法的实施例的流程示意图。所述方法包括如下步骤：
步骤101：接收分布式事务的启动请求，并为所述分布式事务分配事务标识。
本申请提供的跨数据库分布式事务的实现方法，通过对多个目标数据库的并发访问采取集中控制，实现了基于分布式调用的事务机制，满足了事务的ACID原则。为了更好地理解本申请的技术方案，先对事务和分布式事务的概念作简要的描述。
所谓事务是由一系列数据库操作组成的一个完整的逻辑过程，是一个不可分割的操作单位。在关系数据库中，一个事务可以是一条SQL语句、也可以是一组SQL语句、甚至是整个程序。通过事务，将逻辑相关的一组操作绑定在一起，以便保持数据的完整性和一致性。例如银行转帐，从原账户扣除金额，以 及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，不可拆分，这个过程被称为一个事务。
事务必须符合四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability），简称事务的ACID特性。
所谓原子性，是指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行，一个事务不可能只执行了一半就停止。之所以要求事务满足原子性，是因为与某个事务关联的操作通常具有共同的目标，并且是相互依赖的，如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标，导致出现数据不一致的情况。原子性消除了系统处理操作子集的可能性。但是实际上原子操作的要求很难得到保证，由于硬件的损坏或其他因素导致一个事务中的操作被中断是经常碰到的问题，因此在常规的数据库系统中，通常采用事务回滚机制和日志技术实现事务的原子性。一方面，如果事务中任何一个SQL语句执行失败，那么该事务中已经执行成功的SQL语句也必须撤销，使数据库状态回退到执行事务前的状态，这个过程就称为事务回滚机制；另一方面，采用日志记录事务对数据库所做的更新，如果系统发生灾难性事件时，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态，从而保证事务的原子性。
一致性是指，在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏，事务在完成时，必须使所有的数据仍然保持一致状态，例如，完整性约束要求a+b=10，如果一个事务改变了a，那么b也应该随之改变。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些尚未完成的事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。可见事务的一致性与事务的原子性是密切相关的，在不存在多事务并发的情况下，可以这样认为，如果事务中的每个数据库操作对数据的处理是正确的，并且事务的执行满足了原子性的要求，我们就可以认为数据的一致性没有被破坏，事务满足了一致性的要求。
然而在多个事务并发执行的场景下，即使每个事务都能保持原子性和一致性，由于这些事务可能访问相同的数据，并且它们的操作可能会以不可预期的某种方式交叉执行，导致数据出现不一致的状态。因此对事务又提出了满足隔离性的要求。
隔离性，指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的相对独立、相对完整的数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改在一定程度上隔离，即：并发执行的各个事务之间不能互相干扰，每个事务都感觉不到系统中有其他的事务在执行，因而也就能保证数据库的一致性。数据库管理系统通常采用锁机制来实现事务的隔离性。事务的隔离级别通常分为四类：读未提交（read uncommitted）、读提交（read committed）、可重复读（read repeatable）、可序列化（serializable）。
持久性是指，事务完成之后，它对于系统的影响是永久性的。即：一旦一个事务成功结束，它对数据库所做的更新就必须永久保存下来，即使系统或介质发生故障、甚至发生系统崩溃等灾难性事件，系统重新启动后，数据库还能恢复到事务成功结束时的状态。持久性可以通过数据库系统提供的冗余备份功能和恢复机制来保证。
所谓分布式事务则是在上述事务的基础上出现的一个新概念，具体是指，事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，也即：分布式事务是影响多个资源的事务。本申请所述的跨数据库分布式事务，是指分布式事务的执行要跨越多个不同的目标数据库资源，自然会存在不同的事务并发访问相同的目标数据库资源的情况，为了保障整个目标数据库资源中的数据一致性，强制跨数据库分布式事务满足事务的ACID属性是很有必要的。也可以这样理解，评价事务是否支持分布式的调用，主要看其分布式调用过程中事务的ACID原则是否满足，这也是本申请技术方案的核心所在。
为了便于描述，在本实施例中，将实施了本申请提供的跨数据库分布式事务的实现方法的模块、应用或者系统，简称为统调层。
采用本申请提供的跨数据库分布式事务的实现方法，当业务系统有分布式事务的处理需求时，不需要直接向各个目标数据库发送其分布式事务中包含的各个数据库操作，而是首先向统调层发送分布式事务的启动请求，统调层接收到该分布式事务的启动请求后，为该事务创建一个新的事务标识，并将该事务标识返回给提出启动请求的业务系统，从而完成分配事务标识的操作。此外，统调层还要将新创建的事务标识写入统调层维护的数据中（关于统调层数据的说明参见步骤102中的相关部分），并在该分布式事务的后续执行过程中，使用所述事务标识与其他分布式事务相区分。具体在实施中，统调层可以采用多线 程机制实现多个并发事务的管理，即：统调层为每个分布式事务创建一个新的线程，由该线程负责与其对应的分布式事务后续的相关处理与操作。
业务系统向统调层发送分布式事务的启动申请，以及后续与统调层之间的交互，可以通过函数调用、消息机制、以及建立连接等多种方式来实现。为了保证业务系统能够与统调层建立交互通道，可以将必要的函数接口、统调层地址信息、以及建立连接所需的用户名、密码等信息固化在业务系统的代码内部，也可以采用更为灵活的方式，将上述信息写入配置文件中，每次业务系统通过读取配置文件中的信息，与统调层建立交互通道。这些交互机制不是本申请的核心，本申请不作具体的限定。
步骤102：接收被分配事务标识的分布式事务的针对数据库操作的操作请求或操作请求集合。
完成步骤101后，业务系统获取了需要执行的分布式事务的标识，就可以向统调层发送所述分布式事务针对数据库操作的操作请求了。一个分布式事务中可以仅包括一个数据库操作，也可以包括一组相互关联的数据库操作。业务系统可以将所述分布式事务包含的数据库操作一次性地发送给统调层，统调层逐一处理接收的数据库操作，并将操作结果上报业务系统；业务系统也可以每次仅发送一个数据库操作，接收到统调层返回的执行结果后再下发下一个数据库操作。这两种实施方式都可以实现本申请的技术方案。
要实现本申请提供的跨数据库分布式事务，统调层需要获悉每个分布式事务包含哪些数据库操作，以及这些数据库操作对数据库资源的影响，这样在发生错误或异常时才能实现事务的回滚功能，保证事务的原子性；另外，为了实现各个并发事务对目标数据库资源的访问控制，统调层还需要知道每个分布式事务当前执行的数据库操作涉及对哪些数据库资源的访问，以及这些数据库资源是否正在被其他分布式事务访问等信息，并根据这些信息进行相应的访问控制，才能够避免不同事务之间的操作冲突，保证数据的一致性和正确性。此外，统调层还要对多个并发的分布式事务进行区分和统一管理，因此统调层需要在其内存中维护关于分布式事务以及分布式事务包含的数据库操作的详细信息，这也是实现本申请技术方案不可或缺的部分。
统调层维护的数据分为三类，一类全局数据，一类是事务相关的数据，还有一类是与数据库操作相关的数据。全局数据包括：目标数据库描述、事务列 表、事务清理时间等；事务相关数据用于记录每个事务的信息，包括：事务标识、每个事务包括的数据库操作集合、事务的超时设置、事务的执行状态等；数据库操作相关的数据用于记录每个数据库操作的详细信息，包括：目标数据库信息、影响的行标识、写操作（包括更新操作和删除操作）执行前的数据库数据内容、访问控制、数据库操作语句、数据库操作的类型等。
本实施例的一个具体例子中，目标数据库系统是支持SQL操作的关系型数据库，业务系统发送给统调层的数据库操作就是具体的SQL语句，访问控制是通过锁机制实现的（这部分说明请参见步骤103中的相关部分），统调层维护的数据如下表所示：
表一：全局数据

表二：事务相关数据

表三：数据库操作相关数据


统调层对上述数据的维护方法和使用方法，在后面的描述中会有进一步的说明。上表中的数据仅仅是本实施例的一个具体例子中的数据，在其他实施方式中，统调层可以维护不同于上表的数据，也可以新增其他的数据，只要能够满足统调层对分布式事务的管理需求就可以了，具体维护哪些数据以及数据的类型，这些对实施方式的变更，都不偏离本申请的核心，都在本申请的保护范围之内。
在本步骤中，统调层接收所述分布式事务的数据库操作请求或操作请求集合后，将所述数据库操作的相关信息写入统调层与所述分布式事务对应的数据中。在本实施例的一个具体例子中，统调层将接收的SQL语句添加到SQL集合的一个数组元素中。
步骤103：针对每个操作请求，获取所述数据库操作的目标数据库信息，并遵循ACID原则将所述数据库操作发送到所述目标数据库执行。
本申请提供的跨数据库分布式事务的实现方法，其目标就是实现满足ACID原则的分布式事务。其中，事务的原子性通过统调层的回滚机制和日志机制实现，持久性通过目标数据库系统的冗余备份等功能实现，而本步骤中的操作主要是通过对并发事务的访问控制，以及实现多个并发事务执行过程中的隔离性，从而保证数据的一致性。本步骤是本申请技术方案的核心。为了便于理解，下面首先对并发事务存在的主要问题，以及隔离级别作简要的说明。
并发事务可能会同时操纵同一个目标数据库中的相同数据，因此会发生数据不一致的问题，这些问题包括：丢失更新、脏读、不可重复读和幻觉读。
a)丢失更新：当两个或多个事务选择数据库中的同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其他事务的存在。最后的更新将重写由其他事务所做的更新，这将导致数据丢失。
b)脏读：就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使 用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是过程数据（也称为：脏数据），依据该过程数据所做的操作可能是不正确的。
c)不可重复读：在同一事务中，需要两次读取同一数据，而在两次读取之间，可能有其他事务对数据进行了更改，导致第一个事务两次读取得到的内容不同。
d)幻读：同一事务中，用同样的操作读取两次，而在两次读取之间，可能有其他事务执行了插入操作，导致第一个事务两次查询得到的记录数不相同。
为了解决并发事务存在的上述问题，一方面，要求并发事务必须对数据的写操作（即：更新操作、新增操作或删除操作）进行访问控制，即：任何时候只允许一个事务对相同的数据执行写操作，在该事务提交之前，防止其他事务修改相同的数据资源，这一点是对并发事务访问控制的基本要求，这样才可能避免出现丢失更新的现象。另一方面，通过采用不同的访问控制策略以及增加对读操作的访问控制，可以在不同程度上解决上述其他三个方面的问题，也就是说实现并发事务之间的不同的隔离级别。
所谓隔离级别是指，一个事务必须与其他事务进行的数据更改相隔离的程度。通常并发事务之间的隔离级别有以下四种：
a)读未提交（read uncommitted）：这是最低的隔离级别，在这种隔离级别下，所有事务都可以看到并读取其他事务尚未提交的数据。在该隔离级别，可能会出现脏读、不可重复读以及幻读等，因此本隔离级别很少用于实际应用。
b)读提交（read committed）：这是大多数数据库系统的默认隔离级别。它实现了这样一种隔离性：一个事务只能看见已经提交事务所做的改变，即：事务查看到的数据要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。但是在一个事务执行读操作的时候，其他事务可能会对该事务读操作涉及的资源进行更新并提交，因此这种隔离级别可能会出现不可重复读和幻读的问题，也就是说同一查询操作可能返回不同结果。
c)可重复读（read repeatable）：该级别确保同一事务中的多个操作在读取数据时，会看到同样的数据行。该级别解决了不可重复读的问题，但是由于其他事务可以在本事务读取数据的过程中执行新增操作，导致本事务可能出现幻读 的问题。
d)可序列化（serializable，也称为可串行性）：这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。当事务可序列化时，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。
较低的隔离级别可以增强事务并发访问数据的能力，但也增加了每个事务可能遇到的并发副作用（例如脏读）可能性，也就是说可能降低数据的完整性和正确性。相反，较高的隔离级别由于减少了事务可能遇到的并发副作用的类型，因此可以更好地保证数据的完整性和正确性，但是需要进行相对复杂的访问控制，同时也增加了一个事务阻塞其他事务的可能性（其他事务必须等待该事务结束），影响事务的并发性能。
尽管可串行性对于事务确保数据库中的数据在所有时间内的正确性相当重要，然而许多事务并不总是要求完全的隔离。应综合考虑业务系统对数据完整性的要求与每个隔离级别的开销，在此基础上选择相应的隔离级别。降低隔离级别以换取更大的吞吐量，是很多业务系统的常规思路。由于在实际的应用过程中往往将隔离性设置为读提交，因此在本实施例中，提供了一种实现读提交隔离级别的分布式事务的优选实施方案（请参见本步骤后续的描述）。
需要说明的是，选择事务隔离级别并不影响为写操作而执行的访问控制（这里所述的访问控制在具体实施过程中，通常是采用锁机制实现的），每个事务总是在其修改的任何数据上获取锁并在事务完成之前持有该锁，不管为该事务设置了什么样的隔离级别。可以这样理解，隔离级别主要是为读取操作定义不同的保护级别，以防止一个事务的读取操作受到其他事务所做更改的影响。
事务的隔离级别可以由业务系统指定，例如：业务系统可以在每次发送事务启动请求时，携带指定隔离级别的参数，统调层接收后按照业务系统的要求进行相应的处理；也可以由统调层采用固定的隔离级别（例如：读提交级别）进行处理。隔离级别的选取和调整，都属于实施方式的具体变更，都不影响本申请的核心，都在本申请的保护范围内。
具体到本实施例，在接收分布式事务的数据库操作请求后，执行下述9个子步骤，实现本申请所提供的跨数据库分布式事务。
1）获取所述数据库操作的目标数据库信息。
根据所述数据库操作的schema信息，查找统调层全局数据中的数据库描述集合，获取执行所述数据库操作的数据库schema的访问地址。一般来说，schema是指数据库表的组织和定义，也可以将其理解为一个容器或者数据库对象命名空间中的一个层次，主要用来解决命名冲突问题。从概念上说，一个数据库系统可以包含多个schema，而每个schema又包含多个数据库对象（表、视图、字段等）。所述分布式事务的请求方不需要知道目标数据库的具体访问地址，而是由统调层负责根据所述数据库操作的schema信息获取对应的目标数据库地址。
2）获取所述数据库操作的类型。
读取接收到的数据库操作语句，从中获取所述数据库操作的类型。所述数据库操作的类型包括：更新操作、删除操作、新增操作、查询操作，其中更新操作、删除操作和新增操作属于写操作，查询操作是通常所说的读操作。
3）解析所述数据库操作，获取所述数据库操作影响的行标识。
行标识是用来唯一标识数据行的，为了实现本申请提供的方法，要求在整个目标数据库系统中保证行标识的唯一性，这一点也是实施本申请所提供的方法的关键所在，通过使用该行标识，统调层能够准确无误地确定目标数据库中的唯一一行，相应的，在进行目标数据库的表设计时也需要新增一个特殊的行标识列，例如rowEid。为了实现行标识的唯一性，该行标识统一由统调层管理。
如果所述数据库操作的类型为新增操作，说明要向目标数据库中插入一新行，统调层为其创建一个新的行标识，并且将该行标识信息添加到新增操作中，例如：所述新增操作是如下所示的Insert语句：
INSERT INTO TABLE_NAME(column1，column2)VALUES(values1,values2)；
统调层为该新增行创建一个行标识200，并将该行标识信息添加到该Insert语句中，得到如下的新增操作的SQL语句：
INSERT INTO TABLE_NAME(column1，column2，rowEid)
VALUES(values1,values2,‘200’)；
如果所述数据库操作的类型为更新操作、删除操作或者查询操作，则需要执行下述步骤获取所述数据库操作影响的行标识。
a)将所述数据库操作解析为采用相同条件的获取行标识的查询操作。
数据库操作语句通常是不携带影响的行标识信息的，因此只有将所述数据库操作语句转换为相同条件的查询语句，并去目标数据库中执行，才能够返回 其影响的行标识。在本实施例的一个具体例子中，采用如下所示的方式进行转换：
对于select*from table where queryCondition；解析为select rowEid from table where queryCondition；
对于update table set xxxx where queryCondition；解析为select rowEid from table where queryCondition；
对于delete from table where queryCondition；解析为select rowEid from table where queryCondition。
b)将所述查询操作发送给所述目标数据库执行。
将转换后的查询操作发送给目标数据库执行。由于在前面的子步骤1）中已经获取了所述数据库操作的目标数据库地址，因此直接根据目标数据库地址建立连接，并发送所述转换后的查询操作即可。至于如何建立连接，可以通过ODBC接口实现，也可以采用其他方式实现，具体的方式不是本申请的核心，本申请不作限定。
c)接收所述目标数据返回的行标识，将返回的行标识作为所述数据库操作影响的行标识。
接收目标数据库的应答，目标数据库返回的行标识就是所述数据库操作影响的行标识。在该步骤中，也可能出现目标服务器无应答的异常情况，可以按照子步骤8）中的超时处理方式进行处理，此处不再赘述。
综上所述，如果所述数据库操作是新增操作，通过统一分配的方式获取了新的行标识，如果所述数据库操作是更新、删除、查询操作，则通过对目标数据库执行一次查询操作获取了这些操作影响的行标识。统调层获取上述行标识后，可以将上述行标识信息写入统调层的事务影响的行标识集合和数据库操作影响的行标识集合中。
4）获取所述行标识对应的行的当前访问状态。
之所以在上述步骤中要获取所述数据库操作影响的行标识，就是为了进一步获取所述行标识对应的行的当前访问状态。所述行标识对应的行的访问状态，是指当前是否存在其他事务获取了所述行标识对应的行的访问控制，以及访问控制的类型等。
在实施过程中，事务对于数据库中行的访问控制通常采用锁机制来实现。 锁是数据库中的一个非常重要的概念，它主要用于多用户环境下保证数据库完整性和一致性。所谓锁机制，就是将数据资源（例如：数据库中的某一行或者某几行）与单个事务关联起来，并控制其他事务如何与该资源进行交互的机制，通常我们称与被锁定资源关联的事务持有或拥有该锁。一旦获得了锁，事务终止前就一直持有该锁，该事务终止时释放锁，其他事务就可以使用被解锁的数据资源了，否则其他事务必须处于等待状态。
锁是实现并发控制的主要方法，特别是实现写控制的主要方法，是多个事务能够同时操纵同一个数据库中的数据而不发生数据不一致现象的重要保障。当多个事务同时对数据库中相同的数据执行写操作（包括：更新、删除、新建）时，只允许持有锁的事务能执行所述写操作，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会继续执行。锁也是实现事务的隔离性的主要方法。大多数数据库，例如SQL Server以及其他的关系型数据都是通过使用锁定来实现隔离机制。
所谓访问控制的类型，是指锁的类型。在本申请所提供的跨数据库分布式事务的实现方法中，主要涉及两种锁：过程锁和排它锁。所谓过程锁是指，如果某事务对其数据库操作加上了过程锁，则不允许其他事务修改该数据库操作影响的行，但是允许其他事务读取该数据库操作影响的行，也就是说，过程锁是保证在同一时刻只会有一个写操作影响数据库中的某一行或某几行。所谓排他锁（又称独占锁）是指，不仅不允许其他事务修改该数据库操作影响的行，同时也不允许其他事务读取该数据库操作影响的行，也就是说，在当前事务释放所述数据库操作的锁之前，其他事务对所述数据库操作影响的行，既不能修改也不能读取。在具体的实施中，对数据库操作加锁的过程，就是对所述数据库操作影响的行添加锁标识的过程，参见子步骤6）中的相关说明。
在本实施例的一个具体例子中，获取所述行标识对应的行的当前访问状态，是通过查找统调层维护的数据来实现的，具体采用如下步骤：a)先查找统调层维护的事务相关的数据，查看所述行标识是否在某个事务影响的行标识集合中，并记录下对应的事务标识TransId；b）然后查找所述事务标识对应的数据库操作相关的数据，获取所述行标识对应的行的当前访问状态信息，包括：正在访问所述行标识对应的行的数据库操作的类型、所述行是否加锁，以及锁的类型等。
5）根据所述行标识对应的行的当前访问状态和所述数据库操作的类型，判断是否需要等待所述行标识对应的行的访问结束；若是，则执行等待，等到所 述行标识对应的行的访问结束，再执行下述步骤；若否，继续执行下述步骤。
本子步骤主要是判断所述数据库操作是否与其他并发事务的操作存在读写冲突，如果存在，则执行等待，等其他并发事务结束后再执行所述数据库操作，从而保证数据的一致性和完整性。
在本申请提供的一种优选实施方式中，采用过程锁实现并发控制，也就是说如果某事务对其数据库操作加上了过程锁，则不允许其他事务修改该数据库操作影响的行，但是允许其他事务读取该数据库操作影响的行。因此，如果所述数据库操作的类型是新增操作或者查询操作，则不需要等待所述行标识对应的行的访问结束（因为，新增或查询操作都不会修改其他事务影响的行），即：不需要等待其他事务释放在所述行标识对应的行上添加的过程锁；如果所述数据库操作的类型是更新操作或者删除操作，则进一步判断是否满足下述条件：
a)所述行标识对应的行当前没有被其他分布式事务访问，也就是说子步骤4）中查看所述行标识是否在某个事务影响的行标识集合时，没有找到影响所述行标识的Trans_Id，或者虽然查到，但是该Trans_Id标识的事务不是其他事务，而是当前正准备执行所述数据库操作的事务本身；
b)所述行标识对应的行当前被其他分布式事务访问但没有添加过程锁，也就是说子步骤4）中查看所述行标识是否在某个事务影响的行标识集合时，找到了不同于当前事务标识的其他事务标识Trans_Id，也就是说存在其他事务正在访问所述行标识对应的行，但是并没有添加过程锁。
如果满足上述a)或b)中的任意一个条件，则不需要等待所述行标识对应的行的访问结束，即：不需要等待其他事务释放在所述行标识对应的行上添加的过程锁；否则，需要等待其他事务释放在所述标识对应的行上添加的过程锁。
所述等待过程，可以采用系统提供的阻塞机制实现，即：将所有请求同一个资源（例如：要求访问同一个目标数据库中的同一行）的数据库操作进行排序，放到一个队列中，在该资源释放后，会通知在请求队列中等待的请求开始执行。不同的锁机制有不同的算法，不同系统提供的阻塞机制的内部实现也会有所不同，但这些细节不在本申请技术方案的考虑之内，主要采用一种能够提供上述阻塞机制的实施方式即可，本申请不作具体的限定。
在本申请提供的上述优选实施方式中，如果所述数据库操作是查询操作，则不需要等待其他事务释放在所述行标识对应的行上添加的过程锁，这样可以 增加事务的并发程度，但是可能出现脏读，即：当前的查询操作可能会读取其他事务尚未提交的过程数据（或者中间数据），因此本申请提供的优选实施方式，针对查询操作，采用了重构查询操作、合并查询结果的处理方式，从而实现了“读提交”的隔离级别，避免了出现脏读的现象，关于这部分说明，请参见子步骤7中的说明。
在上述本申请提供的优选实施方式中，采用过程锁对并发写操作进行控制。在其他实施方式中，也可以采用其他访问控制方式。例如，如果要实现可串行化的隔离级别，则需要使用排他锁，也就是说，在某个事务释放所述数据库操作的锁之前，其他事务对所述数据库操作影响的行，既不能修改也不能读取。因此在这种隔离级别的要求下，不管所述数据库操作是写操作还是读操作，都要进行更为严格的判断，如果所述数据库操作影响的行标识当前被其他事务采用排他锁锁定，那么所述数据库操作必须执行等待，这样才可能实现可串行化的隔离级别。
为了实现可串行化的隔离级别，除了要使用排他锁，还需要考虑可能存在幻读的问题，即：同一事务中，用同样的操作读取两次，而在两次读取之间，可能有其他事务执行了插入操作，导致第一个事务两次查询得到的记录数不相同，也就是说，其他事务可能将新的幻像行插入某个数据集合或表中，且幻像行包括在当前事务的后续读取中。为了避免出现幻读的情况，不能简单地使用过程锁或者排他锁这样的行级锁，而需要使用类似范围锁的锁机制，即将第一个事务中的读取操作可能影响的数据集合或者表整体加锁，以防止其他事务在本事务完成之前将新行插入数据集或表中。相应的，在本步骤的判断中，如果所述数据库操作是新增操作，就需要判断该新增操作影响的行是否处在所述范围锁锁定的范围之内，若是，则必须执行等待。可串行性是四个隔离级别中限制最大的级别，并发级别较低，通常只在特殊的应用需求下才采用该隔离级别。
在本申请提供的优选实施方式中，采用基于过程锁的并发控制机制，在其他实施方式中，也可以采用其他的锁机制，例如上面描述的排他锁或者范围锁，这是都属于具体实施方式的变更，只要能够满足业务系统的需求，实现分布式事务之间的并发控制即可，具体采用哪种锁机制，本申请不作明确的限定。
6）根据所述数据库操作的类型，判断是否需要获取对所述行标识对应的行的访问控制，若是，则为所述行标识对应的行添加访问控制。
如果经过上面的判断过程，所述数据库操作不需要执行等待，即：所述数据操作影响的行标识没有被其他事务锁定；或者所述数据库操作处于阻塞等待状态，并且等到其他事务执行完毕释放了所述行标识对应的行的锁定，这两种情况下，都会转到本子步骤执行，为所述行标识对应的行添加访问控制。
前面已经提到过，为了解决并发事务存在的更新丢失等问题，要求并发事务必须对数据的写操作（即：更新操作、新增操作或删除操作）进行访问控制，即：任何时候只允许一个事务对相同的数据执行写操作，这一点是对并发事务访问控制的基本要求，这样才可能保证数据的一致性和完整性。在具体的实施过程中，为所述行标识对应的行添加访问控制，通常是通过锁机制来实现的，即：为所述行标识对应的行添加锁定标识。
在本实施例的一个具体例子中，通过在统调层维护的数据库操作相关数据中的“锁”数据项中写入具体的锁定信息，实现对所述数据库操作影响的行标识对应的行的锁定，即：为所述行标识对应的行添加了锁定标识。
在本申请提供的一种优选实施方式中，采用过程锁对写操作实现访问控制，即：如果所述数据库操作的类型为新增操作、更新操作或者删除操作，则为所述行标识对应的行添加过程锁；如果所述数据库操作的类型为查询操作，则不必为所述行标识对应的行添加过程锁。
在其他实施方式中，也可以采用其他锁机制实现访问控制，例如，可以为当前事务中的新增操作、更新操作或者删除操作添加排他锁，从而其他事务不能同时访问本事务中的这些操作影响的行（不管其他事务是写还是读），可以避免其他事务读取本事务尚未提交的过程数据（中间数据），从而实现“读提交”的隔离级别，也就是说通过降低并发性提高了隔离的级别；再例如：可以为当前事务中的查询操作也添加过程锁，从而避免其他事务修改当前事务中的查询操作影响的行，保证当前事务中对相同行的前后两次查询，其查询结果是一致的，即实现了“可重复读”的隔离级别。上述实施方式的变更，可以基于业务系统的不同需求确定，不管采取哪种方式，只要满足了业务系统对隔离级别的需求，都不偏离本申请所述技术方案的核心，都在本申请的保护范围之内。
7）重新构造查询操作。
如果所述数据库操作是查询操作，并且统调层采用过程锁进行并发控制，那么如果直接执行查询操作，就有可能读取其他事务尚未提交的过程数据，即： 仅能实现最低的“读未提交”的隔离级别；如果采用排它锁进行并发控制，虽然可以实现“读提交”的隔离级别，但是会影响多事务的并发效果，因此本申请提供了一种优选实施方式，采取构造查询操作、合并查询结果的方式，在采用过程锁进行并发控制的同时，实现了“读提交”的隔离级别。
因此本申请提供的优选实施方式，在将所述数据库操作发送给所述目标数据库执行前，如果所述数据库操作为查询操作，并且在子步骤4）中获取的所述行标识的访问状态为，其他事务已经对所述行标识中的行添加了过程锁，那么需要执行以下步骤重构查询操作：
a)获取所述被锁定的行当前执行的数据库操作的类型。
在子步骤4）中，通过查找统调层维护的事务相关数据和数据库操作相关数据，已经获取所述行标识中对应的行的当前访问状态信息，从中获取被添加了过程锁的行当前执行的数据库操作的类型。在本实施例的一个具体例子中，所述查询操作影响的行标识为100、101、102，通过查找统调层的事务相关数据，发现有其他事务T1正在访问行标识为100的行，进一步查找事务T1对应的SQL语句集合，从中找到了当前访问行标识为100的行的SQL语句，可以看到事务T1已经为该行添加了过程锁，并且可以进一步获取所述SQL语句的类型，并进行下面的处理。
b)如果所述被锁定的行当前执行的数据库操作的类型为新增操作，将所述被锁定的行标记为不满足查询条件；如果所述被锁定的行当前执行的数据库操作的类型为更新操作或者删除操作，则进一步判断所述被锁定的行在执行当前的更新操作或者删除操作之前是否满足所述查询操作的条件，若是，则记录满足所述查询操作的条件的行；否则，将所述被锁定的行标记为不满足查询条件。
此处的操作主要是为了实现“读提交”的隔离级别。如果其他事务没有完成对所述锁定行的操作，即：尚未提交，那么当前的查询操作虽然可以访问这部分被其他事务锁定的行，但是不应该获取其中间数据，而是应该获取所述其他事务尚未执行前的数据。
如果所述被锁定的行当前执行的数据库操作的类型为新增操作，那么不管新增的行是否满足所述查询操作的条件，都应该将其标识为不满足查询条件，因为新增行是所述其他事务的中间数据。
如果所述被锁定的行当前执行的数据库操作的类型为更新操作或者删除操 作，则进一步读取统调层存储的所述被锁定的行在执行当前的更新操作或者删除操作之前的原数据库行的内容，并判断该内容是否满足所述查询操作的条件，若是，则记录原数据库行，否则，将被锁定的行标识为不满足查询条件。即使对被锁定的行执行当前的更新操作后满足所述查询操作的条件，也不能将其作为满足查询条件的结果，因为所述更新操作并没有提交，其更新后的行是其他事务的中间数据。
在本实施例的上述具体例子中，所述查询操作影响的行标识为100、101、102，其中其他事务T1正在访问并且锁定了行标识为100的行，而T1事务对所述行标识为100的行执行的是更新操作，并且所述行标识为100的行，其执行更新操作之前的内容不满足所述查询操作的条件，则将行标识为100的行标记为不满足查询条件。
c)生成剔除了所述不满足查询条件的行标识的查询操作。
根据上述处理结果，剔除不满足查询条件的行标识、重新生成查询操作语句。在本实施例的上述例子中，所述查询操作是：select*from table where queryCondition，因为行100被标识为不满足查询条件，因此重新构造后的查询操作是：select*from table where queryCondition and rowEid no in(‘100’)。
实施上述重新构造查询操作的步骤，是为了在采用过程锁的同时实现“读提交”的隔离级别，对于更新操作、删除操作、新增操锁不需要执行上述重构查询操作的步骤。对于其他实施方式，由于可能采用不同的锁机制和实现不同的隔离级别，因此上述针对查询操作执行的重构子步骤并不是必需的。
8）将所述数据库操作发送给所述目标数据库执行。
经过上面的7个子步骤，已经完成了将所述数据库操作发送到目标数据库之前所需要进行的必要处理操作，包括：分配行标识、执行等待、添加访问控制、重构查询操作等预处理，那么就可以将所述数据库操作或者重构的查询操作发送给目标数据库去执行。
为了在统调层统一维护各个分布式事务的信息，以及每个分布式事务包含的数据库操作的具体信息，需要在执行所述数据库操作之前，将与所述数据库操作相关的信息写入统调层的数据中，包括：所述数据库操作影响的行标识集合、如果所述数据库操作是写操作还要记录该操作执行前的原数据库行的内容、所述数据库操作的执行状态、所述数据库操作是否添加锁、以及锁的类型、执 行所述数据库操作的开始时间等。通常，直接将所述数据库操作作为所述分布式事务中的一个新的成员添加到所述分布式事务的数据库操作集合中即可，如果所述数据库操作影响的行与所述分布式事务之前执行过的某个数据库操作影响的行相同，例如：所述分布式事务中的前后两个数据库操作都是修改的同一个目标数据库中的同一行，那么所述数据库操作可以不额外占用新的存储空间，而是采用合适的策略更新前一个数据库操作的相关数据即可。
不仅仅在执行所述数据库操作之前需要更新统调层相关数据，在其他时机也应该进行相应的更新统调层数据的操作，例如：统调层接收到某个数据库操作请求后，应该记录该数据库操作的语句，并记录其执行状态为“待执行”，获取所述数据库操作的类型后，应该进行相应的记录，将所述数据库操作发送给目标数据库执行之前，更新所述数据库操作的执行状态为“执行中”、并记录开始执行的时间，目标数据库返回成功应答后，则更新所述数据库操作的执行状态为“执行成功”等。记录当前执行的分布式事务和数据库操作的相关数据，是统调层能够统一管理多个分布式事务的基础，不同的实施方式可能采取不同的数据结构、也可以采取不同的更新数据的时机，只要能够正确地记录各个事务和数据库操作当前的状态即可，具体实施方式的细节，不是本申请的核心，本申请不作具体限定。
然后将所述数据库操作或者重构的查询操作发送到目标数据库执行，并等待目标数据库的应答，通常目标数据库执行完毕所述数据库操作，就会将执行结果返回给统调层，但是考虑到在跨数据库分布式事务的场景下，统调层和目标数据库通常不在同一个物理地点，两者之间是通过网络连接进行交互，因此不可避免可能出现因为目标数据库自身故障或者网络连接暂时中断等原因导致的应答超时现象，即：统调层在一段预先设定的时间间隔内没有收到目标数据库的应答。预先设定的时间间隔，可以是统调层预先定义的一个统一的值（例如：100ms），也可以根据每个数据库操作不同的特点设置不同的值，在本实施例中，采用了后者的实现方式，即：在统调层维护的数据库操作相关数据中有一项数据“主动验证时间差”，在接收到所述数据库操作的请求后，即可根据所述数据库操作的类型为其设置该值，例如：对于要返回大量数据的查询操作，可以设置一个较大的值，对于仅仅修改一行的更新操作可以设置为相对较小的值。如果统调层向目标数据库发送执行所述数据库操作的命令后，统调层检测到当前时间与“开始执行时间”记录的时间的差值大于“主动验证时间差”设 定的值，统调层可以判定所述数据库操作可能出现故障，这时统调层可以采用主动查询的方式获取该数据库操作的执行情况。
9）向所述分布式事务的请求方返回所述数据库操作的执行结果。
接收目标数据库返回的所述数据库操作的执行结果，并将所述结果发送给所述分布式事务的请求方。
对于本申请提供的一种优选实施方式，为了实现“读提交”的隔离级别，针对查询操作在子步骤7）中重新构造了查询操作，相应的，在本子步骤中，也应该根据重新构造的查询操作的返回结果，执行必要的合并处理，即：将所述重构查询操作的执行结果，与已记录的满足所述查询操作的条件的行合并，并将合并后的结果返回给所述分布式事务的请求方。在本实施例的一个具体例子中，如果在子步骤7）中，统调层已经在满足条件的原数据库行的集合中记录了10条数据（即：有10行满足查询条件），将重新构造的查询操作发送到目标数据库表中查询时又返回10条，那么在统调层就需要将这20条数据归并后返回给所述数据库操作的请求方。
通常情况下，目标数据库可以正确执行所述数据库操作，并返回操作成功应答，但是也不排除可能出现目标数据库执行异常、并向统调层返回操作失败应答的情况，这种情况下统调层采用回滚机制来保证分布式事务的原子性、一致性和持久性。
由于事务是一组逻辑相关的数据库操作序列，是一个不可分割的操作单位，对于其中的数据库操作，要么全都执行，要么全都不执行，一个事务不可能只执行了一半就停止，这也是事务原子性的基本要求。如果事务中的某个点发生故障，则该事务所做的所有更新都应该恢复到事务开始之前的状态。
实现事务的原子性，通常采用回滚（rolling back）机制，所谓回滚是指，撤销一个未成功事务中已执行的数据库操作对数据所作的修改，也就是说，如果事务中任何一个数据库操作执行失败，那么该事务中已经执行成功的数据库操作也必须撤销，使数据库状态回退到执行事务前的状态。回滚的实现，通常可以采用类似逆操作的方式，即：撤销新增操作，执行相应的删除操作即可；撤销删除操作，执行相应的新增操作即可；撤销更新操作，执行恢复原始数据的更新操作即可。由此可见，为了实现回滚机制，必须保存写操作执行前的数据库数据的内容。统调层在其维护的数据库操作相关的数据中，有一项数据“写 操作执行前的数据库数据内容”，之所以设计该数据项，一方面是用于实现“读提交”隔离级别的重构查询操作，另一方面就是为了实现事务的回滚机制。
所述分布式事务在执行过程中出现异常，那么统调层可以在将该结果返回给所述分布式事务的请求方后，主动执行回滚操作，也可以等待所述分布式事务的请求方下发启动回滚操作的命令后再执行回滚，这两种方式都可以保证所述分布式事务的原子性。统调层通过下述步骤执行回滚操作：
a)更新统调层数据，将所述分布式事务的执行状态更新为“回滚中”，将所述分布式事务中所有需要撤销的数据库操作的执行状态都更新为“待回滚”；
b)针对每个待撤销的数据库操作，根据“写操作执行前的数据库数据内容”数据项的内容，构造所述数据库操作的逆操作或者是恢复数据原始内容的更新操作，然后发送到目标数据库执行。在执行前更新所述数据库操作的状态为“回滚中”，执行结束后更新其状态为“回滚成功”；
c)向所述分布式事务的请求方上报“回滚成功”消息，告知所述分布式事务的请求方，所述分布式事务已经撤销。当然，作为一种异常情况，回滚操作也可能失败，这种情况下统调层也可以不自发采取动作，而是将该情况上报所述分布式事务的请求方，然后由所述分布式事务的请求方根据应用层的策略下发再次回滚或者是清除所述分布式事务的命令。
步骤104：待所有的数据库操作执行完毕，清除所述分布式事务。
一方面，如果统调层将接收到的所述分布式事务中的所有数据库操作都执行完毕，包括执行成功和回滚成功两种情况，那么统调层就可以清除所述分布式事务；另一方面，统调层也可以在接收所述分布式事务请求方下发的关于所述分布式事务结束的显示指示后，清除所述分布式事务。
清除所述分布式事务，主要包括以下两方面的操作：
1）对所述分布式事务锁定的行执行解除锁定操作。
由于统调层在所述分布式事务的执行过程中，为了实现并发事务的访问控制和实现一定的隔离级别，采用了锁机制，因此所述分布式事务中的数据库操作所影响的行目前可能还处于锁定状态，也就是说所述分布式事务可能还是一个或者多个锁的持有者，这种情况下，统调层需要对所述分布式事务锁定的行执行解除锁定的操作，也就是释放所述分布式事务持有的锁，这样其他阻塞在上述锁上的其他分布式事务就可以结束等待状态，并得以执行，从而保证跨数 据库分布式事务的正常运转。
2）删除所述分布式事务标识及对应的内存数据。
因为所述分布式事务已经执行完毕，因此统调层需要从其维护的统调层数据中删除与所述事务相关的数据，包括：所述分布式事务的标识、执行状态、所述分布式事务包含的数据库操作集合、以及其他与所述分布式事务相关的数据，并从统调层维护的全局事务列表中删除所述分布式事务。通过清理已完成的分布式事务的相关数据，统调层可以有效地回收和管理其使用的内存空间，避免出现过度消耗内存空间的情况。
上面介绍了跨数据库分布式事务的启动、执行、以及结束的处理过程，在实际实施过程中，还要考虑一些可能出现的异常情况，并为异常情况设置必要的处理方式，从而保证统调层即使在异常情况下也能够正常运转并且保证跨数据库分布式事务的ACID特性。统调层可以提供两种级别的异常处理机制：
1）数据库操作级别的异常处理机制。前面提到过的统调层将所述数据库操作发给目标数据库后，可能会出现目标数据库应答超时的情况，这时统调层可以通过主动查询的方式获取所述数据库操作的实际执行情况。这种异常处理机制属于数据库操作级别的异常处理机制。
2）事务级别的异常处理机制。由于跨数据库分布式事务的特点，所述分布式事务在执行的过程中可能出现各种难以预测的问题，导致所述分布式事务出现超时的现象，针对这一问题，统调层采用如下机制进行处理：统调层判断所述分布式事务的持续时间，如果发现所述持续时间大于预先设定的时间（即：统调层维护的数据中针对每个分布式事务的事务超时设置），则抛出超时异常，对应的异常处理程序捕获到该异常后，可以根据预先设定的策略进行必要的处理，例如：发起所述分布式事务的回滚操作等。当然，上述事务超时异常，只是分布式事务执行过程中可能出现的一种异常情况，在具体的实施过程中，对于可能出现的其他异常，也可以采用类似的处理方式，交由异常处理程序处理。
在跨数据库分布式事务的实现过程中，除了要考虑上述可能出现的异常情况，还必须考虑系统可能发生灾难性事件，例如宕机等突发事件，可能导致某个分布式事务只执行了部分数据库操作，使目标数据库的数据处于不一致的状态。作为一个完善的跨数据库分布式事务，必须具备处理上述灾难性事件的能力，即：必须能够恢复尚未执行完毕的分布式事务的数据。要实现这一点，通 常需要采用日志机制，即：在统调层维护一个事务日志文件，用于记录所有事务以及每个事务对目标数据库所做的修改，一旦系统出现故障，则使用事务日志撤销事务对目标数据库已做的更新，将目标数据库恢复到执行事务前的一致状态。统调层采用前面介绍的回滚机制和日志技术来保证分布式事务的原子性、一致性和持久性。
在统调层实现日志功能，需要执行两方面的操作：
1）生成并维护事务日志文件。将统调层维护的分布式事务的相关数据，以及分布式事务中每个数据库操作的相关数据写入事务日志文件中，为了保证事务日志文件能够正确反映分布式事务的执行状态，最好采用实时写入事务日志文件的方式，即：统调层每次更新其维护的数据时，也同时将更新的内容写入事务日志文件中。当某个分布式事务执行完毕，统调层在清理与该事务相关的数据的同时，也应该删除事务日志文件中记录的有关该分布式事务的数据，并将回收的事务日志文件的空间用于存储其他分布式事务的日志数据。
2）统调层重新启动时，加载所述日志文件中的事务数据并进行必要的回滚操作。
一旦发生宕机等灾难性事件，统调层在重新启动的过程中，首先读取并加载日志文件中的数据，恢复统调层在重新启动之前的分布式事务的执行状态，并针对尚未执行完的分布式事务执行回滚操作，撤销该分布式事务对目标数据库已做的更新，将目标数据库恢复到执行该分布式事务前的初始状态，从而保证事务的原子性。这里所述的回滚操作与事务执行过程中的回滚操作类似，具体步骤可以参见步骤103中的相关说明，此处不再赘述。
在发生异常的情况下，一方面采用回滚机制和日志机制，可以保证分布式事务的原子性、一致性和持久性；另一方面，统调层也需要考虑其自身数据的合理维护机制。统调层记录了与分布式事务相关的数据以及与分布式事务中的数据库操作相关的数据，在分布式事务正常结束的情况下，上述数据会被统调层及时清理，在发生异常的情况下，上述数据可能被遗忘，从而成为占用统调层内存空间的无效数据，为了对上述无效数据提供清理机制，本申请所提供的方法在统调层的全局数据中写入“事务清理时间”这一数据项，用于在特定的时间点上将异常的已经终结的事务清理掉。具体地说，统调层可以在设定的事务清理时间点上扫描其维护的所有分布式事务的执行状态，如果发现该分布式 事务的状态一直未被更新，即：该分布式事务处于非活跃状态，则统调层可以主动发起清理该分布式事务的操作。
采用本申请提供的跨数据库分布式事务的实现方法，通过在目标数据库系统中使用唯一的行标识，并采用访问控制机制对分布式事务的访问操作进行统一管理，避免了对目标数据库的非同步操作导致数据不一致的问题，实现了轻量级的、易于维护、并且满足ACID原则的跨数据库分布式事务。
本申请提供的一种优选实施方式，通过对分布式事务中的写操作（包括新增操作、更新操作和删除操作）加过程锁，即：允许其他分布式事务读取所述写操作影响的行但是不能对所述行执行写操作，同时还采用了重构查询语句、合并查询结果的方式，避免读取其他事务尚未提交的过程数据，从而在实现跨数据库分布式事务的“读提交”隔离级别的同时，也取得较好的并发性效果。
在上述的实施例中，提供了一种跨数据库分布式事务的实现方法，与之相对应的，本申请还提供一种跨数据库分布式事务的实现装置。请参看图2，其为本申请的一种跨数据库分布式事务的实现装置的实施例示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。
本实施例的一种跨数据库分布式事务的实现装置，包括：事务启动单元201，用于接收分布式事务的启动请求，并为所述分布式事务分配事务标识；操作接收单元202，用于接收被分配事务标识的分布式事务的针对数据库操作的操作请求或操作请求集合；操作执行单元203，用于针对每个操作请求，获取所述数据库操作的目标数据库信息，并遵循ACID原则将所述数据库操作发送到所述目标数据库执行；事务清除单元204，用于待所述分布式事务执行完毕后，清除所述分布式事务。
可选的，所述操作执行单元采用如下方式获取所述数据库操作的目标数据库信息：根据所述数据库操作指定的目标数据库和/或表的名称，查找预先设置的数据库描述信息，从中获取与所述目标数据库和/或表的名称对应的目标数据库信息。
可选的，所述操作执行单元包括：
目标数据库查询子单元，用于根据所述数据库操作指定的目标数据库和/或表的名称，查找预先设置的数据库描述信息，从中获取与所述目标数据库和/或 表的名称对应的目标数据库信息；
操作类型获取子单元，用于获取所述数据库操作的类型；
行标识获取子单元，用于解析所述数据库操作，获取所述数据库操作影响的行标识；
访问状态获取子单元，用于获取所述行标识对应的行的当前访问状态；
等待子单元，用于根据所述行标识对应的行的当前访问状态和所述数据库操作的类型，判断是否需要等待所述行标识对应的行的访问结束；若是，则执行等待，等到所述行标识对应的行的访问结束，再执行下述步骤；若否，继续执行下述步骤；
访问控制子单元，用于根据所述数据库操作的类型，判断是否需要获取对所述行标识对应的行的访问控制，若是，则为所述行标识对应的行添加访问控制；
操作执行子单元，用于将所述数据库操作发送给所述目标数据库执行；
结果返回子单元，用于向所述分布式事务的请求方返回所述数据库操作的执行结果。
可选的，所述操作执行单元还包括：
操作超时处理子单元，用于当没有在预先设定的时间内收到目标数据库返回的执行结果时，通过主动访问目标数据库的方式获取所述数据库操作的执行结果。
可选的，所述操作类型获取子单元获取的操作类型包括：新增操作、更新操作、删除操作或读取操作。
可选的，所述行标识获取子单元包括：
行标识分配子单元，用于当所述数据库操作的类型为新增操作时，为所述新增操作分配一个唯一标识该行的行标识，并将所述行标识添加到新增操作中；
行标识查询子单元，用于将所述数据库操作解析为采用相同条件的获取行标识的查询操作，并将所述查询操作发送给所述目标数据库执行，将所述目标数据库返回的行标识作为所述数据库操作影响的行标识。
可选的，所述等待子单元具体用于，当所述数据库操作的类型是新增操作或者查询操作时，不执行等待；当所述数据库操作的类型是更新操作或者删除 操作时，如果所述行标识对应的行当前没有被当前分布式事务之外的事务访问，或者虽被当前分布式事务之外的事务访问但没有被锁定，则不执行等待，否则执行等待。
可选的，所述访问控制子单元具体用于，当所述数据库操作的类型为新增操作、更新操作或者删除操作时，为所述行标识对应的行添加允许执行查询操作但不允许执行新增操作、更新操作和删除操作的过程锁。
可选的，所述操作执行单元还包括：
查询操作重构子单元，用于当所述数据库操作的类型为查询操作、并且所述行标识中存在被当前分布式事务之外的事务锁定的行时，重新构造查询操作。
所述查询操作重构子单元包括：
锁定行操作类型获取子单元，用于获取所述被锁定的行当前执行的数据库操作的类型；
查询条件验证子单元，用于当所述被锁定的行当前执行的数据库操作的类型为新增操作时，将所述被锁定的行标记为不满足查询条件；当所述被锁定的行当前执行的数据库操作的类型为更新操作或者删除操作、并且所述被锁定的行在执行当前的更新操作或者删除操作之前满足所述查询操作的条件时，记录满足所述查询操作的条件的行，否则，将所述被锁定的行标记为不满足查询条件；
查询操作生成子单元，用于生成剔除了所述不满足查询条件的行标识的查询操作；
相应的，所述操作执行子单元具体用于将重新构造的查询操作发送给所述目标数据库执行。
相应的，所述结果返回子单元具体用于，将所述查询操作的执行结果，与已记录的满足所述查询操作的条件的行合并，并将合并后的结果返回给所述分布式事务的请求方。
可选的，所述装置还包括：
数据写入单元，用于将所述分布式事务的相关信息和所述分布式事务包括的数据库操作的相关信息写入与所述分布式事务标识对应的内存数据中。
可选的，所述事务清除单元包括：
解除锁定子单元，用于对所述分布式事务锁定的行执行解除锁定操作；
数据清除子单元，用于删除所述分布式事务标识及与所述分布式事务相关的内存数据。
可选的，所述装置还包括：
回滚单元，用于获取数据库操作的执行结果，当所述分布式事务中的某个数据库操作未能执行成功时，对所述分布式事务中的已经成功执行的其他数据库操作执行回滚操作，恢复到所述分布式事务执行前的状态。
可选的，所述装置还包括：
异常处理单元，用于判断所述分布式事务的持续时间，如果所述分布式事务未能在预先设定的时间内完成，则触发异常处理程序执行回滚操作。
可选的，所述装置还包括：
日志管理单元，用于将所述分布式事务的执行过程以及所述分布式事务对目标数据库所做的修改写入日志文件中。
可选的，所述装置还包括：
事务恢复单元，用于读取所述日志文件，并根据所述日志文件中记录的分布式事务的信息，对尚未完成的分布式事务执行回滚操作。
本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其 他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。