《保证跨数据源操作结果一致性的装置和方法.pdf》由会员分享，可在线阅读，更多相关《保证跨数据源操作结果一致性的装置和方法.pdf（20页珍藏版）》请在专利查询网上搜索。
1、(10)申请公布号 CN 102306197 A (43)申请公布日 2012.01.04 CN 102306197 A *CN102306197A* (21)申请号 201110283994.9 (22)申请日 2011.09.22 G06F 17/30(2006.01) (71)申请人 用友软件股份有限公司 地址 100094 北京市海淀区北清路 68 号用 友软件园 (72)发明人 栗竹冉 (74)专利代理机构 北京友联知识产权代理事务 所 ( 普通合伙 ) 11343 代理人 尚志峰 汪海屏 (54) 发明名称 保证跨数据源操作结果一致性的装置和方法 (57) 摘要 本发明提供了一种保。
2、证跨数据源操作结果一 致性的方法， 包括 ： 打开消息中间件的本地事务， 当接收到来自消息中间件的指定列队中的消息 时， 根据消息创建一个全局事务， 开始第二数据源 的本地事务， 其中， 消息中间件为第一数据源 ； 根 据消息的业务处理需要从第二数据源中获取所需 业务数据， 在业务处理结束时， 将生成的处理结果 保存至第二数据源 ； 根据返回的处理结果发起提 交或者回滚全局事务的过程， 先提交或者回滚第 二数据源的本地事务， 然后提交或者回滚消息中 间件的本地事务， 全局事务提交或者回滚成功后， 释放全局事务的相关资源。本发明还提供了一种 保证跨数据源操作结果一致性的装置。可以在非 XA 协议。
3、方式下， 保证跨数据源的操作结果的一致 性。 (51)Int.Cl. (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书 3 页 说明书 10 页 附图 6 页 CN 102306204 A1/3 页 2 1. 一种保证跨数据源操作结果一致性的装置， 其特征在于， 包括 ： 消息处理单元， 请求打开消息中间件的本地事务， 接收来自所述消息中间件的指定列 队中的消息， 根据所述消息向全局事务控制单元发送创建一个全局事务的第一请求以及在 接收到来自应用服务单元返回的处理结果时， 向所述全局事务控制单元发送发起提交或者 回滚所述全局事务的过程的第二请求以及在接收到来自所述全局事务。
4、单元的命令时， 提交 或者回滚所述消息中间件的本地事务， 所述消息中间件的本地事务为在所述消息中间件上 运行的事务， 所述消息中间件为第一数据源 ； 所述全局事务控制单元， 在接收到来自所述消息处理单元的所述第一请求时， 创建一 个所述全局事务， 开始第二数据源的本地事务以及在接收到来自所述消息单元的所述第二 请求时， 发起提交或者回滚所述全局事务的过程， 先提交或者回滚所述第二数据源的本地 事务， 然后命令所述消息处理单元提交或者回滚所述消息中间件的本地事务， 以完成所述 全局事务的提交或者回滚过程， 所述全局事务提交成功后， 释放所述全局事务的相关资源， 所述全局事务为跨所述第一数据源和所。
5、述第二数据源运行的事务， 所述第二数据源的本地 事务为在所述第二数据源上运行的事务 ； 所述应用服务单元， 根据所述消息的业务处理需要从所述第二数据源中获取所需业务 数据， 在所述业务处理结束时， 将生成的处理结果保存至所述第二数据源， 将所述处理结果 返回至所述消息处理单元。 2. 根据权利要求 1 所述的保证跨数据源操作结果一致性的装置， 其特征在于， 所述消 息单元还用于在接收到所述消息时， 请求所述全局事务控制单元查看所述消息是否为第一 次处理的消息以及接收来自所述全局事务单元的所述全局事务的标识并将所述标识发送 至所述应用单元 ； 所述全局事务单元还用于在确定所述消息为第一次处理时，。
6、 请求为创建的所述全局事 务分配相应的标识， 并将所述标识发送至所述消息单元， 在确定所述消息不是第一次被处 理时， 根据恢复出来的对应的所述全局事务的状态继续处理所述消息。 3. 根据权利要求 1 所述的保证跨数据源操作结果一致性的装置， 其特征在于， 所述全 局事务控制单元包括 ： 状态修改模块， 在所述应用服务单元处理所述消息之前， 设置所述全局事务的状态为 正在进行业务处理状态， 在进行所述消息的处理过程时， 将所述消息中间件的本地事务的 状态和所述第二数据源的本地事务的状态均设置为正在进行业务处理状态以及在发起提 交所述全局事务的过程时， 修改所述全局事务的状态为正在提交状态， 修改。
7、所述消息中间 件的本地事务的状态为正在提交状态， 预先修改所述第二数据源的本地事务的状态为提交 完成状态， 当监控到所述第二数据源的本地事务和所述消息中间件的本地事务均提交完成 时， 先修改所述消息中间件的本地事务的状态为提交完成状态， 然后修改所述全局事务的 状态为提交完成状态， 释放所述全局事务的相关资源。 4. 根据权利要求 3 所述的保证跨数据源操作结果一致性的装置， 其特征在于， 所述全 局事务控制单元还包括 ： 恢复模块， 在提交所述第二数据源的本地事务之前， 若出现异常并重新启动， 则回滚所 述消息中间件的本地事务， 将所述消息返回到所述消息中间件的指定列队中， 所述应用服 务单。
8、元将重新处理所述消息， 在提交所述消息中间件的本地事务之前， 若出现异常并重新 权 利 要 求 书 CN 102306197 A CN 102306204 A2/3 页 3 启动， 则回滚所述消息中间件的本地事务， 将所述消息返回到所述消息中间件的指定列队 中， 所述应用服务单元将重新处理所述消息， 处理结束后删除所述消息以及在修改所述消 息中间件的本地事务的状态为提交完成状态之前， 若出现异常并重新启动， 则在所述消息 中间件中删除所述消息。 5. 根据权利要求 4 所述的保证跨数据源操作结果一致性的装置， 其特征在于， 所述全 局事务控制单元还包括 ： 控制模块， 在所述消息中间件的本地事。
9、务的状态和所述第二数据源的本地事务的状态 均设置为正在进行业务处理状态时， 允许在所述全局事务中加入其它数据源的本地事务， 在所述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状 态时， 不允许在所述全局事务中加入所述其它数据源的本地事务 ； 所述消息中间件的本地事务的状态信息、 所述第二数据源的本地事务的状态信息以及 所述全局事务的状态信息保存在所述第二数据源中， 所述第二数据源为数据库数据源。 6. 一种保证跨数据源操作结果一致性的方法， 其特征在于， 包括 ： 步骤 602， 打开消息中间件的本地事务， 当接收到来自所述消息中间件的指定列队中的 消息时， 根据所述消。
10、息创建一个全局事务， 开始第二数据源的本地事务， 其中， 所述消息中 间件为第一数据源， 所述消息中间件的本地事务为在所述消息中间件上运行的事务， 所述 第二数据源的本地事务为在所述第二数据源上运行的事务， 所述全局事务为跨所述第一数 据源和所述第二数据源运行的事务 ； 步骤 604， 根据所述消息的业务处理需要从所述第二数据源中获取所需业务数据， 在所 述业务处理结束时， 将生成的处理结果保存至所述第二数据源 ； 步骤 606， 根据返回的所述处理结果发起提交或者回滚所述全局事务的过程， 先提交或 者回滚所述第二数据源的本地事务， 然后提交或者回滚所述消息中间件的本地事务， 以完 成所述全局。
11、事务的提交或者回滚过程， 所述全局事务提交成功后， 释放所述全局事务的相 关资源。 7. 根据权利要求 6 所述的保证跨数据源操作结果一致性的方法， 其特征在于， 所述步 骤 602 还包括 ： 判断所述消息是否为第一次处理的消息， 若判断出所述消息为第一次处理， 则创建所述全局事务并请求为所述全局事务分配标识， 根据所述标识处理所述消息， 若判 断出所述消息不是第一次被处理， 则根据恢复出来的对应的所述全局事务的状态继续处理 所述消息。 8. 根据权利要求 6 所述的保证跨数据源操作结果一致性的方法， 其特征在于， 所述步 骤 602 还包括 ： 在处理所述消息之前， 设置所述全局事务的状态。
12、为正在进行业务处理状态， 在进行所述消息的处理过程时， 将所述消息中间件的本地事务的状态和所述第二数据源的 本地事务的状态均设置为正在进行业务处理状态 ； 所述步骤 606 还包括 ： 在发起提交所述全局事务的过程时， 修改所述全局事务的状态 为正在提交状态， 修改所述消息中间件的本地事务的状态为正在提交状态， 预先修改所述 第二数据源的本地事务的状态为提交完成状态， 当监控到所述第二数据源的本地事务和所 述消息中间件的本地事务均提交完成时， 先修改所述消息中间件的本地事务的状态为提交 完成状态， 然后修改所述全局事务的状态为提交完成状态， 释放所述全局事务的相关资源。 9. 根据权利要求 8。
13、 所述的保证跨数据源操作结果一致性的方法， 其特征在于， 所述步 权 利 要 求 书 CN 102306197 A CN 102306204 A3/3 页 4 骤 606 还包括 ： 在提交所述第二数据源的本地事务之前， 若出现异常并重新启动， 则回滚所 述消息中间件的本地事务， 所述消息返回到所述消息中间件的指定列队中， 重新处理所述 消息 ； 在提交所述消息中间件的本地事务之前， 若出现异常并重新启动， 则回滚所述消息中 间件的本地事务， 将所述消息返回到所述消息中间件的指定列队中， 重新处理所述消息， 处 理结束后删除所述消息 ； 在修改所述消息中间件的本地事务的状态为提交完成状态之前，。
14、 若出现异常并重新启 动， 则在所述消息中间件中删除所述消息。 10. 根据权利要求 8 所述的保证跨数据源操作结果一致性的方法， 其特征在于， 当所述 消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行业 务处理状态时， 允许在所述全局事务中加入其它数据源的本地事务， 当所述消息中间件的 本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时， 不允许在所述全 局事务中加入所述其它数据源的本地事务， 所述消息中间件的本地事务的状态信息、 所述 第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据源 中， 所述第二数据源为数据库数据源。 权。
15、 利 要 求 书 CN 102306197 A CN 102306204 A1/10 页 5 保证跨数据源操作结果一致性的装置和方法 技术领域 0001 本发明涉及同步技术领域， 具体而言， 涉及保证跨数据源操作结果一致性的装置 和方法。 背景技术 0002 在当前的企业级分布式生产环境中， 多个数据源的使用在保持高效率、 高可用的 同时也带来了如何保证跨数据源的全局事务的操作结果一致性问题。 目前主流的解决方案 一般是利用独立的事务管理器， 使用XA协议的两阶段提交过程来保证其一致性(详请参见 X/OPEN 组织定义的 XA 规范 )。但 XA 协议有以下的弊端 ： 0003 1. 使用 X。
16、A 协议实现的事务本身要用到数据源的一些关键资源， 这使得对数据源 的性能有一定的影响。 0004 2.根据XA规范， XA协议在预提交成功后会要求数据源锁定本事务相关的资源 ； 直 到第二阶段 ( 真正的提交或者回滚 ) 完成， 相关资源的锁才会被释放。一旦在第二阶段异 常， 在事务完成前的很长一段时间里被锁定的资源将会不可访问， 这在很多客户现场是不 可接受的。 0005 3. 这种锁是一种 “硬锁”即使连接断掉、 数据库实例甚至整个机器重新启动 该锁都不会释放， 这对某些数据访问实时性要求很高的系统是不合适的。 0006 从以上描述不难看出使用 XA 协议做分布式的事务管理的种种弊端， 。
17、在一些特定 的情况下可能因为对资源的锁定会造成一时间事务相关的数据不可访问， 从而给客户以很 差的使用体验。 0007 因此， 如何在不使用 XA 协议的情况下保证跨数据源的分布式全局事务的一致性， 是需要解决的问题。 发明内容 0008 本发明所要解决的技术问题在于， 提供一种数据同步技术， 可以在不使用 XA 协议 的情况下保证跨数据源的分布式全局事务的一致性。 0009 根据本发明的一个方面， 提供了一种保证跨数据源操作结果一致性的装置， 包括 ： 消息处理单元， 请求打开消息中间件的本地事务， 接收来自所述消息中间件的指定列队中 的消息， 根据所述消息向全局事务控制单元发送创建一个全局。
18、事务的第一请求以及在接收 到来自应用服务单元返回的处理结果时， 向所述全局事务控制单元发送发起提交或者回滚 所述全局事务的过程的第二请求以及在接收到来自所述全局事务单元的命令时， 提交或者 回滚所述消息中间件的本地事务， 所述消息中间件的本地事务为在所述消息中间件上运行 的事务， 所述消息中间件为第一数据源 ； 所述全局事务控制单元， 在接收到来自所述消息处 理单元的所述第一请求时， 创建一个所述全局事务， 开始第二数据源的本地事务以及在接 收到来自所述消息单元的所述第二请求时， 发起提交所述全局事务的过程， 先提交所述第 二数据源的本地事务， 然后命令所述消息处理单元提交所述消息中间件的本地。
19、事务， 以完 说 明 书 CN 102306197 A CN 102306204 A2/10 页 6 成所述全局事务的提交或者回滚过程， 所述全局事务提交或者回滚成功后， 释放所述全局 事务的相关资源， 所述全局事务为跨所述第一数据源和所述第二数据源运行的事务， 所述 第二数据源的本地事务为在所述第二数据源上运行的事务 ； 所述应用服务单元， 根据所述 消息的业务处理需要从所述第二数据源中获取所需业务数据， 在所述业务处理结束时， 将 生成的处理结果保存至所述第二数据源， 将所述处理结果返回至所述消息处理单元。 0010 在上述技术方案中， 优选地， 所述消息单元还用于在接收到所述消息时， 请。
20、求所述 全局事务控制单元查看所述消息是否为第一次处理的消息以及接收来自所述全局事务单 元的所述全局事务的标识并将所述标识发送至所述应用单元 ； 所述全局事务单元还用于在 确定所述消息为第一次处理时， 请求为创建的所述全局事务分配相应的标识， 并将所述标 识发送至所述消息单元， 在确定所述消息不是第一次被处理时， 根据恢复出来的对应的所 述全局事务的状态继续处理所述消息。 0011 在上述技术方案中， 优选地， 所述全局事务控制单元包括 ： 状态修改模块， 在所述 应用服务单元处理所述消息之前， 设置所述全局事务的状态为正在进行业务处理状态， 在 进行所述消息的处理过程时， 将所述消息中间件的本。
21、地事务的状态和所述第二数据源的本 地事务的状态均设置为正在进行业务处理状态以及在发起提交所述全局事务的过程时， 修 改所述全局事务的状态为正在提交状态， 修改所述消息中间件的本地事务的状态为正在提 交状态， 预先修改所述第二数据源的本地事务的状态为提交完成状态， 当监控到所述第二 数据源的本地事务和所述消息中间件的本地事务均提交完成时， 先修改所述消息中间件的 本地事务的状态为提交完成状态， 然后修改所述全局事务的状态为提交完成状态， 释放所 述全局事务的相关资源。 0012 在上述技术方案中， 优选地， 所述全局事务控制单元还可以包括 ： 恢复模块， 在提 交所述第二数据源的本地事务之前， 。
22、若出现异常并重新启动， 则回滚所述消息中间件的本 地事务， 将所述消息返回到所述消息中间件的指定列队中， 系统恢复后， 所述应用服务单元 将重新处理所述消息， 在提交所述消息中间件的本地事务之前， 若出现异常并重新启动， 则 回滚所述消息中间件的本地事务， 将所述消息返回到所述消息中间件的指定列队中， 在系 统恢复后， 所述应用服务单元将重新处理该消息， 而由于针对本消息的第二数据源处理已 经完成 ( 通过激烈的本地事务状态可以查询 )， 所以处理结束后只要删除所述消息就行以 及在修改所述消息中间件的本地事务的状态为提交完成状态之前， 若出现异常并重新启 动， 则在所述消息中间件中删除所述消息。
23、。 0013 在上述技术方案中， 优选地， 所述全局事务控制单元还可以包括 ： 控制模块， 在所 述消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行 业务处理状态时， 允许在所述全局事务中加入其它数据源的本地事务， 在所述消息中间件 的本地事务的状态和所述第二数据源的本地事务的状态均提交完成状态时， 不允许在所述 全局事务中加入所述其它数据源的本地事务 ； 所述消息中间件的本地事务的状态信息、 所 述第二数据源的本地事务的状态信息以及所述全局事务的状态信息保存在所述第二数据 源中， 所述第二数据源为数据库数据源。 0014 通过上述技术方案， 可以使用非 XA 协议方。
24、式来保证跨数据源的数据操作结果一 致性利用保存在第二数据源里的全局事务的状态， 来双向核对 DBMS( 第二数据源 ) 和 MOM( 消息中间件， 第一数据源 ) 这两类数据源， 通过绝对的状态控制来保证事务业务处理 说 明 书 CN 102306197 A CN 102306204 A3/10 页 7 的操作结果一致性。 0015 根据本发明的又一方面， 还提供了一种保证跨数据源操作结果一致性的方法， 包 括 ： 步骤 602， 打开消息中间件的本地事务， 当接收到来自所述消息中间件的指定列队中的 消息时， 根据所述消息创建一个全局事务， 开始第二数据源的本地事务， 其中， 所述消息中 间件。
25、为第一数据源， 所述消息中间件的本地事务为在所述消息中间件上运行的事务， 所述 第二数据源的本地事务为在所述第二数据源上运行的事务， 所述全局事务为跨所述第一数 据源和所述第二数据源运行的事务 ； 步骤 604， 根据所述消息的业务处理需要从所述第二 数据源中获取所需业务数据， 在所述业务处理结束时， 将生成的处理结果保存至所述第二 数据源 ； 步骤 606， 根据返回的所述处理结果发起提交或者回滚所述全局事务的过程， 先提 交或者回滚所述第二数据源的本地事务， 然后提交或者回滚所述消息中间件的本地事务， 以完成所述全局事务的提交或者回滚过程， 所述全局事务提交或者回滚成功后， 释放所述 全局。
26、事务的相关资源。 0016 在上述技术方案中， 优选地， 所述步骤 602 还可以包括 ： 判断所述消息是否为第一 次处理的消息， 若判断出所述消息为第一次处理， 则创建所述全局事务并请求为所述全局 事务分配标识， 根据所述标识处理所述消息， 若判断出所述消息不是第一次被处理， 则根据 恢复出来的对应的所述全局事务的状态继续处理所述消息。 0017 在上述技术方案中， 优选地， 所述步骤 602 还可以包括 ： 在处理所述消息之前， 设 置所述全局事务的状态为正在进行业务处理状态， 在进行所述消息的处理过程时， 将所述 消息中间件的本地事务的状态和所述第二数据源的本地事务的状态均设置为正在进行。
27、业 务处理状态 ； 所述步骤 606 还包括 ： 在发起提交所述全局事务的过程时， 修改所述全局事务 的状态为正在提交状态， 修改所述消息中间件的本地事务的状态为正在提交状态， 预先修 改所述第二数据源的本地事务的状态为提交完成状态， 当监控到所述第二数据源的本地事 务和所述消息中间件的本地事务均提交完成时， 先修改所述消息中间件的本地事务的状态 为提交完成状态， 然后修改所述全局事务的状态为提交完成状态， 释放所述全局事务的相 关资源。 0018 在上述技术方案中， 优选地， 所述步骤 606 还可以包括 ： 在提交所述第二数据源的 本地事务之前， 若出现异常并重新启动， 则回滚所述消息中间。
28、件的本地事务和所述第二数 据源的本地事务， 所述消息回到所述消息中间件的指定列队中， 重新处理所述消息 ； 在提交 所述消息中间件的本地事务之前， 若出现异常并重新启动， 则回滚所述消息中间件的本地 事务， ， 将所述消息返回到所述消息中间件的指定列队中， 重新处理所述消息， 处理结束后 删除所述消息 ； 在修改所述消息中间件的本地事务的状态为提交完成状态之前， 若出现异 常并重新启动， 则在所述消息中间件中删除所述消息。 0019 在上述技术方案中， 优选地， 当所述消息中间件的本地事务的状态和所述第二数 据源的本地事务的状态均设置为正在进行业务处理状态时， 允许在所述全局事务中加入其 它数。
29、据源的本地事务， 当所述消息中间件的本地事务的状态和所述第二数据源的本地事务 的状态均提交完成状态时， 不允许在所述全局事务中加入所述其它数据源的本地事务， 所 述消息中间件的本地事务的状态信息、 所述第二数据源的本地事务的状态信息以及所述 全局事务的状态信息保存在所述第二数据源中， 所述第二数据源为数据库数据源 ( 例如， OLTP 数据源 )。 说 明 书 CN 102306197 A CN 102306204 A4/10 页 8 0020 通过上述技术方案， 可以使用非 XA 协议方式来保证跨数据源的数据操作结果一 致性利用保存在第二数据源里的全局事务的状态， 来双核对 DBMS( 第二。
30、数据源 ) 和 MOM( 消息中间件， 第一数据源 ) 这两类数据源， 通过绝对的状态控制来保证事务业务处理 的操作结果一致性。 附图说明 0021 图 1 示出了根据本发明的实施例的保证跨数据源操作结果一致性的系统的框图 ； 0022 图 2 示出了根据本发明的实施例的多模块协作的时序图 ； 0023 图 3 示出了根据本发明的实施例的全局事务的状态变化示意图 ； 0024 图 4 示出了根据本发明的实施例的全局事务中的分支状态变化示意图 ； 0025 图 5 示出了根据本发明的实施例的保证跨数据源操作结果一致性的装置的框图 ； 以及 0026 图 6 示出了根据本发明的实施例的保证跨数据源。
31、操作结果一致性的方法的流程 图。 具体实施方式 0027 为了能够更清楚地理解本发明的上述目的、 特征和优点， 下面结合附图和具体实 施方式对本发明进行进一步的详细描述。 0028 在下面的描述中阐述了很多具体细节以便于充分理解本发明， 但是， 本发明还可 以采用其他不同于在此描述的其他方式来实施， 因此， 本发明并不限于下面公开的具体实 施例的限制。 0029 在下文中出现的英文缩写的说明如下 ： 0030 消息中间件 ： 英文名称Message Oriented Middleware， 简称MOM， 是一种构建高效 可靠的数据传输平台的基础软件。 0031 数据库管理系统 ： 英语名称Da。
32、tabase Management System， 简称DBMS， 也是一种基 础软件， 主要功能是向上层应用提供数据的可靠存储和高效查询服务。 0032 事务 ： 是一系列操作的集合， 这些操作将作为一个整体参与到上层逻辑中 ( 事务 的原子性 ) ； 最终的结果只有两个， 要么所有操作全部生效， 要么全部失败。 0033 本地事务 ： 一般指在单个数据源上运行的事务。 0034 全局事务 ： 一般是跨数据源或者跨系统的事务。 0035 事务管理器 ： 一般是跨数据源的、 独立的事务管理系统。 其功能是维护跨数据源的 全局事务 ( 协调参与本事务的每一个数据源的本地事务 )， 并保证其分布式。
33、环境下的结果 一致性。 0036 首先结合图 1 中所示的实施例在整体上说明根据本发明的技术方案。 0037 如图1所示， 事务管理器102作为一种中间件系统， 通过事务管理接口可以向上层 应用 ( 应用层 ) 提供服务 ； 向下封装了 DBMS( 例如图中的数据库管理系统 104， 可以为 OLTP 数据源并作为第二数据源 )、 MOM( 例如图中的消息中间件 106， 作为第一数据源 ) 和其他的 EIS 所提供的服务 ( 位于企业信息系统层 )， 为事务管理器 102 提供统一的接口。 0038 事务管理器 102 的核心模块有以下三个构成 ： 说 明 书 CN 102306197 A 。
34、CN 102306204 A5/10 页 9 0039 全局事务标识管理 1022 ： 该模块主要负责维护全局事务标识。为保证唯一性， 将 全局事务标识信息持久化在了 DBMS 中， 并向其他模块提供统一的调用接口。 0040 消息处理单元 1024 ： 在多层模型中， 上层应用已经进化成为一个个服务并嵌入在 事务管理器或者其他的中间件系统中运行。消息处理单元 1024 封装了事务和 JMS 消息处 理的相关细节， 根据 JMS 规范 ( 详细请参见 JMS 规范 )， 应用只要实现相应的消息数据处理 逻辑即可， 这极大地简化了上层应用的难度。 0041 全局事务控制单元 1026 ： 该模块。
35、主要负责全局事务的管理， 并向外提供事务处理 的接口， 如创建、 提交、 回滚、 超时监控等。一个全局事务将包括两个分支 ： 一个分支用于处 理 MOM 的操作， 另一个分支用于处理 DBMS 的操作。对全局事务的管理 ( 包括对全局事务分 支的管理 ) 通过对全局事务的状态维护来实现。实际上， 全局事务的状态就是对消息进行 业务处理的状态， 为了保证全局操作的结果一致性， 在设计中全局事务的信息及状态也会 被持久化到 DBMS 系统中， 这样就可以将全局事务的状态操作和业务操作的事务进行绑定， 从而保证消息被不重不丢的处理。 0042 通过上面的描述可以看到实现的过程为 ： 从 MOM 接收。
36、一个消息并处理这个消息， 把对应这个消息数据的业务处理所需要的其他业务数据从 DBMS 里提取出来， 在业务逻辑 处理完成后将生成的结果存储到 DBMS 中去 ； 但如果加入可靠性要求在异常情况下也 能保证消息被不重不丢的处理， 这就需要事务管理器 102 通过全局事务来协调两个数据源 的本地事务， 以此来保证结果一致性。为了避免使用 XA 协议给带来的影响， 将使用双向状 态核对机制来控制全局事务的状态。 下面将以一个多模块协作的时序图来描述如何实现使 用双向状态核对来控制全局事务的状态 ： 0043 如图 2 所示， 1， 将建立消息处理单元 1024 与消息中间件 106、 数据库管理系。
37、统 104(第二数据源， 例如OLTP数据源)、 应用服务单元108的连接 ； 2， 从数据库管理系统中恢 复全局事务标识使用情况 ； 3， 从数据库管理系统中恢复未完成的事务。各个模块都初始化 (1、 2和3)完成后， 事务管理器102提供的消息处理单元1024将阻塞在MOM的消息队列上， 等待一个很新的消息请求到来， 这是触发一个完整的事务处理流程的前提 ( 见 4 和 5)。 0044 4， 消息处理单元1024请求打开一个消息中间件106的本地事务 ； 5， 根据业务需要 请求消息中间件从指定队列中接收到消息 ； 6， 返回给消息处理单元业务对应的消息 ； 7， 消 息处理单元 102。
38、4 一旦收到消息， 请求全局事务控制单元 1026 查看该消息是否已经注册对 应的事务 ； 8， 全局事务控制单元1026检查该消息是否已经注册对应的全局事务(已经被处 理过的消息) ； 9， 消息处理单元1024收到返回查看结果 ； 10， 如果发现是已经被处理过的事 务， 根据对应的事务的状态决定去完成这个事务， 如果是第一次处理这个消息， 则请求全局 事务控制单元1026创建一个全局事务 ； 11， 全局事务控制单元1026请求全局事务标识管理 单元1022给一个全局事务标识 ； 12， 全局事务标识管理单元1022分配一个全局事务标识给 全局事务控制单元 1026 ； 13， 创建全局。
39、事务， 将该全局事务的分支 (MOM 和 DBMS 的两个本地 事务 ) 初始化。14， 开始一个第二数据源 (DBMS， 数据库管理系统 ) 的本地事务 ； 15， 创建事 务过程结束和调用针对该消息的业务处理流程之前， 将全局事务的状态修改为正在进行业 务处理。 0045 16， 全局事务控制单元 1026 将创建的全局事务的标识传送至消息处理单元 1024 ； 17， 应用服务单元 108 调用业务处理逻辑处理接收到的消息 ； 18， 应用服务单元 108 在处理 说 明 书 CN 102306197 A CN 102306204 A6/10 页 10 时， 向第二数据源获取业务处理需要。
40、的业务数据 ； 19， 第二数据源返回应用服务单元 108 需 要的业务数据 ； 20， 处理消息数据 ； 21， 将处理结果返回至消息处理单元 ； 22， 消息处理单元 1024 接收到处理结果后， 发起提交全局事务的流程 ； 24， 将全局事务的状态修改为正在提 交状态， 并且将第二数据源装的本地事务的状态修改为已经提交， 消息中间件的本地事务 的状态修改为正在提交状态， 将这些状态信息持久化在第二数据源中 ； 25， 全局事务控制单 元 1026 命令提交第二数据源的本地事务 ； 26， 全局事务控制单元 1026 命令消息处理单元 1024 提交消息中间件的本地事务 ； 27， 消息处。
41、理单元 1024 接收到指令后， 提交消息中间件 的本地事务 ； 28， 消息中间件 106 返回提交成功的信息给消息处理单元 ； 29， 消息处理单元 1024 通知全局事务控制单元 1026 消息中间件 106 的本地事务已经提交成功 ； 30， 全局事务 控制单元 1026 接收到通知后， 修改消息中间件的本地事务状态为已经提交 ； 31， 修改全局 事务状态为已经提交， 并将这些状态信息持久化与第二数据源中 ； 32， 到此一个从收到消息 到处理的整个过程的全局事务就完成了， 最后释放全局事务的相关资源， 结束本次请求的 处理。 0046 在图 2 中只给出了消息数据处理成功后全局事务。
42、提交的流程， 考虑到如果消息数 据处理失败后全局事务的回滚流程和提交流程十分类似， 因此将不再给出全局事务回滚的 相互协作时序图。此外， 图 2 里给出的是正常的业务时序图， 真正实现过程中对任何的异常 /失败都要严格按照时序进行回滚处理， 这样才能保证其全局事务的结果一致性。 下面将详 细解释这种系统是如何保证在各种异常情况下操作结果的一致性的， 从时序图里可以看到 23 32 为全局事务的提交或回滚过程， 接下来就针对每一个步骤假设系统重新启动， 是如 何被恢复的。 0047 (1) 在 25 之前系统异常并重新启动 ： 0048 会发现对第二数据源执行的所有操作所在的事务， 因为系统重新。
43、启动而被回滚 掉， 因此， 第二数据源中将没有任何处理该消息所对应的事务的记录 ； 而该消息在消息中间 件中对应的本地事务也将回滚掉， 消息又重新回到了消息中间件的队列中 ； 系统恢复后这 个消息将再次被取出并进行处理 ( 和进行第一次处理的过程一样 )， 所以这种情况不会造 成任何的结果不一致。 0049 (2) 在 26 或 27 或 28 之前系统异常并重新启动 ： 0050 在消息中间件提交本地事务前系统异常并重新启动， 将导致消息中间件的本地事 务 (MOM 分支的本地事务 ) 回滚， 消息回到消息中间件的制定列队中， 按照第一次处理该消 息时的流程 ( 获取全局事务， 检查全局事务。
44、的状态到修改全局事务的状态 ) 重新处理该消 息对应的本地事务， 而此时 DBMS 分支的本地事务已经提交， 因此全局事务控制单元在初始 化时， 将把该 MOM 消息对应的全局事务恢复回来， 其全局事务的状态为正在提交， MOM 分支 的状态为正在提交， 而 DBMS 分支的状态为已经提交， 这表示针对这个消息数据所对应的业 务处理都已经成功处理结束， 接下来所要做的是直接从 MOM 中删除这个消息并释放全局事 务的相关资源就， 同样这种情况也不会造成任何结果不一致。 0051 (3) 在 29 或 30 之前系统异常并重新启动 ： 0052 虽然在DBMS中的全局事务的状态与上述情况一样， 。
45、但实际上MOM分支的本地事务 已经提交 ( 被处理的消息已经不存在 )， 只需按正常处理那样去删除这个消息， 然后释放全 局事务相应的资源， 这种情况也不会造成任何的结果不一致。 说 明 书 CN 102306197 A CN 102306204 A7/10 页 11 0053 (4) 在 31 之前系统异常并重新启动 ： 0054 重新启动后， 全局事务控制单元从 DBMS 中恢复事务后， 其全局事务状态为正在提 交， 而DBMS和MOM这两个分支的状态都是已经提交完成， 此时处理过程更加简单， 只需修改 全局事务状态为提交完成并释放全局事务的相关资源， 这种情况下也不会有任何结果不一 致。。
46、 0055 (5) 在 32 之前系统异常并重新启动 ： 0056 在此之前发生异常并重新启动系统， 全局事务控制单元从 DBMS 中恢复事务后， 发 现全局事务状态已经是提交完成， 只需释放全局事务相关的资源， 这种情况下也不会有任 何结果不一致。 0057 从上面的详细描述可以看出根据本发明的技术方案虽然没有使用 XA 协议， 但是 在任何情况都能保证全局事务所协调的 MOM 和 DBMS 这两个数据源上本地事务的一致性。 0058 下面结合图 3 说明全局事务的状态变化情况。 0059 如图 3 所示， 步骤 302， 全局事务的状态以初始状态开始， 若事务发起者主动回滚， 则进入步骤3。
47、12， 处于正在进行分支回滚状态。 步骤304， 在各个分支(例如消息中间件的本 地事务、 第二数据源的本地事务 ) 的业务处理阶段， 将各分支的状态设置为正在进行业务 处理状态， 全局事务的状态也为正在进行业务处理状态， 此时， 在全局事务中可以加入其他 的分支。若进行业务处理超时， 则进入步骤 312， 处于正在进行分支回滚状态。步骤 306， 所 有分支业务处理完成后修改全局事务的状态为业务处理完成状态， 这时不能在全局事务中 加入其他的分支， 若业务处理超时或失败， 则进入步骤 312， 然后进行步骤 314， 进入分支回 滚完成状态。步骤 308， 收到来自调用者的提交事务信息后， 。
48、全局事务的状态会被修改为正 在提交事务状态， 并触发各个分支的提交流程， 各分支状态为正在进行提交状态。 步骤310， 在此期间需要监视所有分支的状态， 直到各个分支都提交完成， 最后将全局事务状态修改 为全局事务提交完成状态， 这样就完成了一个全局事务的生命周期。在整个生命周期内任 何主动发起或者失败 ( 比如业务失败或者超时 ) 都可以触发全局事务的回滚流程。 0060 下面结合图 4 说明全局事务分支的状态变化情况。 0061 如图 4 所示， 是全局事务的一个分支 ( 消息中间件的本地事务或 OLTP 数据源的 本地事务 ) 的状态变化示意图， 步骤 402， 与全局事务一样， 分支的。
49、状态也是以初始状态开 始。 步骤404， 在调用真正的业务处理流程之前其状态会被修改为正在进行业务处理。 步骤 404， 直至业务处理处理完成， 分支的状态会被相应的修改， 修改为业务处理完成状态。 接下 来的状态需要等待全局事务的触发， 进行分支提交或者回滚流程。 判断是否处理成功， 如果 处理成功或全局事务发起者发起提交指令， 则进入步骤 408， 进入正在进行提交状态， 然后 进入步骤 410， 提交完成后， 将分支状态修改为提交完成状态。若判断处理失败或全局事务 发起者要求回滚， 则进入步骤 412， 进入分支正在进行回滚状态， 然后进入步骤 414， 进入分 支回滚完成状态， 在提交或者回滚完成后， 分支的生命周期结束。 0062 图 5 示出了根据本发明的实施例的保证跨数据源操作结果一致性的装置的框图。 0063 如图 5 所示， 根据本发明的实施例的保证跨数据源操作结果一致性的装置 500， 包 括 ： 消息处理单元 502， 请求打开消息中间件的本地事务， 接收来自所述消息中间件的指定 列队中的消息。