全局事务和本地事务

站在事务管理的角度，可以把Java中用到的事务分为本地事务和全局事务。

本地事务
不用事务的编程框架来管理事务，直接使用资源管理器来控制事务。典型的就是java.sql.Connection 中的setAutoCommit、commit、rollback方法。

本地事务的优点
支持严格的ACID属性
可靠
高效
状态可以只在资源管理器中维护
应用编程模型简单
本地事务的局限
不具备分布式事务处理能力
隔离的最小单位由资源管理器决定，如数据库中的一条记录
本地事务比较简单，对事务不太了解的同学可以阅读我的博客中其他关于事务的内容。

全局事务
前面我们介绍了本地事务，本地事务是我们在编程中比较常接触的事务，比如典型的jdbc操作，在保证ACID方面做的非常出色。但是本地事务无法解决分布式场景中的事务问题。
我前面的文章中专门介绍过分布式场景中为什么需要事务。这里我再稍微回顾一下。
典型的分布式事务场景
转账
对于银行账户间转账的问题。账户A向账户B转账，从实现上来看，一般可以拆分为“从账户A中扣钱”、“向账户B中加钱”两个操作步骤，两个账户大多数情况下会被切分到不同的数据库上，更多的是，两个操作会是两次服务调用。这两个操作要求做到要么同时成功、要么同时失败。因此引入了分布式事务问题。

全局事务怎么做呢？ 

JPA.getUserTransaction().begin();      首先要全局事务的API,不需要我们编写，通常容器已经提供给我们了，我们只需要begin一下 
connection = mysql 连接mysql 
connection2 = oracle 连接oracle 
connection--> update mysql_table set amount=amount-xx where id=aaa 发生扣钱,假设是在mysql数据库扣钱的。 
connection2--> update oracle_table set amount=amount+xx where id=bbb 发生在oracle数据库 
JPA.getUserTransaction().commit(); 

那么它是怎么知道事务该提交还是回滚呢？ 
这时候它使用了二次提交协议。二次提交协议简单说就这样：如果你先执行第一条语句，执行的结果先预提交到数据库，预提交到数据库了，数据库会执行这条语句，然后返回一个执行的结果，这个结果假如我们用布尔值表示的话，成功就是true，失败就是false.然后把执行的结果放入一个（假设是List）对象里面去，接下来再执行第二条语句，执行完第二条语句之后（也是预处理，数据库不会真正实现数据的提交，只是说这条语句送到数据库里面，它模拟下执行，给你返回个执行的结果），假如这两条语句的执行结果在List里面都是true的话，那么这个事务就认为语句是成功的，这时候全局事务就会提交。二次提交协议，数据库在第一次提交这个语句时，只会做预处理，不会发生真正的数据改变，当我们在全局事务提交的时候，这时候发生了第二次提交，那么第二次提交的时候才会真正的发生数据的改动。 

   如果说在执行这两条语句中，有一个出错了，那么List集合里就有个元素为false，那么全局事务就认为你这个事务是失败的，它就会进行回滚，回滚的时候，哪怕你的第二条语句在第一次提交的时候是成功的，它在第二次提交的时候也会回滚，那么第一次的更改也会恢复到之前的状态，这就是二次提交协议。（可以查看一下数据库方面的文档来了解二次提交协议）