Link to the original text of this article: http://blog.csdn.net/bluishglc/article/details/7612811 , please indicate the source for reprinting!
1.XA
XA is a specification for distributed transactions proposed by the X/Open organization. The XA specification mainly defines the interface between the (global) transaction manager (Transaction Manager) and the (local) resource manager (Resource Manager). The XA interface is a bidirectional system interface that forms a communication bridge between the Transaction Manager and one or more Resource Managers. The reason why XA needs to introduce a transaction manager is that in a distributed system, theoretically (refer to the paper by Fischer et al.), two machines cannot theoretically reach a consistent state, and a single point needs to be introduced for coordination. The transaction manager controls global transactions, manages the transaction lifecycle, and coordinates resources. The resource manager is responsible for controlling and managing the actual resources (such as databases or JMS queues). The following diagram illustrates the relationship between transaction managers, resource managers, and applications:
Figure 1. The relationship between various participants of distributed transactions under the XA specification
2.JTA
As a transaction specification on the Java platform, JTA (Java Transaction API) also defines support for XA transactions. In fact, JTA is modeled based on the XA architecture . In JTA, the transaction manager is abstracted as the javax.transaction.TransactionManager interface. And through the underlying transaction service (ie JTS). Like many other Java specifications, JTA only defines interfaces, and the specific implementation is provided by suppliers (such as J2EE manufacturers). Currently, the implementation of JTA mainly includes the following:
1. JTA implementation provided by J2EE container (JBoss)
2. Independent JTA implementation: such as JOTM, Atomikos. These implementations can be used in environments that do not use J2EE application servers to provide distributed transaction guarantees. Such as Tomcat, Jetty and ordinary java applications.
3. Two-phase commit
All introductions to distributed transactions will inevitably mention two-phase commit, because it is the key to implementing XA distributed transactions (to be precise: two-phase commit mainly guarantees the atomicity of distributed transactions: that is, all nodes or do all or none). The so-called two stages refer to: the first stage: the preparation stage and the second stage: the submission stage.
Figure 2. Two-phase commit diagram (from the article "Java Transaction Design Strategy" published by info)
1.准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。(关于每一个参与者在准备阶段具体做了什么目前我还没有参考到确切的资料，但是有一点非常确定：参与者在准备阶段完成了几乎所有正式提交的动作，有的材料上说是进行了“试探性的提交”，只保留了最后一步耗时非常短暂的正式提交操作给第二阶段执行。)
2.提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
将提交分成两阶段进行的目的很明确，就是尽可能晚地提交事务，让事务在提交前尽可能地完成所有能完成的工作，这样，最后的提交阶段将是一个耗时极短的微小操作，这种操作在一个分布式系统中失败的概率是非常小的，也就是所谓的“网络通讯危险期”非常的短暂，这是两阶段提交确保分布式事务原子性的关键所在。（唯一理论上两阶段提交出现问题的情况是当协调者发出提交指令后当机并出现磁盘故障等永久性错误，导致事务不可追踪和恢复）
从两阶段提交的工作方式来看，很显然，在提交事务的过程中需要在多个节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时，这样，比起一阶段提交，两阶段提交在执行同样的事务时会消耗更多时间。事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量达到一定数量的时候，就会出现大量事务积压甚至出现死锁，系统性能就会严重下滑。这就是使用XA事务
4.一阶段提交(Best Efforts 1PC模式)
不像两阶段提交那样复杂，一阶段提交非常直白，就是从应用程序向数据库发出提交请求到数据库完成提交或回滚之后将结果返回给应用程序的过程。一阶段提交不需要“协调者”角色，各结点之间不存在协调操作，因此其事务执行时间比两阶段提交要短，但是提交的“危险期”是每一个事务的实际提交时间，相比于两阶段提交，一阶段提交出现在“不一致”的概率就变大了。但是我们必须注意到：只有当基础设施出现问题的时候(如网络中断，当机等)，一阶段提交才可能会出现“不一致”的情况，相比它的性能优势，很多团队都会选择这一方案。关于在spring环境下如何实现一阶段提交,有一篇非常优秀的文章值得参考：http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html?page=5
5.事务补偿机制
像best efforts 1PC这种模式，前提是应用程序能获取所有的数据源，然后使用同一个事务管理器(这里指是的spring的事务管理器)管理事务。这种模式最典型的应用场景非数据库sharding莫属。但是对于那些基于web service/rpc/jms等构建的高度自治(autonomy)的分布式系统接口，best efforts 1PC模式是无能为力的，此类场景下，还有最后一种方法可以帮助我们实现“最终一致性”，那就是事务补偿机制。关于事务补偿机制是一个大话题，本文只简单提及，以后会作专门的研究和介绍。
6. How to choose between standard distributed transactions based on two-phase commit and Best Efforts 1PC
Generally speaking, the number of subsystems that need to interact is small, and the whole system will not or rarely introduce new subsystems in the future And the load remains stable for a long time, that is, if there is no scaling requirement, considering the development complexity and workload, you can choose to use distributed transactions. For systems with less stringent time requirements and high performance requirements, Best Efforts 1PC or transaction compensation mechanism should be considered. For those systems that need sharding transformation, distributed transactions should basically no longer be considered, because sharding opens a window for horizontal scaling of the database, and the use of distributed transactions seems to add another shackle to the newly opened window.
Supplement: The dangerous period
of network communication may occur at any time due to network communication failure, and any program that waits for a response after sending a request will be in danger of losing contact. This danger occurs after the request is sent and before the server returns the response. If the network communication fails during this period, the requesting party cannot receive the response, so it is impossible to judge whether the server has successfully processed the request, because the failure to receive the response may be a request It was not successfully sent to the server, or the response from the server after processing could not be sent back to the requester. This period is called the In-doubt Time of network communication. Obviously, the dangerous period of network communication is another reliability issue that needs to be considered in addition to single point reliability in distributed systems.
References:
1. Baidu Encyclopedia
2. http://en.wikipedia.org/wiki/Java_Transaction_API
3. http://www.nosqlnotes.net/archives/62#more-62
4. http://hi.baidu .com/javaopensource/blog/item/0a2b764ec501b10cb3de05ba.html