浅谈@Transactional

问题一：为什么@Transactional注解会生效？

@Transactional实质是使用了JDBC的事务来进行事务控制的
@Transactional基于Spring的动态代理的机制

加了注解通过aop实现，aop底层是动态代理，底层执行TransactionInterceptor的里面包装了打开事务，执行业务逻辑，异常就回滚，没有异常就commit提交事务

 

 

 

问题二：@Transactional哪几种情况会失效？

1）Transactional注解标注方法修饰符为非public时，@Transactional注解将会不起作用。

@Transactional 注解应该只被应用到 public 方法上，这是由 Spring AOP 的本质决定的。在 protected、private 或者默认可见性的方法上使用 @Transactional 注解，这将被忽略，也不会抛出任何异常

2）在类内部调用调用类内部@Transactional标注的方法。这种情况下也会导致事务不开启

既然事务管理是基于动态代理对象的代理逻辑实现的，那么如果在类内部调用类内部的事务方法，这 个调用事务方法的过程并不是通过代理对象来调用的，而是直接通过this对象来调用方法，绕过的代理对 象，肯定就是没有代理逻辑了。

3）事务方法内部捕捉了异常，没有抛出新的异常，导致事务操作不会进行回滚。

 

 

当数据库上有多个事务同时执行的时候，就可能出现如下问题：

• 脏读（dirty read）：读取了未提交的数据（涉及数据修改）
• 不可重复读（non-repeatable read）：同个事务中多次读取的同一条数据的值不同（涉及数据修改）
• 幻读（phantom read）：同个事务中相同条件下查出的数据条数不同（涉及数据增删）

 

隔离级别：

*读未提交（read uncommitted）：**一个事务还没提交时，它做的变更就能被别的事务看到。
**读提交（read committed）：**一个事务提交之后，它做的变更才会被其他事务看到。
可重复读（repeatable read）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
**串行化（serializable ）：**顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。