TCC型事务

      TCC属于补偿型柔性事务，本质也是一个两阶段型事务，这与JTA是极为相似的，但是与JTA的不同点是，JTA属于资源层事务，而TCC是服务层事务。  

      在一个长事务（ long-running ）中 ，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。

      WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。          

     在JTA事务中，所有需要被事务管理的资源（由不同厂商实现）都必须实现规定接口（比如XAResource中的commit和rollback等），同理，所有需要加入TCC事务的服务也必须提供相应的接口实现，在TCC中这些接口为：try、confirm、cancel（缩写为TCC）。TCC事务管理器会使用try、confirm、cancel接口协调多个服务进行事务处理，如下图所示：

                

           Try: 尝试执行业务

                 • 完成所有业务检查(一致性)

                 • 预留必须业务资源(准隔离性)          

            Confirm:确认执行业务

                 • 真正执行业务

                 • 不作任何业务检查

                 • 只使用Try阶段预留的业务资源 

                 • Confirm操作要满足幂等性

            Cancel: 取消执行业务

                 • 释放Try阶段预留的业务资源 

                 • Cancel操作要满足幂等性

            

            TCC与2PC协议比较：

                 • 位于业务服务层而非资源层

                 • 没有单独的准备(Prepare)阶段， Try操作兼备资源操作与准备能力 

                 • Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度) 

                 • 较高开发成本