前述

这段时间在工作中碰到一个事务相关的问题。先说下这个问题的场景，我们是一个商城项目，正在开发优惠券模块，现在有一个需求是需要批量领取优惠券，而且在领券时，其中一张领取失败不能影响其他符合要求的券的领取。由于之前在开发时，在领券这一块一直做的是单张领取,所以在做批量的时候很简单的做了个循环，然后封装成一个批量领券的方法中。伪代码如下：

@Service
@Transactional(rollbackFor = Exception.class)
@Slf4j
public class CouponService {
    /**
     * 单独领取某张券
     * @param couponCode
     * @return
     */
    public Coupon get(String couponCode) {
        log.info("查询是否存在这个券");
        if ("001".equals(couponCode) || "002".equals(couponCode)) {
            return Coupon.builder().code(couponCode).name("优惠券A").build();
        }
        // 自定义的异常类，专门指定不符合规则的券被领取时抛出的状态
        throw new CustomeException("不存在这个优惠券");
    }
    /**
     * 批量领取
     * @param codes
     * @return
     */
    public List<Coupon> batchGet(List<String> codes) {
        List<Coupon> target = new ArrayList<>();
        codes.forEach(code -> {
            Coupon coupon = null;
            try {
                coupon = get(code);
            } catch (CustomeException e) {
                log.error(e.getMessage());
            }
            target.add(coupon);
        });
        return target;
    }
}

上面的方法在执行时会抛出异常

Transaction rolled back because it has been marked as rollback-only

我们来分析下这个异常：

首先我们要知道，spring中事务的默认传播机制是

PROPAGATION_REQUIRED：如果存在一个事务，则支持当前事务。如果没有事务则开启

在这种传播机制下，batchGet方法跟循环中的get方法会共享一个事务，而在get方法抛出异常时，这个事务已经被标记为rollback-only了，在这种情况下，batchGet方法捕获了这个异常并没有继续向上抛出，所以会执行commit操作，而对一个被标记成rollback-only的方法执行commit操作，就会抛出以上错误。

我的解决办法就是，在batcGet方法上将事务的隔离级别设置为PROPAGATION_SUPPORTS：如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。

Transaction rolled back because it has been marked as rollback-only

Spring中事务的传播机制：

1.ROPAGATION_REQUIRED：如果存在一个事务，则支持当前事务。如果没有事务则开启

解释：当A.methodA()和B.methodB()都打上REQUIRED的事务标志，执行A.methodA()方法的时候，看到上下文没有事务，会新建一个事务，当执行到b.methodB()的时候，发现上下文已经有事务了，则不会新建事务，用A.methodA()新建的那个事务。如果b.methodB()执行成功，a.methodA()执行失败，那么b.methodB()和a.methodA()都会回滚（用的都是a.methodA()的事务）

2.PROPAGATION_SUPPORTS：如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行

解释：当B.methodB()打上PROPAGATION_SUPPORTS的事务标志，执行A.methodA()方法，当执行到b.methodB()的时候，会检查上下文有没有事务，如果A.methodA()有事务，则b.methodB()沿用该事务，反之b.methodB()就以非事物的方式执行

3. PROPAGATION_MANDATORY:如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常

解释：当B.methodB()打上PROPAGATION_MANDATORY的事务标志，执行A.methodA()方法，当执行到b.methodB()的时候，会检查上下文有没有事务，如果A.methodA()有事务，则b.methodB()沿用该事务，如果没有，则会抛出异常

4.PROPAGATION_REQUIRES_NEW：总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起

解释：当B.methodB()打上PROPAGATION_REQUIRES_NEW的事务标志，执行A.methodA()方法，当执行到b.methodB()的时候，会检查上下文有没有事务，如果A.methodA()有事务，则会挂起A.methodA()的事务，新建一个属于b.methodB()，当b.methodB()的事务执行结束的时候，则会唤醒b.methodB()的事务。和PROPAGATION_REQUIRED的差别在于回滚，当b.methodB()的事务提交后，A.methodA()执行失败，只会回滚A.methodA不会回滚b.methodB()，当b.methodB()执行失败，异常被A.methodA()方法catch到的话，A.methodA()事务不会回滚

5.PROPAGATION_NOT_SUPPORTED：总是非事务地执行，并挂起任何存在的事务

解释：当B.methodB()打上PROPAGATION_NOT_SUPPORTED的事务标志，执行A.methodA()方法，当执行到b.methodB()的时候，会检查上下文有没有事务，如果A.methodA()有事务，则会挂起A.methodA()的事务，当执行完b.methodB()方法的时候，A.methodA()方法继续以事务的方式执行

6.PROPAGATION_NEVER： 总是非事务地执行，如果存在一个活动事务，则抛出异常

解释：当B.methodB()打上PROPAGATION_NEVER的事务标志，执行A.methodA()方法，当执行到b.methodB()的时候，会检查上下文有没有事务,如果有事务，则抛出异常，如果没有则以非事务执行

7.PROPAGATION_NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, PROPAGATION_REQUIRED 属性执行

解释：当B.methodB()打上PROPAGATION_NOT_SUPPORTED的事务标志，执行A.methodA()方法，当执行到b.methodB()的时候，如果A.methodA()方法有事务，则会用当前事务，如果 b.methodB()执行失败，只会回滚 b.methodB()，不会回滚A.methodA()，只有当A.methodA()执行完成后才会提交b.methodB()的事务，如果A.methodA()方法没有事务，就会新建一个事务；

Spring中事物的隔离级别

事务隔离级别:

ISOLATION_DEFAULT,

ISOLATION_READ_UNCOMMITTED,

ISOLATION_READ_COMMITTED,

ISOLATION_REPEATABLE_READ,

ISOLATION_GENERALIZABLE

1.ISOLATION_DEFAULT:这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别

2. ISOLATION_READ_UNCOMMITTED ：这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。

3. ISOLATION_READ_COMMITTED ：保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。：

4. ISOLATION_REPEATABLE_READ ：这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。

5. ISOLATION_SERIALIZABLE ：这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻读。