本文目录
- @transactional怎么解析
- 分布式事务能用@transactional吗
- Spring Boot中Service用@Transactional 注解在方法上，只在最外层方法起作用吗
- Spring 事务管理问题
- 把transactional注解标到private方法上会怎样
@transactional怎么解析
@Transactional采用注解式事务，所有标记为这个注解的并且能被spring扫描到的方法都会根据@Transactional的配置来使用事务，一般事务放在一个单元操作中，比如同时保存两个表，那么需要对这一个操作开启事务，要么都成功，一个失败的话事务回滚。也就是说不一定放在Dao层，
分布式事务能用@transactional吗
1. 在需要事务管理的地方加@Transactional 注解。@Transactional 注解可以被应用于接口定义和接口方法、类定义和类的 public 方法上。
2. @Transactional 注解只能应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错， 但是这个被注解的方法将不会展示已配置的事务设置。
3. 注意仅仅 @Transactional 注解的出现不足于开启事务行为，它仅仅 是一种元数据。必须在配置文件中使用配置元素，才真正开启了事务行为。
4. 通过 元素的 “proxy-target-class“ 属性值来控制是基于接口的还是基于类的代理被创建。如果 “proxy-target-class“ 属值被设置为 “true“，那么基于类的代理将起作用（这时需要CGLIB库cglib.jar在CLASSPATH中）。如果 “proxy-target-class“ 属值被设置为 “false“ 或者这个属性被省略，那么标准的JDK基于接口的代理将起作用。
标准的JDK基于接口的代理将起作用--》
proxy-target-class=“false“/》
基于类的代理将起作用 ,同时 cglib.jar必须在CLASSPATH中
proxy-target-class=“true“/》
--》
非JTA事务（即非分布式事务）， 事务配置的时候 ，需要指定dataSource属性（非分布式事务，事务是在数据库创建的链接上开启。）--》
JTA事务（非分布式事务）， 事务配置的时候 ，不能指定dataSource属性（分布式事务，是有全局事务来管理数据库链接的）--》
注解@Transactional cglib与java动态代理最大区别是代理目标对象不用实现接口,那么注解要是写到接口方法上，要是使用cglib代理，这是注解事物就失效了，为了保持兼容注解最好都写到实现类方法上。
5. Spring团队建议在具体的类（或类的方法）上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。在接口上使用 @Transactional 注解，只能当你设置了基于接口的代理时它才生效。因为注解是 不能继承 的，这就意味着如果正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装。
6. @Transactional 的事务开启 ，或者是基于接口的 或者是基于类的代理被创建。所以在同一个类中一个方法调用另一个方法有事务的方法，事务是不会起作用的。
public interface PersonService {
//删除指定id的person
public void delete(Integer personid) ;
//删除指定id的person,flag
public void delete(Integer personid,boolean flag) ;
}
public class PersonServiceBean implements PersonService {
private JdbcTemplate jdbcTemplate;
public void delete(Integer personid){
try{
this.delete(personid,true)
System.out.println(“delete success“);
}catch(Exception e){
System.out.println(“delete failed“);
}
}
@Transactional
//此时，事务根本就没有开启, 即数据库会默认提交该操作，即记录别删除掉 public void delete(Integer personid,boolean flag){
if(flag == ture){
jdbcTemplate.update(“delete from person where id=?“, new Object{personid},
new int{java.sql.Types.INTEGER});
throw new RuntimeException(“运行期例外“);
}
}
}
public class PersonServiceBeanTest{
PersonService ps = new PersonServiceBean ();
ps.delete(5);
}
7. Spring使用声明式事务处理，默认情况下，如果被注解的数据库操作方法中发生了unchecked异常，所有的数据库操作将rollback；如果发生的异常是checked异常，默认情况下数据库操作还是会提交的。
-----------------------------------------------------------------------------------------------------------------------------------------------
public interface PersonService {
//删除指定id的person
public void delete(Integer personid) ;
//获取person
public Person getPerson(Integer personid);
}
//PersonServiceBean 实现了PersonService 接口，则基于接口的还是基于类的代理 都可以实现事务
@Transactional public class PersonServiceBean implements PersonService {
private JdbcTemplate jdbcTemplate;
//发生了unchecked异常,事务回滚, @Transactional
public void delete(Integer personid){
jdbcTemplate.update(“delete from person where id=?“, new Object{personid},
new int{java.sql.Types.INTEGER});
throw new RuntimeException(“运行期例外“);
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------
public interface PersonService {
//删除指定id的person
public void delete(Integer personid) throws Exception;
//获取person
public Person getPerson(Integer personid);
}
@Transactional
public class PersonServiceBean implements PersonService {
//发生了checked异常,事务不回滚,即数据库记录仍能被删除，
//checked的例外，需要我们在外部用try/catch语法对调用该方法的地方进行包含 @Transactional
public void delete(Integer personid) throws Exception{
jdbcTemplate.update(“delete from person where id=?“, new Object{personid},
new int{java.sql.Types.INTEGER});
throw new Exception(“运行期例外“);
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------
但是，对于checked这种例外，默认情况下它是不会进行事务回滚的，但是如果我们需要它进行事务回滚，这时候可以在delete方法上通过@Transaction这个注解来修改它的行为。
@Transactional
public class PersonServiceBean implements PersonService {
@Transactional(rollbackFor=Exception.class)
//rollbackFor这属性指定了，既使你出现了checked这种例外，那么它也会对事务进行回滚
public void delete(Integer personid) throws Exception{
jdbcTemplate.update(“delete from person where id=?“, new Object{personid},
new int{java.sql.Types.INTEGER});
throw new Exception(“运行期例外“);
}
}
---------------------------------------------------------------------------------------------------------------------------------------------------
在PersonServiceBean这个业务bean里面，有一些事务是不需要事务管理的，好比说获取数据的getPersons方法，getPerson方法。因为@Transactional 放在了类的上面。
此时，可以采用propagation这个事务属性@Transactional(propagation=Propagation.NOT_SUPPORTED)，propagation这个属性指定了事务传播行为，我们可以指定它不支持事务，当我们这么写了之后，Spring容器在getPersons方法执行前就不会开启事务.
@Transactional
public class PersonServiceBean implements PersonService {
@Transactional(propagation=Propagation.NOT_SUPPORTED)
//则此方法 就不会开启事务了
public Person getPerson(Integer personid)
{
}
}
Spring Boot中Service用@Transactional 注解在方法上，只在最外层方法起作用吗
一般来说function2和function1用的是同一个Transaction。
这个取决于@Transactional 的 propagation设置（事务的传播性）
默认的是
@Transactional(propagation=propagation.REQUIRED)
也就是使用同一个Transaction。也可以按需求设置成 NESTED 或者 REQUIRES_NEW。
//in A.java
Class A {
@Transactional(propagation=propagation.REQUIRED)
public void aMethod {
B b = new B();
b.bMethod();
}
}
//in B.java
Class B {
@Transactional(propagation=propagation.REQUIRED)
public void bMethod { //something }
}在上面这个例子中，传播性被设为了REQUIRED，注意，这是默认值，也即不进行该参数配置等于配置成REQUIRED。
REQUIRED的含义是，支持当前已经存在的事务，如果还没有事务，就创建一个新事务。在上面这个例子中，假设调用aMethod前不存在任何事
务，那么执行aMethod时会自动开启一个事务，而由aMethod调用bMethod时，由于事务已经存在，因此会使用已经存在的事务（也就是执行
aMethod之前创建的那个事务）。
对于这样的配置，如果bMethod过程中发生异常需要回滚，那么aMethod中所进行的所有数据库操作也将同时被回滚，因为这两个方法使用了同一个事务。
MANDATORY的含义是，支持当前已经存在的事务，如果还没有事务，就抛出一个异常。如果上例中aMethod的传播性配置为
MANDATORY，我们就无法在没有事务的情况下调用aMethod，因此，传播性为MANDATORY的方法必定是一个其他事务的子事务，当逻辑上独
立存在没有意义或者可能违反数据、事务完整性的时候，就可以考虑设置这样的传播性设置。
NESTED的含义是，在当前事务中创建一个嵌套事务，如果还没有事务，那么就简单地创建一个新事务。
REQUIRES_NEW的含义是，挂起当前事务，创建一个新事务，如果还没有事务，就简单地创建一个新事务。
请注意以上两者的区别，大多数情况下一上两种传播性行为是类似的，不过在事务回滚的问题上，以上两者有很大的区别。
首先，REQUIRES_NEW会创建一个与原事务无关的新事务，尽管是由一个事务调用了另一个事务，但却没有父子关系。
如果bMethod的传播性是REQUIRES_NEW，而抛出了一个异常，则bMethod一定会被回滚，而如果aMethod捕获并处理了这个
bMethod抛出的异常，那么aMethod仍有可能成功提交。当然，如果aMethod没有处理这个异常，那么aMethod也会被回滚。
如果aMethod在bMethod完成后出现了异常，那么bMethod已经提交而无法回滚，只有aMethod被回滚了。
而对于NESTED，虽然也会创建一个新事务，但是这个事务与调用者是有父子关系的相互依存的。
如果bMethod的传播性是NESTED，而抛出了一个异常，事务的回滚行为与REQUIRES_NEW是一致的。
但是如果aMethod在bMethod完成后出现了异常，bMethod同样也会被回滚。因为事实上，EJB中没有对于NESTED传播性的类似实现，NESTED并不是真正启动了一个事务，而是开启了一个新的savepoint。
NEVER的含义很简单，就是强制要求不在事务中运行，如果当前存在一个事务，则抛出异常，因此如果bMethod传播性是NEVER，则一定抛出异常。
NOT_SUPPORTED的含义是，强制不在事务中运行，如果当前存在一个事务，则挂起该事务。
SUPPORTS的含义是，支持当前事务，如果没有事务那么就不在事务中运行。SUPPORTS传播性的逻辑含义比较模糊，因此一般是不推荐使用的。
Spring 事务管理问题
你说的在某个方法F上开启session，
1、如果F实现复杂功能，需要对多个不同数据库实例进行操作（跨库），从Java层框架的角度，这个session是一个逻辑上的事务，管理所有涉及的数据库实例的连接（一般使用连接池管理），成功则所有涉及的数据库实例的操作统一提交，失败则统一回滚。
2、如果F实现功能，只涉及对某个数据库进行操作，同上。
对于“在service层方法执行前已打开session，开启了事务。那再执行service层方法时又再次打开session，这应该不是同一个session，这不就矛盾了了，事务怎么添加到service层方法上来的呢？
”：不同Spring注解，功能是不一样的。如果你在F上加@Transactional(propagation = Propagation.REQUIRES_NEW)，则前后肯定不处于同一个session上下文环境下。如果注解是@Transactional(propagation = Propagation.REQUIRED），则前后是处于同一个session上下文环境下。Spring会根据注解进行处理，表现为事务的传播特性，技术上通过AOP+代理+线程变量实现。对于开发者，一般只需要知道注解的用法以及注意事项即可。技术实现上，有兴趣可以下载源码查看或买本大牛的书籍学习。
把transactional注解标到private方法上会怎样
spring 的aop是基于 jdk 动态代理和CGLIB代理实现的，如果把transactional 注解标注到protected、private，这将会被忽略，不会产生代理，虽然ide 不会报错，但是方法中的操作是不受控制的
