我们在使用数据库时候，经常会碰到XA 和 Non-XA，但是你知道是什么吗？
[转]
An XA transaction, in the most general terms, is a “global transaction” that may span multiple resources. A non-XA transaction always involves just one resource.
An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).
XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.
Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you’ll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources. Your code can then update/delete/publish/whatever across the many resources. When you say “commit”, the results are commited across all of the resources. When you say “rollback”, everything is rolled back across all resources.
The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.
In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can’t participate in a global transaction (sort of - some people implement what’s called a “last participant” optimization that can let you do this for exactly one non-XA item).
For more details - see the JTA pages on java.sun.com. Look at the XAResource and Xid interfaces in JTA. See the X/Open XA Distributed Transaction specification. Do a google source on “Java JTA XA transaction”.
简单说就是XA transaction是全局事务，可同时涉及多个资源，如多个数据库甚至还有消息服务，可支持分布式事务。而Non-XA 是单一事务或者本地事务。
上面提到了分布式事务，我觉得有几个比较重要的理论顺便在这里也一并学习和了解一下。
CAP理论
指在一个分布式系统中，最多只能满足C、A、P中的两个需求。
- C：Consistency 一致性。同一数据的多个副本是否实时相同。
- A：Availability 可用性。一定时间内 & 系统返回一个明确的结果 则称为该系统可用。
- P：Partition tolerance 分区容错性。将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。
CAP理论告诉我们，在分布式系统中，C、A、P三个条件中我们最多只能选择两个。那么问题来了，究竟选择哪两个条件较为合适呢？
对于一个业务系统来说，可用性和分区容错性是必须要满足的两个条件，并且这两者是相辅相成的。业务系统之所以使用分布式系统，主要原因有两个：
-
提升整体性能
当业务量猛增，单个服务器已经无法满足我们的业务需求的时候，就需要使用分布式系统，使用多个节点提供相同的功能，从而整体上提升系统的性能，这就是使用分布式系统的第一个原因。
-
实现分区容错性
单一节点 或 多个节点处于相同的网络环境下，那么会存在一定的风险，万一该机房断电、该地区发生自然灾害，那么业务系统就全面瘫痪了。为了防止这一问题，采用分布式系统，将多个子系统分布在不同的地域、不同的机房中，从而保证系统高可用性。
这说明分区容错性是分布式系统的根本，如果分区容错性不能满足，那使用分布式系统将失去意义。
此外，可用性对业务系统也尤为重要。在大谈用户体验的今天，如果业务系统时常出现“系统异常”、响应时间过长等情况，这使得用户对系统的好感度大打折扣，在互联网行业竞争激烈的今天，相同领域的竞争者不甚枚举，系统的间歇性不可用会立马导致用户流向竞争对手。因此，我们只能通过牺牲一致性来换取系统的可用性和分区容错性。这也就是下面要介绍的BASE理论。
BASE理论
CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件。而对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”*并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性。下面来介绍下BASE理论。
-
BA：Basic Available 基本可用
整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。只不过“基本可用”和“高可用”的区别是：
-
“一定时间”可以适当延长
当举行大促时，响应时间可以适当延长
-
给部分用户返回一个降级页面
给部分用户直接返回一个降级页面，从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。
-
-
S：Soft State：柔性状态
同一数据的不同副本的状态，可以不需要实时一致。
-
E：Eventual Consistency：最终一致性
同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。
还有与分布式事务相关的 两阶段提交协议 （Tow Phase Commit, 2PC）, 三阶段提交协议 (Three Phase Commit, 3PC)可以参考下面的资料，都讲的比较详细。
[参考]