1. 事务管理器抽象

一个事务管理器只需要三个基本的能力：获取一个事务、提交事务、回滚事务。

public interface PlatformTransactionManager extends TransactionManager {
    // 获取一个事务
    TransactionStatus getTransaction(@Nullable TransactionDefinition definition)
            throws TransactionException;

    // 提交事务
    void commit(TransactionStatus status) throws TransactionException;

    // 回滚事务
    void rollback(TransactionStatus status) throws TransactionException;
}

DataSourceTransactionManagerAutoConfiguration 配置类导入了数据库事务管理器 DataSourceTransactionManager。

2. 事务同步回调钩子

事务同步回调钩子让我们有机会在事务的各个阶段加入一些协调的动作。

public interface TransactionSynchronization extends Flushable {
    /** Completion status in case of proper commit. */
    int STATUS_COMMITTED = 0;

    /** Completion status in case of proper rollback. */
    int STATUS_ROLLED_BACK = 1;

    /** Completion status in case of heuristic mixed completion or system errors. */
    int STATUS_UNKNOWN = 2;

    default void suspend() {}
    default void resume() {}
    default void flush() {}
    default void beforeCommit(boolean readOnly) {}
    default void beforeCompletion() {}
    default void afterCommit() {}
    default void afterCompletion(int status) {}
}

继续阅读 →

1. 应用场景说明

有多个事务发起的点 E0、E1，都调用到需要在事务里执行的方法 M0、M1，M0、M1 里都可能产生一些逻辑：一些作为事务的一部分执行、一些在事务提交失败时执行、一些在事务成功提交后执行。

2. 自行实现的一个简陋实现

应用命令模式把要根据事务是否提交成功来决定执行的逻辑封装成一个命令，在事务之外来执行。

定义了下面这样一个类，分别用于收集在事务提交成功和失败后执行的逻辑：

public class Actions {
    private List<Runnable> transactionCommitSuccessActions = new ArrayList<Runnable>();
    private List<Runnable> transactionCommitFailedActions = new ArrayList<Runnable>();
}

在开启事务前初始化一个 Actions 对象，然后事务方法调用到的方法都得传递这个对象，在事务方法结束后就可以根据事务是否成功来执行不同的队列里的逻辑。

继续阅读 →

Spring 的事务传播属性

org.springframework.transaction.annotation.Propagation 定义了 Spring 的事务传播属性：

• REQUIRED: 支持当前事务，如果不存在则新建一个。

• REQUIRES_NEW: 创建新的事务，如果当前存在一个则 suppend 当前的。

• SUPPORTS: 支持当前事务，如果不存在则以非事务方式执行。

• MANDATORY: 支持当前事务，如果不存在则抛出异常。

• NOT_SUPPORTED: 以非事务方式执行，如果当前存在一个事务则 suppend 当前的。

• NEVER: 以非事务方式执行，如果存在事务则抛出异常。

• NESTED: 如果当前存在一个事务则以嵌套事务的方式执行。

一个生产问题

一开始是 DBA 反馈数据库出现两种现象：

1. 出现一些操作做完但会话一直还在等待客户端的提交动作。
2. 偶尔出现大量的行锁，导致 JVM 线程互相等待而假死。

有个获取流水号的方法 systemService.getSerialNo 的事务传播属性是 NOT_SUPPORTED 的，这个方法通过类似这样的 update t_serialno set serial_no = :newSerialNo where serial_key = :key and serial_no = :oldSerialNo SQL 语句进行更新，更新返回的受影响行数等于 1 认为新的流水号是不重复的，更新不成功则重试。

行锁就出现在这些流水号的更新上。

继续阅读 →

问题

最近有同事碰到这个异常信息： Transaction rolled back because it has been marked as rollback-only ，异常栈被吃了，没打印出来。

调用代码大概如下：

@Component
public class InnerService {
    @Autowired
    private JdbcTemplate jdbcTemplate;

    @Transactional(rollbackFor = Throwable.class)
    public void innerTx(boolean ex) {
        jdbcTemplate.execute("insert into t_user(uname, age) values('liuwhb', 31)");
        if (ex) {
            throw new NullPointerException();
        }
    }

}

@Component
public class OutterService {
    @Autowired
    private InnerService innerService;

    @Transactional(rollbackFor = Throwable.class)
    public void outTx(boolean ex) {
        try {
            innerService.innerTx(ex);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

outterService.outTx(true);

他期望的是 innerService.innerTx(ex); 调用即使失败了也不会影响 OutterService.outTx 方法上的事务，只回滚了 innerTx 的操作。

结果没有得到他想要的，调用 OutterService.outTx 的外围方法捕获到了异常，异常信息是 Transaction rolled back because it has been marked as rollback-only，outTx 的其他操作也没有提交事务。

分析

上述方法的事务传播机制的默认的，也就是 Propagation.REQUIRED，如果当前已有事务就加入当前事务，没有就新建一个事务。

事务性的方法 outTx 调用了另一个事务性的方法 innerTx 。调用方对被调用的事务方法进行异常捕获，目的是希望被调用方的异常不会影响调用方的事务。

但还是会影响调用方的行为的。Spring 捕获到被调用事务方法的异常后，会把事务标记为 read-only，然后调用方提交事务的时候发现事务是只读的，就会抛出上面的异常。

继续阅读 →