Spring 在 4.2 版本之后提供了@TransactionlEventListener 注解，可以很方便地在事务提交后做一些处理，但是如果使用不当，或者没有正确理解其背后的运行逻辑，很容易踩坑甚至导致线上故障。

之前工作中就遇到了一个问题，在事务监听时，做了一些事务操作，但是这个事务并没有生效。

今天我们就来深入了解一下，这个问题是怎么产生的，又该如何解决。

问题复现

我们来模拟一个很简单的场景：创建订单的时候会发布“订单已注册”的事件，在事件监听里保存操作记录，再发布“操作记录已保存”的事件，最后在这个事件监听里做一些逻辑。

以下代码中省略了一些不重要的实现。

首先是 OrderService，createOrder() 方法里保存订单记录，发布“订单已注册”的事件：

publicclassOrderService {

    @Transactional
    publicvoidcreateOrder(){
        String orderNo = "test_no";
        Order order = new Order(orderNo);
        orderRepository.save(order);
        log.info("publish OrderCreatedEvent");
        applicationContext.publishEvent(new OrderCreatedEvent(orderNo));
    }

}

“订单已注册”的事件监听里，调用

operationService.saveOperation()：

publicclassOrderCreatedEventListener {

    @TransactionalEventListener
    publicvoidhandle(OrderCreatedEvent event) {
        log.info("handle OrderCreatedEvent : " + event.getOrderNo());
        operationService.saveOperation(event.getOrderNo(), "创建订单");
    }

}

OperationService.saveOperation()，保存操作记录，并发布“操作记录已保存”的事件：

publicclassOperationService {

    @Transactional
    publicvoidsaveOperation(String orderNo, String info){
        Operation operation = new Operation(orderNo, info);
        operationRepository.save(operation);
        log.info("publish OperationSavedEvent");
        applicationContext.publishEvent(new OperationSavedEvent(orderNo, info));
    }

}

“操作记录已保存”的事件监听里，打印一下日志，代替后续操作：

publicclassOperationSavedEventListener {

    @TransactionalEventListener
    publicvoidhandle(OperationSavedEvent event) {
        log.info("handle OperationSavedEvent : " + event.getOrderNo());
    }

}

开始测试，调用一下 orderService.createOrder() 方法，看一下日志打印：

Hibernate: insertintoorder_entity (id, order_no) values (null, ?)
INFOc.l.s.service.OrderService    : publishOrderCreatedEventINFOc.l.s.event.OrderCreatedEventListener    : handleOrderCreatedEvent : test_noINFOc.l.s.service.OperationService: publishOperationSavedEvent

奇怪的事情发生了！数据库里只写入了订单数据，并没有写入操作记录，而且发布了 OperationSavedEvent 事件后，监听回调没有执行。

问题排查

先翻阅一下官方文档，在 事务事件 章节内，有这么一段提示：

最后一句话的意思是：在事务事件监听内，已经没有可供加入的事务。

回顾一下上面的问题代码，OrderService.createOrder() 是一个事务方法，这个事务提交后，触发了

OperationSavedEventListener，而在这个监听方法里，OperationService.saveOperation() 也是一个事务方法，传播类型为默认，即会加入当前事务。

但是在执行 saveOperation() 时，前面的事务已经完成了提交，所以没办法加入，导致操作记录保的事务没有真正执行。又因为操作记录保存的事务没有执行，所以没有触发

OperationSavedEventListener。

哦~大概明白了问题所在，我们进入 Spring 源码看一看是不是真的如此。

首先将 JPA 的日志级别调整为 debug

logging.level.org.springframework.orm.jpa=debug

再运行一下，看看日志：

DEBUG o.s.orm.jpa.JpaTransactionManager        : Creating new transaction withname [co.lilpilot.springtestfield.service.OrderService.createOrder]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
DEBUG o.s.orm.jpa.JpaTransactionManager        : Opened new EntityManager [SessionImpl(1115296438<open>)] for JPA transaction
DEBUG o.s.orm.jpa.JpaTransactionManager        : Exposing JPA transactionas JDBC [org.springframework.orm.jpa.vendor.HibernateJpaDialect$HibernateConnectionHandle@fe87ddd]
DEBUG o.s.orm.jpa.JpaTransactionManager        : Foundthread-bound EntityManager [SessionImpl(1115296438<open>)] for JPA transaction
DEBUG o.s.orm.jpa.JpaTransactionManager        : Participating in existing transaction
Hibernate: insertinto order_entity (id, order_no) values (null, ?)
INFO c.l.s.service.OrderService    : publish OrderCreatedEvent
DEBUG o.s.orm.jpa.JpaTransactionManager        : Initiating transactioncommit
DEBUG o.s.orm.jpa.JpaTransactionManager        : Committing JPA transactionon EntityManager [SessionImpl(1115296438<open>)]
INFO c.l.s.event.OrderCreatedEventListener    : handle OrderCreatedEvent : test_no
DEBUG o.s.orm.jpa.JpaTransactionManager        : Foundthread-bound EntityManager [SessionImpl(1115296438<open>)] for JPA transaction
DEBUG o.s.orm.jpa.JpaTransactionManager        : Participating in existing transaction
DEBUG o.s.orm.jpa.JpaTransactionManager        : Foundthread-bound EntityManager [SessionImpl(1115296438<open>)] for JPA transaction
DEBUG o.s.orm.jpa.JpaTransactionManager        : Participating in existing transaction
INFO c.l.s.service.OperationService: publish OperationSavedEvent
DEBUG o.s.orm.jpa.JpaTransactionManager        : Cannot register Spring after-completion synchronization with existing transaction - processing Spring after-completion callbacks immediately, with outcome status'unknown'
DEBUG o.s.orm.jpa.JpaTransactionManager        : Closing JPA EntityManager [SessionImpl(1115296438<open>)] aftertransaction

