引起Spring事务失效的可能原因

简介: 引起Spring事务失效的可能原因

引起Spring事务失效的可能原因

一、 事务不生效

1.访问权限问题

众所周知,java的访问权限主要有四种:private、default、protected、public,它们的权限从左到右,依次变大。

但如果我们在开发过程中,把有某些事务方法,定义了错误的访问权限,就会导致事务功能出问题,例如:

@Service
public class RoleService {
    @Transactional
    private void add(RoleModel roleModel) {
        save(roleModel);
        update(roleModel);
    }
}


AbstractFallbackTransactionAttributeSource类的computeTransactionAttribute方法中有个判断,如果目标方法不是public,则TransactionAttribute返回null,即不支持事务。

Don't allow no-public methods as required.

也就是说,如果我们自定义的事务方法(即目标方法),它的访问权限不是public,而是private、default或protected的话,spring则不会提供事务功能。

2. 方法用final修饰

@Service 
public class RoleService {
@Transactional     
public final void add(RoleModel roleModel){
  save(roleModel);
  update(roleModel);
 }
}

结果:事务失效。

为什么?

如果你看过spring事务的源码,可能会知道spring事务底层使用了aop,也就是通过jdk动态代理或者cglib,帮我们生成了代理类,在代理类中实现的事务功能。

但如果某个方法用final修饰了,那么在它的代理类中,就无法重写该方法,而添加事务功能。

注意:如果某个方法是static的,同样无法通过动态代理,变成事务方法。

3.方法内部调用

@Service 
public class UserService {
@Autowired    
private UserMapper userMapper;
public void add(UserModel userModel) {
  userMapper.insert(userModel);
  updateStatus(userModel);    
}     
@Transactional     
public void updateStatus(UserModel userModel) {
  doSameThing();
  }
}


结果是正确还是失败呢?

答案:在同一个类中的方法直接内部调用,会导致事务失效。

那么问题来了,如果有些场景,确实想在同一个类的某个方法中,调用它自己的另外一个方法,该怎么办呢?

3.1 新加一个Service方法

@Service 
public class ServiceA {
@Autowired    
prvate ServiceB serviceB;
public void save(User user) { 
  queryData1();
  queryData2();
  serviceB.doSave(user);    
}
}  
@Service  
public class ServiceB {
@Transactional(rollbackFor=Exception.class)
public void doSave(User user) {
  addData1();
  updateData2();
}
}


事务是否生效?答案:是可以的

3.2 在该Service类中注入自己

@Service
public class ServiceA {
    @Autowired
    prvate ServiceA
    serviceA;
    public void save(User user) {
        queryData1();
        queryData2();
        serviceA.doSave(user);
    }
    @Transactional(rollbackFor = Exception.class)
    public void doSave(User user) {
        addData1();
        updateData2();
    }
}


事务是否生效?答案:是可以的

这种做法会不会出现循环依赖问题?答案:不会。

spring ioc内部的三级缓存保证了它,不会出现循环依赖问题

3.3 通过AopContent类

@Service
public class ServiceA {
    public void save(User user) {
        queryData1();
        queryData2();
        ((ServiceA) AopContext.currentProxy()).doSave(user);
    }
    @Transactional(rollbackFor = Exception.class)
    public void doSave(User user) {
        addData1();
        updateData2();
    }
}


事务是否生效?答案:是可以的

3.4 同类中调用嵌套方法AOP失效

在同一个类中,非事务方法A调用事务方法B,会导致事务失效,可以采用AopContext.currentProxy().xxxxx()来保证事务生效。

注意事项:

Spring Boot需要在启动类加上以下注解

@EnableAspectJAutoProxy(proxyTargetClass = true, exposeProxy = true)

SSM需要xml文件配置

<aop:aspectj-autoproxy proxy-target-class="true" expose-proxy="true"/>

为什么AopContext可以解决同类方法AOP失效问题

AopContext类的源码如下

