记录下用@Transational遇到的坑

(1)用@Transactional注解可以声明在类上，也可以声明在方法上。在大多数情况下，方法上的事务会首先执行。为了避免长事务，推荐用在方法上。

(2)只用@Transactional时任何 RuntimeException 将触发事务回滚，但是任何 checked Exception 将不触发事务回滚，所以推荐使用@Transactional(rollbackFor = Exception.class)，这样所有异常都会回滚

(3) @Transactional注解，是使用 AOP 实现的，本质就是在目标方法执行前后进行拦截。 在目标方法执行前加入或创建一个事务，在执行方法执行后，根据实际情况选择提交或是回滚事务。当 Spring 遇到该注解时，会自动从数据库连接池中获取 connection，并开启事务然后绑定到 ThreadLocal 上，对于@Transactional注解包裹的整个方法都是使用同一个connection连接。如果我们出现了耗时的操作，比如第三方接口调用，业务逻辑复杂，大批量数据处理等就会导致我们我们占用这个connection的时间会很长，数据库连接一直被占用不释放。一旦类似操作过多，就会导致数据库连接池耗尽。在一个事务中执行RPC操作导致数据库连接池撑爆属于是典型的长事务问题，类似的操作还有在事务中进行大量数据查询，业务规则处理等

（4）有些网上配置事务的时候如果spring父容器不扫描@Controller，MVC子容器不扫描@Service.在control层配置的事务就会失效，所以复制网上配置的时候，推荐在service层使用@Transactional避免事务失效
（5）使用try，catch包裹的时候，catch后面如果没有抛出异常，发送异常程序会继续执行，也不会回滚事务
（6）如果是同一个类中的方法互相调用，事务也可能会失效