spring事务的三个坑

最新推荐文章于 2024-05-22 10:00:08 发布

享学源码

最新推荐文章于 2024-05-22 10:00:08 发布

阅读量480

点赞数

分类专栏： spring

本文链接：https://blog.csdn.net/wuqinduo/article/details/102744964

版权

spring 专栏收录该内容

16 篇文章 3 订阅

订阅专栏

回顾

在spring源码系列11:事务代理对象的执行那一节，得出的结论
事务执行：通过TransactionInterceptor增强器对
目标方法进行环绕增强。

调用目标方法前，创建事务。
执行目标方法
调用目标方法后，提交事务。

TransactionInterceptor功能增强功能的是实现在父类TransactionAspectSupport的invokeWithinTransaction方法

关键代码：

			//创建事务
			TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
			Object retVal = null;
			try {
				//执行目标方法
				retVal = invocation.proceedWithInvocation();
			}
			catch (Throwable ex) {
				//异常回滚
				completeTransactionAfterThrowing(txInfo, ex);
				throw ex;
			}
			finally {
				cleanupTransactionInfo(txInfo);
			}
			//提交事务
			commitTransactionAfterReturning(txInfo);
			return retVal;

最近遇到事务方面的问题。在看了源码后，才对这些问题的出现豁然开朗

事务存在的三个问题

假如有这么一个类

@Service
public class TransactionalService {

    @Autowired
    UserDao userDao;

	public String noTransactionalSave(){
        System.out.println("非事务方法");
        return  save1();
    }
    @Transactional
    public String save1(){
        User user = new User("主动方事务方法",0);
        save2();
        userDao.save(user);
        return "save1";
    }
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public String save2(){
        User user = new User("被事务方法",1);
        userDao.save(user);
        return "save2";
    }
    @Transactional
    public synchronized String syncSave(){
        System.out.println("锁方法");
        User user = new User("锁方法",0);
        userDao.save(user);
        return "锁";
    }
}

记得在事务代理的创建那一节说过，不管是方法上，还是类上使用 @Transactional。都会对此类进行代理的创建。
创建代理后，调用目标方法首先调用的是代理的方法。

以CGLB为例，执行链

调用方法-->动态代理类.方法-->MethodInterceptor.intercept方法-->MethodInvocation.proceed执行增强器链-->Adivce.invoke方法-->目标方法

我们再看看MethodInterceptor.intercept()方法

@Override
		public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
			Object oldProxy = null;
			boolean setProxyContext = false;
			Class<?> targetClass = null;
			Object target = null;
			try {
				//是否暴露出代理对象。
				if (this.advised.exposeProxy) {
					//将代理对象放到事务上下文中。
					oldProxy = AopContext.setCurrentProxy(proxy);
					setProxyContext = true;
				}
				// May be null. Get as late as possible to minimize the time we
				// "own" the target, in case it comes from a pool...
				target = getTarget();
				if (target != null) {
					targetClass = target.getClass();
				}
				List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);
				Object retVal;
				//没事增强，则使用反射调用目标类方法方法
				//也就是处理非事务方法
				if (chain.isEmpty() && Modifier.isPublic(method.getModifiers())) {
					
					Object[] argsToUse = AopProxyUtils.adaptArgumentsIfNecessary(method, args);
					retVal = methodProxy.invoke(target, argsToUse);
				}
				else {
					//处理事务方法
					retVal = new CglibMethodInvocation(proxy, target, method, args, targetClass, chain, methodProxy).proceed();
				}
				retVal = processReturnType(proxy, target, method, retVal);
				return retVal;
			}
			finally {
				if (target != null) {
					releaseTarget(target);
				}
				if (setProxyContext) {
					// Restore old proxy.
					AopContext.setCurrentProxy(oldProxy);
				}
			}
		}

1.同类中非事务方法调事务方法

首先因为有事务注解，所以会生成代理对象。

因为首先调用的是非事务方法，所以chain.isEmpty()条件成立，走反射执行目标方法。

执行链：
代理类noTransactionalSave()-->MethodInterceptor.intercept方法-->methodProxy.invoke方法--->目标类.noTransactionalSave()-->目标.save1()方法。

我们看出事务方法save1()虽然有事务注解，但是因为其被非事务方法调用。在本次调用链中，没有走事务增强分支，所以导致了事务的失效。