注意，出现了一行日志提示：“Cannot register Spring after-completion synchronization with existing transaction – processing Spring after-completion callbacks immediately, with outcome status ‘unknown’”。

顺藤摸瓜进入 JpaTransactionManager 类，其实这一行日志的打印是在它的抽象父类中，即

AbstractPlatformTransactionManager.registerAfterCompletionWithExistingTransaction()

可以看到这里指定了事务状态为 STATUS_UNKNOWN，所以后续的回调逻辑里不再执行事务操作了。这个方法是在

AbstractPlatformTransactionManager.triggerAfterCompletion() 内被调用的：

在这里判断了事务的状态，此时我们的事务状态为有事务，但不是一个新事务，所以进了第二个判断分支。而触发的地方，就是

AbstractPlatformTransactionManager.processCommit()，也就是 Spring 处理事务提交的地方：

privatevoidprocessCommit(DefaultTransactionStatus status)throws TransactionException {
    try {

        //... 省略 doCommit 相关逻辑try {
            triggerAfterCommit(status);
        }
        finally {
            // ①
            triggerAfterCompletion(status, TransactionSynchronization.STATUS_COMMITTED);
        }

    }
    finally {
        // ②
        cleanupAfterCompletion(status);
    }
}

在 commit 逻辑处理完成后，即标识①的位置，触发了事务提交后的回调。

看到这里，问题已经很清楚了，Spring 在事务提交后，会触发后续回调逻辑，但是如果回调逻辑里也存在事务方法，却又不是一个新事务时，这个妄想加入的事务不会被提交。

问题解决

其实明白了问题，解决方案自然也很简单，只需要调整一下事务的传播类型，把保存操作记录的方法，标示为一个新的事务就好了：

publicclassOperationService {

    @Transactional(Transactional.TxType.REQUIRES_NEW)
    publicvoidsaveOperation(String orderNo, String info){
        Operation operation = new Operation(orderNo, info);
        operationRepository.save(operation);
        log.info("publish OperationSavedEvent");
        applicationContext.publishEvent(new OperationSavedEvent(orderNo, info));
    }

}

这样子，操作记录的保存就能写入数据库，而且也能触发后续的事件监听。

One More Thing

且慢，我们再回想一下，Spring 的事件监听机制，其实是基于观察者模式的同步回调，而事务事件的监听同理，也是在事务提交后，获取事务同步注册器中已经注册了的回调，再同步执行。

刚才分析了

AbstractPlatformTransactionManager.processCommit()，触发回调方法 triggerAfterCompletion() 之后，还有最后一步操作 cleanupAfterCompletion()，即标识②所在的位置。

而在这一步中，才会关闭数据库的连接。

你是不是意识到了什么？

如果在事务事件监听的同步处理中，是个耗时较长的操作，就会一直持有这个数据库连接，线上如果有大量的并发调用，数据库的连接池很容易被耗尽。

想要解决这个问题，可以考虑异步，用新线程去处理这个耗时调用，提前结束回调并释放之前的数据库连接。

总结

在这篇文章中，我们分析了在使用 Spring 的事务监听器时，因为原事务已提交，后续事务加入失败而导致的事务失效问题，解决方案就是将后续事务作为新事物处理。

同时梳理了一下 Spring 事务提交和后续处理的过程，明白了回调操作仍然持有之前的数据库连接，如果耗时过长可能会耗尽连接池，可以通过新线程处理来避免这个问题。

资源获取：

大家

点赞、收藏、关注、评论

啦 、

查看

👇🏻
👇🏻
👇🏻

微信公众号获取联系方式

👇🏻
👇🏻
👇🏻


精彩专栏推荐订阅：

在

下方专栏

👇🏻
👇🏻
👇🏻
👇🏻


每天学四小时：Java+Spring+JVM+分布式高并发，架构师指日可待