package org.springframework.aop.framework;
import org.springframework.core.NamedThreadLocal;
import org.springframework.lang.Nullable;
public final class AopContext {     
// 维护了一个ThreadLocal,存放AOP代理类     
  private static final ThreadLocal<Object> currentProxy = new NamedThreadLocal<>("Current AOP proxy");
  private AopContext() {
  }    
    public static Object currentProxy() throws IllegalStateException {
    Object proxy = currentProxy.get();
    if (proxy == null) {
    throw new IllegalStateException("Cannot find current proxy: Set 'exposeProxy' property on Advised to 'true' to make it available, and " +                             "ensure that AopContext.currentProxy() is invoked in the same thread as the AOP invocation context.");         }         return proxy;     }     // 提供代理类set进ThreadLocal方法     @Nullable     static Object setCurrentProxy(@Nullable Object proxy) {         Object old = currentProxy.get();         if (proxy != null) {             currentProxy.set(proxy);         }         else {             currentProxy.remove();         }         return old;     } }
    //jdk动态代理创建时JdkDynamicAopProxy中的invoke方法中调用AopContext存入代理类
    public Object getProxy() {
        return getProxy(ClassUtils.getDefaultClassLoader());
    }
    public Object getProxy(ClassLoader classLoader) {
        if (logger.isDebugEnabled()) {
            logger.debug("Creating JDK dynamic proxy: target source is " + this.advised.getTargetSource());
        }
        Class[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised);
        findDefinedEqualsAndHashCodeMethods(proxiedInterfaces);
        return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this);
    }
    //生成代理类,反射生成的。JdkDynamicAopProxy继承自InvocationHandler
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object oldProxy = null;
        boolean setProxyContext = false;
        TargetSource targetSource = this.advised.targetSource;
        Object target = null;
        Integer var8;
        try {
            if (!this.equalsDefined && AopUtils.isEqualsMethod(method)) {
                Boolean var18 = this.equals(args[0]);
                return var18;
            }
            if (this.hashCodeDefined || !AopUtils.isHashCodeMethod(method)) {
                if (method.getDeclaringClass() == DecoratingProxy.class) {
                    Class var17 = AopProxyUtils.ultimateTargetClass(this.advised);
                    return var17;
                }
                Object retVal;
                if (!this.advised.opaque && method.getDeclaringClass().isInterface() && method.getDeclaringClass().isAssignableFrom(Advised.class)) {
                    retVal = AopUtils.invokeJoinpointUsingReflection(this.advised, method, args);
                    return retVal;
                }
                if (this.advised.exposeProxy) {             // Make invocation available if necessary. 
                oldProxy = AopContext.setCurrentProxy(proxy);
                setProxyContext = true;             
                }             
                target = targetSource.getTarget();
                Class<?> targetClass = target != null ? target.getClass() : null;
                List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
                if (chain.isEmpty()) { 
                Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
                retVal = AopUtils.invokeJoinpointUsingReflection(target, method, argsToUse);             
                } else {
                MethodInvocation invocation = new ReflectiveMethodInvocation(proxy, target, method, args, targetClass, chain); 
                retVal = invocation.proceed();             
                }            
                Class<?> returnType = method.getReturnType();
                if (retVal != null && retVal == target && returnType != Object.class && returnType.isInstance(proxy) && !RawTargetAccess.class.isAssignableFrom(method.getDeclaringClass())) {
                retVal = proxy; 
                } else if (retVal == null && returnType != Void.TYPE && returnType.isPrimitive()) {  
                throw new AopInvocationException("Null return value from advice does not match primitive return type for: " + method);   
                }            
                Object var12 = retVal; 
                return var12; 
                }        
                var8 = this.hashCode(); 
                } finally { 
                  if (target != null && !targetSource.isStatic()) { 
                  targetSource.releaseTarget(target);        
                  }        
                  if (setProxyContext) { 
                  AopContext.setCurrentProxy(oldProxy); 
                   }     
                  }    
                  return var8; 
                  }
                    请注意关键代码
                    if (this.advised.exposeProxy) {
                        oldProxy = AopContext.setCurrentProxy(proxy);
                        setProxyContext = true;
                    }
                    cglib动态代理CglibAopProxy在创建代理时也调用AopContext存入代理类
                    private static class DynamicAdvisedInterceptor implements MethodInterceptor, Serializable {
                        private final AdvisedSupport advised;
                        public DynamicAdvisedInterceptor(AdvisedSupport advised) {
                            this.advised = advised;
                        }
                        @Override
                        @Nullable
                        public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
                            Object oldProxy = null;
                            boolean setProxyContext = false;
                            Object target = null;
                            TargetSource targetSource = this.advised.getTargetSource();
                            try {
                                if (this.advised.exposeProxy) {                 // Make invocation available if necessary.
                                oldProxy = AopContext.setCurrentProxy(proxy); 
                                setProxyContext = true; 
                                }             // Get as late as possible to minimize the time we "own" the target, in case it comes from a pool...             target = targetSource.getTarget();             Class<?> targetClass = (target != null ? target.getClass() : null);             List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);             Object retVal;             // Check whether we only have one InvokerInterceptor: that is,             // no real advice, but just reflective invocation of the target.             if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) {                 // We can skip creating a MethodInvocation: just invoke the target directly.                 // Note that the final invoker must be an InvokerInterceptor, so we know                 // it does nothing but a reflective operation on the target, and no hot                 // swapping or fancy proxying.                 Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);                 retVal = methodProxy.invoke(target, argsToUse);             }             else {                 // We need to create a method invocation...                 retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();             }             retVal = processReturnType(proxy, target, method, retVal);             return retVal;         }         finally {             if (target != null && !targetSource.isStatic()) {                 targetSource.releaseTarget(target);             }             if (setProxyContext) {                 // Restore old proxy.                 AopContext.setCurrentProxy(oldProxy);             }         }     }
                                    其中关键代码
                                    if (this.advised.exposeProxy) {   
                                    // Make invocation available if necessary. 
                                    oldProxy = AopContext.setCurrentProxy(proxy);
                                    setProxyContext = true; 
                                    }


总结:AopContext可以解决同类方法AOP失效问题


4.未被spring管理

@Controller、@Service、@Component、@Repository等注解,可以自动实现bean实例化和依赖注入的功能。

忘了加@Service注解(错误用法):

//@Service
public class UserService {     
@Transactional     
public void add(UserModel userModel) { 
save(userModel);
update(userModel);
} 
}


事务是否生效?答案是不会生成事务。

5.多线程调用(注意)

spring事务用在多线程场景中,会有问题吗?

事务是否生效?(错误用法):

@Slf4j
@Service
public class UserService {
    @Autowired
    private UserMapper userMapper;
    @Autowired
    private RoleService roleService;
    @Transactional
    public void add(UserModel userModel) throws Exception {
        userMapper.insert(userModel);
        new Thread(() -> {
            roleService.doOtherThing();
        }).start();
    }
}
@Service
public class RoleService {
    @Transactional
    public void doOtherThing() {
        System.out.println("保存role表数据");
    }
}


事务方法add中,调用了事务方法doOtherThing,但是事务方法doOtherThing是在另外一个线程中调用的。

这样会导致两个方法不在同一个线程中,获取到的数据库连接不一样,从而是两个不同的事务。如果想doOtherThing方法中抛了异常,add方法也回滚是不可能的。

private static final ThreadLocal<Map<Object, Object>> resources =   new NamedThreadLocal<>("Transactional resources");

我们说的同一个事务,其实是指同一个数据库连接,只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程,拿到的数据库连接肯定是不一样的,所以是不同的事务。


二 、事务不回滚

spring目前支持7种传播特性:

  • REQUIRED如果当前上下文中存在事务,那么加入该事务,如果不存在事务,创建一个事务,这是默认的传播属性值。
  • SUPPORTS如果当前上下文存在事务,则支持事务加入事务,如果不存在事务,则使用非事务的方式执行。
  • MANDATORY如果当前上下文中存在事务,否则抛出异常。
  • REQUIRES_NEW每次都会新建一个事务,并且同时将上下文中的事务挂起,执行当前新建事务完成以后,上下文事务恢复再执行。
  • NOT_SUPPORTED如果当前上下文中存在事务,则挂起当前事务,然后新的方法在没有事务的环境中执行。
  • NEVER如果当前上下文中存在事务,则抛出异常,否则在无事务环境上执行代码。
  • NESTED 如果当前上下文中存在事务,则嵌套事务执行,如果不存在事务,则新建事务。
@Service 
public class UserService {
  @Transactional(propagation = Propagation.NEVER)
  public void add(UserModel userModel) {
     save(userModel);
     update(userModel);
   } 
}


目前只有这三种传播特性才会创建新事务:REQUIRED,REQUIRES_NEW,NESTED。

2.自己吞了异常

事务不会回滚,最常见的问题是:开发者在代码中手动try...catch了异常。比如(错误用法)

@Slf4j
@Service
public class UserService {
    @Transactional
    public void add(UserModel userModel) {
        try {
            save(userModel);
            update(userModel);
        } catch (Exception e) {
            log.error(e.getMessage(), e);
        }
    }
}


这种情况下spring事务当然不会回滚


3.手动抛了别的异常

异常是否会回滚?(错误用法)

@Slf4j
@Service
public class UserService {
    @Transactional
    public void add(UserModel userModel) throws Exception {
        try {
            save(userModel);
            update(userModel);
        } catch (Exception e) {
            log.error(e.getMessage(), e);
            throw new Exception(e);
        }
    }
}


答案:普通的Exception(非运行时异常),它不会回滚。

即使开发者没有手动捕获异常,但如果抛的异常不正确,spring事务也不会回滚。

上面的这种情况,开发人员自己捕获了异常,又手动抛出了异常:Exception,事务同样不会回滚。

因为spring事务,默认情况下只会回滚RuntimeException(运行时异常)和Error(错误),对于普通的Exception(非运行时异常),它不会回滚。


4.自定义了回滚异常(建议使用Exception或Throwable)

在使用@Transactional注解声明事务时,有时我们想自定义回滚的异常,spring也是支持的。可以通过设置rollbackFor参数,来完成这个功能。

异常是否会回滚?(错误用法)

@Slf4j 
@Service 
public class UserService {
@Transactional(rollbackFor = BusinessException.class)
public void add(UserModel userModel) throws Exception {                    save(userModel); 
update(userModel);    
} 
 }


答案:事务也不会回滚。

如果在执行上面这段代码,保存和更新数据时,程序报错了,抛了SqlException、DuplicateKeyException等异常。而BusinessException是我们自定义的异常,报错的异常不属于BusinessException,所以事务也不会回滚。

即使rollbackFor有默认值,但阿里巴巴开发者规范中,还是要求开发者重新指定该参数。

因为如果使用默认值,一旦程序抛出了Exception,事务不会回滚,这会出现很大的bug。所以,建议一般情况下,将该参数设置成:Exception或Throwable。


5.嵌套事务回滚多了

public class UserService {
    @Autowired
    private UserMapper userMapper;
    @Autowired
    private RoleService roleService;
    @Transactional
    public void add(UserModel userModel) throws Exception {
        userMapper.insert(userModel);
        roleService.doOtherThing();
    }
}
@Service
public class RoleService {
    @Transactional(propagation = Propagation.NESTED)
    public void doOtherThing() {
        System.out.println("保存role表数据");
    }
}


这种情况使用了嵌套的内部事务,原本是希望调用roleService.doOtherThing方法时,如果出现了异常,只回滚doOtherThing方法里的内容,不回滚 userMapper.insertUser里的内容,即回滚保存点。。但事实是,insertUser也回滚了。

因为doOtherThing方法出现了异常,没有手动捕获,会继续往上抛,到外层add方法的代理方法中捕获了异常。所以,这种情况是直接回滚了整个事务,不只回滚单个保存点。

怎么样才能只回滚保存点呢?

@Slf4j
@Service
public class UserService {
    @Autowired
    private UserMapper userMapper;
    @Autowired
    private RoleService roleService;
    @Transactional
    public void add(UserModel userModel) throws Exception {
        userMapper.insert(userModel);
        try {
            roleService.doOtherThing();
        } catch (Exception e) {
            log.error(e.getMessage(), e);
        }
    }
}


可以将内部嵌套事务放在try/catch中,并且不继续往上抛异常。这样就能保证,如果内部嵌套事务中出现异常,只回滚内部事务,而不影响外部事务。

三、 其他

1 大事务问题

package com.alibaba.fulfill.domain.event;
@Service
public class UserService {
    @Autowired
    private RoleService roleService;
    @Transactional
    public void add(UserModel userModel) throws Exception {
        query1();
        query2();
        query3();
        roleService.save(userModel);
        update(userModel);
    }
}
@Service
public class RoleService {
    @Autowired
    private RoleService roleService;
    @Transactional
    public void save(UserModel userModel) throws Exception {
        query4();
        query5();
        query6();
        saveData(userModel);
    }
}


其实只有这两行才需要事务:

roleService.save(userModel); update(userModel);

在RoleService类中,只有这一行需要事务:

saveData(userModel);

如果query方法非常多,调用层级很深,而且有部分查询方法比较耗时的话,会造成整个事务非常耗时,而从造成大事务问题

总结:

相较于@Transactional注解声明式事务,我们更建议大家使用,基于TransactionTemplate的编程式事务。主要原因如下:

  1. 避免由于spring aop问题,导致事务失效的问题。
  2. 能够更小粒度的控制事务的范围,更直观。
  3. 建议一般情况下,将该参数设置成:Exception或Throwable
目录
打赏
0
0
0
0
435
分享
相关文章
Spring中事务失效的场景
因为Spring事务是基于代理来实现的,所以某个加了@Transactional的⽅法只有是被代理对象调⽤时, 那么这个注解才会⽣效 , 如果使用的是被代理对象调用, 那么@Transactional会失效 同时如果某个⽅法是private的,那么@Transactional也会失效,因为底层cglib是基于⽗⼦类来实现 的,⼦类是不能重载⽗类的private⽅法的,所以⽆法很好的利⽤代理,也会导致@Transactianal失效 如果在业务中对异常进行了捕获处理 , 出现异常后Spring框架无法感知到异常, @Transactional也会失效
微服务——SpringBoot使用归纳——Spring Boot事务配置管理——常见问题总结
本文总结了Spring Boot中使用事务的常见问题,虽然通过`@Transactional`注解可以轻松实现事务管理,但在实际项目中仍有许多潜在坑点。文章详细分析了三个典型问题:1) 异常未被捕获导致事务未回滚,需明确指定`rollbackFor`属性;2) 异常被try-catch“吃掉”,应避免在事务方法中直接处理异常;3) 事务范围与锁范围不一致引发并发问题,建议调整锁策略以覆盖事务范围。这些问题看似简单,但一旦发生,排查难度较大,因此开发时需格外留意。最后,文章提供了课程源代码下载地址,供读者实践参考。
81 0
微服务——SpringBoot使用归纳——Spring Boot事务配置管理——Spring Boot 事务配置
本文介绍了 Spring Boot 中的事务配置与使用方法。首先需要导入 MySQL 依赖,Spring Boot 会自动注入 `DataSourceTransactionManager`,无需额外配置即可通过 `@Transactional` 注解实现事务管理。接着通过创建一个用户插入功能的示例,展示了如何在 Service 层手动抛出异常以测试事务回滚机制。测试结果表明,数据库中未新增记录,证明事务已成功回滚。此过程简单高效,适合日常开发需求。
195 0
微服务——SpringBoot使用归纳——Spring Boot事务配置管理——事务相关
本文介绍Spring Boot事务配置管理,阐述事务在企业应用开发中的重要性。事务确保数据操作可靠,任一异常均可回滚至初始状态,如转账、购票等场景需全流程执行成功才算完成。同时,事务管理在Spring Boot的service层广泛应用,但根据实际需求也可能存在无需事务的情况,例如独立数据插入操作。
54 0
Spring事务失效场景
本文深入探讨了Spring框架中事务管理可能失效的几种常见场景及解决方案,包括事务方法访问级别不当、方法内部自调用、错误的异常处理、事务管理器或数据源配置错误、数据库不支持事务以及不合理的事务传播行为或隔离级别。通过合理配置和正确使用`@Transactional`注解,开发者可以有效避免这些问题,确保应用的数据一致性和完整性。
113 10
【Spring】【事务】初学者直呼学会了的Spring事务入门
本文深入解析了Spring事务的核心概念与使用方法。Spring事务是一种数据库事务管理机制,通过确保操作的原子性、一致性、隔离性和持久性(ACID),维护数据完整性。文章详细讲解了声明式事务(@Transactional注解)和编程式事务(TransactionTemplate、PlatformTransactionManager)的区别与用法,并探讨了事务传播行为(如REQUIRED、REQUIRES_NEW等)及隔离级别(如READ_COMMITTED、REPEATABLE_READ)。
110 1
Spring中的事务是如何实现的
1. Spring事务底层是基于数据库事务和AOP机制的 2. ⾸先对于使⽤了@Transactional注解的Bean,Spring会创建⼀个代理对象作为Bean 3. 当调⽤代理对象的⽅法时,会先判断该⽅法上是否加了@Transactional注解 4. 如果加了,那么则利⽤事务管理器创建⼀个数据库连接 5. 并且修改数据库连接的autocommit属性为false,禁⽌此连接的⾃动提交,这是实现Spring事务⾮ 常重要的⼀步 6. 然后执⾏当前⽅法,⽅法中会执⾏sql 7. 执⾏完当前⽅法后,如果没有出现异常就直接提交事务 8. 如果出现了异常,并且这个异常是需要回滚的就会回滚事务
Spring事务失效,常见的情况有哪些?
本文总结了Spring事务失效的7种常见情况,包括未启用事务管理功能、方法非public类型、数据源未配置事务管理器、自身调用问题、异常类型错误、异常被吞以及业务和事务代码不在同一线程中。同时提供了两种快速定位事务相关Bug的方法:通过查看日志(设置为debug模式)或调试代码(在TransactionInterceptor的invoke方法中设置断点)。文章帮助开发者更好地理解和解决Spring事务中的问题。
115 7
【SpringFramework】Spring事务
本文简述Spring中数据库及事务相关衍伸知识点。
78 9
理解和解决Spring框架中的事务自调用问题
事务自调用问题是由于 Spring AOP 代理机制引起的,当方法在同一个类内部自调用时,事务注解将失效。通过使用代理对象调用、将事务逻辑分离到不同类中或使用 AspectJ 模式,可以有效解决这一问题。理解和解决这一问题,对于保证 Spring 应用中的事务管理正确性至关重要。掌握这些技巧,可以提高开发效率和代码的健壮性。
422 13

热门文章

最新文章

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问