XA规范

X/Open组织定义了分布式事务处理模型。X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。事务管理器（TM）是交易中间件，资源管理器（RM）是数据库、通信资源管理器（CRM）是消息中间件。通常把一个数据库内部的事务处理看作本地事务，而分布式事务处理的对象是全局事务。全局事务是指在分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作就是一个全局事务。在一个事务中可能更新几个不同的数据库，此时一个数据库对自己内部所做操作的提交不仅需要本身的操作成功，还需要全局事务相关的其他数据库的操作成功。如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束、提交、回滚等，XA接口函数由数据库厂商提供，根据这一思想衍生出二阶段提交协议和三阶段提交协议。

二阶段提交

所谓的两个阶段是指准备阶段和提交阶段。准备阶段是指事务协调者（事务管理器）向每个参与者（资源管理器）发送准备消息，每个参与者要么直接返回失败信息（如权限验证失败），要么在本地执行事务，写本地的redo和undo日志但不提交，可以进一步将准备阶段分为以下三步。

（1）协调者节点向所有参与者节点询问是否可以执行提交操作（vote），并开始等待各参与者节点的响应。

（2）参与者节点执行询问发起为止的所有事务操作，并将undo信息和redo信息写入日志。

（3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个“同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个“中止”消息。

提交阶段指如果协调者收到了参与者的失败消息或者超时，则直接向每个参与者发送回滚（Rollback）消息，否则发送提交（commit）消息，参与者根据协调者的指令执行提交或者回滚操作，释放所有事务在处理过程中使用的锁资源。

二阶段提交所存在的缺点如下：

（1）同步阻塞问题，在执行过程中所有参与节点都是事务阻塞型的，当参与者占用公共资源时，其他第三方节点访问公共资源时不得不处于阻塞状态。

（2）单点故障，由于协调者的重要性，一旦协调者发生故障，则参与者会一直阻塞下去

（3）数据不一致，在二阶段提交的第2阶段中，当协调者向参与者发送commit请求之后发生了局部网络异常或者在发送commit请求的过程中协调者发生了故障，则会导致只有一部分参与者接收到了commit请求，而在这部分参与者在接收到commit请求之后就会执行commit操作，其他部分未接收到commit请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致的现象。

由于二阶段提交存在诸如同步阻塞、单点问题、数据不一致、宕机等缺陷，所以，研究者们在二阶段提交的基础上做了改进，提出了三阶段提交。

三阶段提交

三阶段提交（Three-phase commit，3PC），把二阶段提交的准备阶段再次一分为二，这三样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

（1）CanCommit阶段：三阶段提交的CanCommit阶段其实和二阶段提交的准备阶段很像，协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

（2）PreCommit节点：协调者根据参与者的反应情况来决定是否可以记录事务的PreCOmmit操作。根据相相应情况，有以下两种可能。

假如协调者从所有参与者那里获得的反馈都是Yes响应，则执行事务。

假如在任何一个参与者向协调者发送了No响应，或者等待超时之后协调者都没有接到参与者的响应，则执行事务的中断。

（3）DoCommit阶段：该阶段进行真正的事务提交，也可以分为执行提交、中断事务两种执行情况。

执行提交的过程如下：

协调者接收到参与者发送的ACK响应后，将从预提交状态进入提交状态，并向所有参与者发送doCommit请求。

事务提交参与者接收到doCommit请求之后，执行正式的事务提交，并在完成事务提交之后释放所有的事务资源。

事务提交完之后，向协调者发送ACK响应。

协调者接收到所有参与者的ACK响应之后，完成事务。

中断事务的过程如下：

协调者向所有参与者发送abort请求。

参与者接收到abort请求之后，利用其它第2个阶段记录的undo信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

参与者完成事务回滚之后，向协调者发送ACK消息。

协调者接收到参与者反馈的ACK消息之后，执行事务的中断。

Spring事务隔离级别

1、ISOLATION_DEFAULT：默认的隔离级别

2、ISOLATION_READ_UNCOMMITTED：这是事务最低的隔离级别，它允许另外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻读

3、ISOLATION_READ_COMMITTED：保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻读。

4、ISOLATION_REPEATABLE_READ：这种事务隔离级别可以防止脏读，不可重复读，但可能出现幻读。

5、ISOLATION_SERIALIZABLE：花费最高代价但最可靠的事务隔离级别。事务被处理为顺序执行。

备注：

脏读：修改且未提交引起的。事务A把张三的工资由5000改为8000，但事务A尚未提交。与此同时，事务B读取到张三的工资为8000，随后，事务A发生了异常，回滚了事务。此时张三的工资又回滚为5000，那么事务B读取到张三的工资为8000的数据即为脏数据，事务B做了一次脏读。

不可重复读：修改引起的。事务A读取到张三的工资为5000，操作没有完成，事务还没提交。与此同时，事务B把张三的工资改为8000，并提交了事务。随后在事务A中，再次读取张三的工资，此时工资变为8000，在一个事务中前后两次读取的结果并不一致，导致了不可重复读。大部分数据库缺省的事务隔离级别都不会出现这种状况。

幻读：添加新纪录引起。事务A读取所有工资为5000的人数为10人，此时，事务B插入一条工资也为5000的记录。当事务A再次读取工资为5000的员工人数时为11人。此时产生了幻读。大部分数据库缺省的事务隔离级别都会出现这种情况，此种事务隔离级别将带来表级锁。

Spring事务的传播行为

所谓事务传播行为，就是多个事务方法相互调用时，事务如何在这些方法间传播。Spring支持以下7种事务传播行为

下面三种保证同一事务中

PROPAGATION_REQUIRED：支持当前事务，如果不存在就新建一个（默认）

@Transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)

PEOPAGATION_SUPPORTS：支持当前事务，如果不存在，就不使用事务，以非事务方式执行

@Transactional(propagation=Propagation.SUPPORTS, rollbackFor=Exception.class)

PROPAGATION_MANDATORY：支持当前事务，如果不存在，抛出异常

@Transactional(propagation=Propagation.MANDATORY, rollbackFor=Exception.class)

下面四种保证没有在同一事务中

PROPAGATION_REQUIRES_NEW：如果有事务存在，挂起当前事务，创建一个新的事务

@Transational(propagation=Propagation.REQUIRES_NEW, rollbackFor=Exception.class)

PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果有事务存在，挂起当前事务

@Transational(propagation=Propagation.NOT_SUPPORTED, rollbackFor=Exception.class)

PROPAGATION_NEVER：以非事务方式运行，如果有事务存在，抛出异常

@Transational(propagation=Propagation.NEVER, rollbackFor=Exception.class)

PROPAGATION_NESTED：如果当前事务存在，则嵌套事务运行；如果当前没有事务，则执行与REQUIRED类似的操作。

@Transational(propagation=Propagation.NESTED, rollbackFor=Exception.class)