Spring @Transactional transaction mechanism
Several concepts should be clear: transaction propagation mechanism, transaction boundary
working principle
When running a test class configured with @Transactional annotation, the following steps will occur.
1) At the beginning of the transaction, through the AOP mechanism, a proxy connection object is generated and placed in a certain container related to the DataSourceTransactionManager of the DataSource instance. In the entire next transaction, the client code should use this connection to connect to the database and execute all database commands [database commands executed without using this connection to connect to the database will not be rolled back when the transaction is rolled back]
2) At the end of the transaction, roll back the database command executed on the proxy connection object obtained in step 1, and then close the proxy connection object
Cases where @Transactional does not take effect
- @Transactional does not take effect in private methods
- In the same bean, the nested public method @Transactional does not take effect
Solution
Simple and rude, you can open @Transactional when you need to call the service. If it doesn't work, like there are calls to third-party resources, you can consider creating another service to open @Transactional if you don't want the transaction to open for too long.
So how does @Transactional work?
The persistence context proxy that implements the EntityManager interface is not the only part of declarative transaction management, but actually consists of three components:
1. EntityManager Proxy itself
2. Aspects of the transaction
3. Transaction Manager
Aspects of business
The transaction aspect is an "around" aspect that can be called both before and after the annotated business method. The concrete class that implements the aspect is TransactionInterceptor.
Aspects of a transaction have two main responsibilities:
1. At 'before', the aspect provides a call site to decide whether the called business method should run within the scope of the ongoing transaction, or start a new independent transaction.
2. At 'after', the aspect needs to determine whether the transaction is committed, rolled back, or continues to run.
3. 在’before’时，事务切面自身不包含任何决策逻辑，是否开始新事务的决策委派给事务管理器完成。
事务管理器
事务管理器需要解决下面两个问题：
新的Entity Manager是否应该被创建？
是否应该开始新的事务？
这些需要事务切面’before’逻辑被调用时决定。事务管理器的决策基于以下两点：
1. 事务是否正在进行
2. 事务方法的propagation属性（比如REQUIRES_NEW总要开始新事务）
如果事务管理器确定要创建新事务，那么将：
1. 创建一个新的entity manager
2. entity manager绑定到当前线程
3. 从数据库连接池中获取连接
4. 将连接绑定到当前线程
特点：
1. 使用ThreadLocal变量将entity manager和数据库连接都绑定到当前线程。
2. 事务运行时他们存储在线程中，当它们不再被使用时，事务管理器决定是否将他们清除。
3. 程序的任何部分如果需要当前的entity manager和数据库连接都可以从线程中获取。
EntityManager proxy
EntityManager proxy(前面已经介绍过)就是谜题的最后一部分。当业务方法调用entityManager.persist()时，这不是由entity manager直接调用的。
而是业务方法调用代理，代理从线程获取当前的entity manager，前面介绍过事务管理器将entity manager绑定到线程。
了解了@Transactional机制的各个部分，我们来看一下实现它的常用Spring配置。
根据上面所述，我们所使用的客户代码应该具有如下能力：
1)每次执行数据库命令的时候
如果在事务的上下文环境中，那么不直接创建新的connection对象，而是尝试从DataSource实例的某个与DataSourceTransactionManager相关的某处容器中获取connection对象；在非事务的上下文环境中，直接创建新的connection对象
2)每次执行完数据库命令的时候
如果在事务的上下文环境中，那么不直接关闭connection对象，因为在整个事务中都需要使用该connection对象，而只是释放本次数据库命令对该connection对象的持有；在非事务的上下文环境中，直接关闭该connection对象
在service类前加上@Transactional，声明这个service所有方法需要事务管理。每一个业务方法开始时都会打开一个事务。
Spring默认情况下会对运行期例外(RunTimeException)进行事务回滚。这个例外是unchecked
如果遇到checked意外就不回滚。
如何改变默认规则：
1 让checked例外也回滚：在整个方法前加上 @Transactional(rollbackFor=Exception.class)
2 让unchecked例外不回滚： @Transactional(notRollbackFor=RunTimeException.class)
3 不需要事务管理的(只查询的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED)
4 如果不添加rollbackFor等属性，Spring碰到Unchecked Exceptions都会回滚，不仅是RuntimeException，也包括Error。
注意：
如果异常被try｛｝catch｛｝了，事务就不回滚了，如果想让事务回滚必须再往外抛try｛｝catch｛throw Exception｝。
@Transaction的属性
@Transactional之value
value这里主要用来指定不同的事务管理器；主要用来满足在同一个系统中，存在不同的事务管理器。比如在Spring中，声明了两种事务管理器txManager1, txManager2。
然后，用户可以根据这个参数来根据需要指定特定的txManager。
什么情况下使用？
比如在一个系统中，需要访问多个数据源或者多个数据库，则必然会配置多个事务管理器的。
@Transactional之propagation
Propagation支持7种不同的传播机制：
REQUIRED
业务方法需要在一个事务中运行,如果方法运行时,已处在一个事务中,那么就加入该事务,否则自己创建一个新的事务.这是spring默认的传播行为.。
SUPPORTS
如果业务方法在某个事务范围内被调用,则方法成为该事务的一部分,如果业务方法在事务范围外被调用,则方法在没有事务的环境下执行。
MANDATORY
只能在一个已存在事务中执行,业务方法不能发起自己的事务,如果业务方法在没有事务的环境下调用,就抛异常
REQUIRES_NEW
业务方法总是会为自己发起一个新的事务,如果方法已运行在一个事务中,则原有事务被挂起,新的事务被创建,直到方法结束,新事务才结束,原先的事务才会恢复执行.
NOT_SUPPORTED
声明方法需要事务,如果方法没有关联到一个事务,容器不会为它开启事务.如果方法在一个事务中被调用,该事务会被挂起,在方法调用结束后,原先的事务便会恢复执行.
NEVER
声明方法绝对不能在事务范围内执行,如果方法在某个事务范围内执行,容器就抛异常.只有没关联到事务,才正常执行.
NESTED
如果一个活动的事务存在,则运行在一个嵌套的事务中.如果没有活动的事务,则按REQUIRED属性执行.它使用了一个单独的事务, 这个事务拥有多个可以回滚的保证点.内部事务回滚不会对外部事务造成影响, 它只对DataSourceTransactionManager 事务管理器起效.
@Transactional之isolation
隔离级别所要解决的问题是在应用程序中，存在多个事务同时在运行之时，需要解决和处理好的问题。那首先来看看，一般会出现哪些问题呢？先来看看吧。
脏读（dirty read)
一个事物更新了数据库中的某些数据，另一个事物读取了这些数据，这时前一个事物由于某些原因回滚了，那么第二个事物读取的数据就是“脏数据”
不可重复读（non-repeatable read)
一个事物需要两次查询同一数据，但两次查询中间可能有另外一个事物更改了这个数据，导致前一个事物两次读出的数据不一致。
幻读 （phantom read)
一个事物两次查询同一个表，但两次查询中间可能有另外一个事物又向这个表中插入了一些新数据，导致前一个事物的两次查询不一致
@Transactional中Isolation有具备的值
- DEFAULT 使用各个数据库默认的隔离级别
- Read Uncommited :读未提交数据( 会出现脏读,不可重复读,幻读 )
- Read Commited :读已提交的数据(会出现不可重复读,幻读)
- Repeatable Read :可重复读(会出现幻读)
- Serializable :串行化
其与事务中容易出现的问题对应关系具体如下
具体如何来设置具体的隔离界别，则依据业务系统具体可以容忍的程度而定。Serializable最为严格，然而效率最低；Read Uncommited效率最高，但是容易出现各种问题，中间的2个级别介于二者之间，故本质上是效率与出错概率的平衡与妥协。
@Transactional之timeout
用于设置事务处理的时间长度，阻止可能出现的长时间的阻塞系统或者占用系统资源。单位为秒。如果超时设置事务回滚，并抛出TransactionTimedOutException异常。
spring事务超时 = 事务开始时到最后一个Statement创建时时间 + 最后一个Statement的执行时超时时间（即其queryTimeout）。
关于事务超时时间的计算可以参考：http://jinnianshilongnian.iteye.com/blog/1986023
@Transactional之readOnly
默认情况下是false，可以显示指定为true， 告诉程序该方法下使用的是只读操作，如果进行其他非读操作，则会跑出异常；这个紧紧适用于只有readOnly标识的情况下，当其与propagation机制同时使用之时，则会出现只读设置被覆盖的情况，比如在required的情况下。在使用 REQUIRED 传播模式时，会抛出一个只读连接异常。使用 JDBC 时是这样。使用基于 ORM 的框架时，只读标志只是对数据库的一个提示，并且一条基于 ORM 框架的指令（本例中是 hibernate）将对象缓存的 flush 模式设置为 NEVER，表示在这个工作单元中，该对象缓存不应与数据库同步。不过，REQUIRED 传播模式会覆盖所有这些内容，允许事务启动并工作，就好像没有设置只读标志一样。
具体的详细内容可以参考： http://robinsoncrusoe.iteye.com/blog/825531
@Transactional之rollbackForClassName/rollbackFor
Spring默认情况下会对运行期例外(RunTimeException)进行事务回滚。这个例外是unchecked，如果遇到checked意外就不回滚。
用来指明回滚的条件是哪些异常类或者异常类名。用法比较简单，这些不再赘述。
@Transactional之noRollbackForClassName/noRollbackFor
作用雷同于8， 用来指明在抛出特定异常的情况下，不进行数据库的事务回滚操作。
参考：
http://www.importnew.com/12300.html