张瀚文的空间

我们一直在努力....

跨服务的事务机制

标签:

前一段时间社区里关于跨服务的事务问题,之前的思路是可以采用两段式的方案去处理事务。比如:
a和b两个服务间的事务,客户端调用a服务时,先预提交,然后调用b的事务,当b的事务返回正确,则第二次提交a事务。
问题出现了,web service本身提倡的就是无状态的数据交互,如果是采用两段式的事务管理,就必然有全局上下文环境,不然怎么知道最后一个提交的事务是哪个呢。这样就说明当前事务相关的几个组件间是紧密相关的,那这样的两个组件是否真的应该被分割开么?
如果不能整合事务相关的组件,那么就应该把事务管理器抽象出来,建立一套独立的中间层事务管理机制,我想说的就是这个中间层的实现机制。
首先,这个中间层的实质就是事务控制器,它本身必须是一个线程安全的。提供通过向这个事务控制器注册自己的两段式事务开启、提交和回退的web service接口。这里我猜测可以用类似跨服务会话管理的方式去管理分布式事务,建立一个会话事务池之类的东西,将要执行的服务暂时保存在服务器端,预提交成功后,再从会话事务池中第二次提交,如果失败就将该会话池中已经执行的服务或者全部服务回滚。然后,当有客户想启动分布事务时,就可以向这个事务控制器发起分布式事务请求,选择事务各方,启动一个分布式,最后向事务控制器,而非是各个事务方直接发起提交请求,这样事务控制的多态就可以在事务控制服务器中实现。
再说一下两阶段事务提交的具体实现,最近在看axis2,它支持会话间的异步调用服务。如果有a和b两个服务事务,那先预提交a,a如果成功,在服务端的回调方法中则同时挂起a事务提交b事务,等b成功后在服务端的回调方法中再永久提交a。如果b执行中出错,则在服务端的回调方法中a回滚,如果a执行后,b执行中网络断开,则在服务端的回调方法中整体事务超时回滚。
最后,提出一种其他的思路,解决这种事务问题,是不是可以将数据缓存和数据持久化看成是两段式的前后两部分,预提交时,记录对象的历史状态,同时将当前状态和历史状态写入数据缓存,当永久提交后,在从缓存中取出对象进行数据库的持久化,否则,回滚到之前的状态。

 


    评分: 请先登录再投票,同一篇博客一月只能投票一次!
    无人投票

评论


发表评论

最近访客
关注此文的人们还关注