结论：同类中非事务方法调用事务方法，因为执行链不会走事务增强，导致此次调用中事务方法的事务失效。

解决办法：
（1：出现此中业务场景时，可将非事务方法与事务方法抽象到不同的类中。事务方法所在类会创建事务代理，调用事务方法，走事务增强。
（2：看MethodInterceptor.intercept()中开头有一个if(this.advised.exposeProxy)的判断，如果为真，就会把事务代理对象放到事务上下文中，我们可以在非事务方法中，使用AopContext.currentProxy()获取代理对象,强制save1方法走代理执行。

项目中，我们遇到最多的应该就是事务失效问题，以前总是对事务失效问题模模糊糊，最近看了AOP源码，才对此有了深刻理解。

2.同类中事务方法调用事务方法

同类中事务方法调用事务方法，虽然不会出现事务失效问题。但是却会出现事务传播失效问题。

执行链：
代理方法.save1()--->MethodInterceptor.intercept方法--->methodProxy.invoke方法--->MethodInvocation.proceed执行增强器链-->Adivce.invoke增强方法--->目标方法.save1--->目标方法.save2

可以看出save1是事务方法，会走事务增强，但是save2的调用，是在save1方法增强调用链中，也就是说save2是依靠save1的事务。save2的事务配置，因为没有走Adivce(TransactionInterceptor).invoke增强方法,他的事务传播属性不会被解析。

结论：同类中事务方法调用事务方法，传播属性失效。

解决办法：同1中解决

3.调用同步事务方法

最近同事就遇到了这个问题呢。他在事务方法上加了synchronized关键词，让对此方法的调用强制串行化。

第一个线程查询数据库，没有对应的实例数据，则创建一个数据
第二个线程进入方法查询数据库，有了对应的值，则不用创建。
以此来达到幂等性问题。

想法是好的，但是结果确是有时还是会创建两条。

问题出在哪里呢？

首先：
在动态代理一节讲过，所谓的代理是在内存中生成了新的字节码文件。
在CGLB情况下，TransactionalService类生成的代理类TransactionalService$$EnhancerBySpringCGLIB$$cdcbf2e8中的syncSave()并没有synchronized修饰的。

 public final String syncSave() {
        try {
            MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
            if (var10000 == null) {
                CGLIB$BIND_CALLBACKS(this);
                var10000 = this.CGLIB$CALLBACK_0;
            }

            return var10000 != null ? (String)var10000.intercept(this, CGLIB$syncSave$1$Method, CGLIB$emptyArgs, CGLIB$syncSave$1$Proxy) : super.syncSave();
        } catch (Error | RuntimeException var1) {
            throw var1;
        } catch (Throwable var2) {
            throw new UndeclaredThrowableException(var2);
        }
    }

其次：
再看看TransactionInterceptor对事务的增强那一段关键代码。事务的增强逻辑是在TransactionInterceptor中的。

			//创建事务
			TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
			Object retVal = null;
			try {
				//执行目标方法
				retVal = invocation.proceedWithInvocation();
			}
			catch (Throwable ex) {
				//异常回滚
				completeTransactionAfterThrowing(txInfo, ex);
				throw ex;
			}
			finally {
				cleanupTransactionInfo(txInfo);
			}
			//提交事务
			commitTransactionAfterReturning(txInfo);
			return retVal;

也就是说：两个线程都阻塞到目标方法上，当第一个线程离开目标方法时，他的调用回到了TransactionInterceptor中，做提交事务动作。但是此时第二个线程进入目标方法去执行数据库查询操作，但第一个线程的提交事务动作可能为完成，此时数据库中并没有，所以第二个线程也会创建一个实例数据。这样就可能出现创建两条的情况。

可以看出加锁的范围没有包括到整个事务，把synchronized加到方法上出发点时好的。但是真实的调用确实从代理类开始的，生成的代理类中并没有加synchronized，结合事务的增强。导致了synchronized同步的失效。

结论：@Transcational注解和synchronized锁一起使用会导致同步失效。加锁的范围没有包括到整个事务

解决办法：既然两个在一起，不能使用锁范围覆盖整个事务。那就创造一个覆盖整个事务的调用。锁方法与事务方法分离到不同的类中，在锁方法中调用事务方法，不就完成了锁范围覆盖整个事务了吗