studyday1的博客

3.什么情况下@DS会失效？在同一个实现类中，一个非DS注解的常规方法里调用@DS注解的方法，同样存在@DS失效的情况，原因同2，是由spring的aop机制导致的，如果确有这种业务需要，可以将该DS注解方法定义在不同的类中，通过bean注入的方式调用，就不会出现这个问题。在事务方法内调用@DS注解的方法，@DS注解同样不生效，原因是spring只能拦截到最外层方法的@Transactional注解，此时加载该事务的数据源，在事务方法内即使调用了@DS注解的方法，获取的是外层事务的数据源，导致@DS失效。

假如当前正要运行的事务不在另外一个事务里，那么就起一个新的事务 比方说，ServiceB.methodB的事务级别定义PROPAGATION_REQUIRED, 那么因为执行ServiceA.methodA的时候，ServiceA.methodA已经起了事务。此外，只读事务不能保证数据的一致性，因为在只读事务中，数据可能已经被其他事务修改了，因此在使用只读事务时需要注意这一点。此外，只读事务不能保证数据的一致性，因为在只读事务中，数据可能已经被其他事务修改了，因此在使用只读事务时需要注意这一点。

我们在写业务逻辑时，对于有些方法逻辑中，可能会抛异常，比如增删改查的dao层接口throws异常，那在service层中调用后我们需要进行try catch捕获异常，不捕获的话最终也需要在controller层捕获；这里就需要关注一个问题：try catch 语句会让。使用try catch后，相当于就是捕获了异常，事务管理就无感知有异常抛出了，相当于把异常吃掉了，这样事务管理就认为是程序没有出异常了。这样假设在修改接口中，涉及到了异常，事务就会失效，失效则不会回滚，数据就会被修改，无法回到修改前状态。