这个月产品上发生一个问题，就是由于datasource的transaction设置从non-xa的llr改为了模拟两阶段提交，导致更新db不能保证在发送message之前，使application在比较状态是否一致的时候出错，所以我对相关知识进行了学习。
首先，先明确几个概念:
Transaction manager(TM) vs Resource manager(RM)
rm是资源管理器，这里所提到的资源主要包括db connection，jdo persistence，ems queue/topic等。tm是管理全局事务的，宏观控制rm的处理，xa就是在这个部分实现的。
Globel transaction vs Local transaction
local transaction就是我们平常提到的事务，用于提交一个rm的资源，保证资源提交的一致性。改globel transaction主要用于对不同rm的资源进行事务控制。比如不同的datasource更新操作，或者是datasource更新和发送jms message。
XA vs non-XA
xa和非xa的区别在于，xa可以保证全局事务处理的一致性，所有资源要不一起成功，要不一起失败。非xa则对某个资源进行单独处理，非xa的策略包括Logging last resource(LLR),One Phase commit(1PC),Emulate two phase commit。注意xa只有使用于多个rm要在一起管理的时候，如果每次执行只涉及到单个资源，或者设计多个资源但是对db执行select操作，不必使用xa。因为xa本身对性能有一定的影响。
下面具体介绍一下xa和非xa的策略
xa我所涉及的配置只包括两阶段提交，虽然网上有比如三阶段提交能够对其进行优化，但是就我参看的官方文档，还是以两阶段提交为主。所谓的两阶段提交包括准备阶段和执行阶段。在准备阶段tm告知所有rm进行准备，预执行sql，记录redo和undo日志，为之后执行或回滚做准备。然后返回执行状态。tm等待所有rm的状态返回后，如果所有状态都是成功的，则让所有rm进行提交，待所有rm返回执行完毕信息后，然后释放资源。如果存在失败的情况，则让所有rm通过之前记录的log进行回滚，返回成功信息后，tm释放资源。
这里插一句，之前我一直不理解为什么每个datasource都要配xa或非xa的配置，最后Server采用哪种呢?但是后来发现，weblogic上面的transaction配置是是否支持xa。如果不支持的话所才用的策略是什么，这条策略适用于单个datasource，而全局事务还是由xa进行控制。
上面提到过，非xa有三种策略，下面分别进行简单介绍:
单阶段提交:顾名思义就是只提交并执行一次。不受全局事务和tm管理，执行失败并不会影响其他资源的处理。
模拟两阶段提交:与单阶段提交不同，模拟两阶段提交会返回执行成功的信息，但是可能存在启发性错误，比如事务自己进行了回滚，可能会造成db状态与预计状态不同，所以并不能保证rm执行的一致性。
前两种方式存在的问题是，首先不能保证全局事务执行的原子性。另外其他xa控制的rm和非xa控制的rm是隔离开的，所以并不能保证哪些rm先执行更新，而llr可以保证。这一部分内容我们放在下一篇文章进行介绍。
