介绍

如您可能已经知道的（例如，从我以前的博客文章中 ），不再需要创建一个单独的类，该类使用onApplicationEvent方法实现ApplicationListener以便能够对应用程序事件做出响应（包括来自Spring Framework本身和我们自己的域事件）。 从Spring 4.2开始，添加了对注释驱动的事件侦听器的支持。 在方法级别使用@EventListener就足够了，该方法级别将在@EventListener自动注册相应的ApplicationListener ：

@EventListenerpublic void blogAdded(BlogAddedEvent blogAddedEvent) {externalNotificationSender.blogAdded(blogAddedEvent);}

请注意 ，在事件中使用域对象有明显的缺点，在许多情况下也不是最好的主意。 代码示例中的伪域对象用于不引入不必要的复杂性。

交易绑定事件

简单紧凑。 对于“标准”事件，一切看起来都很不错，但在某些情况下，需要在事务提交（或回滚）之后执行一些操作（通常是异步操作）。 那是什么 是否可以使用新机制？

业务需求

首先，是一个小题外话-业务需求。 让我们想象一下超级精美的博客聚合服务。 每次添加新博客时都会生成一个事件。 订阅的用户可以接收SMS或推送通知。 可以在将博客对象计划保存在数据库中之后发布该事件。 但是，在提交/刷新失败（违反数据库约束，ID生成器出现问题等）的情况下，整个数据库事务都会回滚。 通知破损的愤怒用户会出现在门口……

技术问题

在现代的事务管理方法中，事务是声明式配置的（例如，使用@Transactional批注），并且在事务作用域的结尾（例如，方法的结尾）触发提交。 总的来说，这非常方便，而且出错的可能性要小得多（与编程方法相比）。 另一方面，提交（或回滚）是在代码外自动完成的，因此我们无法以“经典方式”做出反应（即在调用transaction.commit()之后的下一行中的发布事件）。

老学校实施

不可或缺的Tomek Nurkiewicz提出了Spring的一种可能的解决方案（也是一种非常优雅的解决方案）。 它使用TransactionSynchronizationManager来注册当前线程的事务同步。 例如：

@EventListenerpublic void blogAddedTransactionalOldSchool(BlogAddedEvent blogAddedEvent) {//Note: *Old school* transaction handling before Spring 4.2 - broken in not transactional contextTransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {@Overridepublic void afterCommit() {internalSendBlogAddedNotification(blogAddedEvent);}});}

所传递的代码在Spring事务工作流中的适当位置执行（对于这种情况，“恰好”在提交后执行）。

为了提供对非事务上下文中执行的支持（例如，在不关心事务的集成测试用例中），可以将其扩展为以下形式，以确保不会因java.lang.IllegalStateException: Transaction synchronization is not active而失败java.lang.IllegalStateException: Transaction synchronization is not active异常：

@EventListenerpublic void blogAddedTransactionalOldSchool(final BlogAddedEvent blogAddedEvent) {//Note: *Old school* transaction handling before Spring 4.2//"if" to not fail with "java.lang.IllegalStateException: Transaction synchronization is not active"if (TransactionSynchronizationManager.isActualTransactionActive()) {TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {@Overridepublic void afterCommit() {internalSendBlogAddedNotification(blogAddedEvent);}});} else {log.warn("No active transaction found. Sending notification immediately.");externalNotificationSender.newBlogTransactionalOldSchool(blogAddedEvent);}}

在缺少活动交易的情况下，通过进行此更改，可以立即执行提供的代码。 到目前为止，一切正常，但是让我们尝试在Spring 4.2中使用注释驱动的事件侦听器实现相同的目的。

Spring 4.2+实施

除了@EventListener之外，Spring 4.2还提供了另一个注解@TransactionalEventListener 。

@TransactionalEventListenerpublic void blogAddedTransactional(BlogAddedEvent blogAddedEvent) {externalNotificationSender.newBlogTransactional(blogAddedEvent);}

执行可以绑定到标准事务阶段：提交之前/之后，回滚之后或完成之后（提交或回滚）。 默认情况下，只有在事件的边界内发布事件时，它才会处理事件。 在其他情况下，该事件将被丢弃。

为了支持在非事务上下文中的执行，可以使用falbackExecution标志。 如果设置为“ true”，则如果没有事务在运行，则将立即处理事件。

@TransactionalEventListener(fallbackExecution = true)public void blogAddedTransactional(BlogAddedEvent blogAddedEvent) {externalNotificationSender.newBlogTransactional(blogAddedEvent);}

摘要

在Spring 4.2中引入的注释驱动的事件侦听器延续了减少基于Spring（Boot）的应用程序中样板代码的趋势。 无需手动创建ApplicationListener实现，无需直接使用TransactionSynchronizationManager只需一个具有正确配置的注释即可。 硬币的另一面是，找到所有事件侦听器会有些困难，尤其是在我们的整体应用程序中有数十个事件侦听器的情况下（尽管可以很容易地对其进行分组）。 当然，新方法仅是一种选择，它在给定的用例中是否有用。 尽管如此，Spring（Boot）的另一个魔力泛滥到了我们的系统中。 但是也许抵抗是徒劳的？

抵抗是徒劳的吗？
资料来源： http : //en.memory-alpha.wikia.com/wiki/Borg_cube

请注意，Spring Framework 4.2是Spring Boot 1.3的默认依赖项（在编写1.3.0.M5时可用）。 另外，可以在Gradle / Maven中为Spring Boot 1.2.5手动升级Spring Framework版本–在大多数情况下它应该可以使用。

• 可以从GitHub获得代码示例。

顺便说一句，为该博客文章编写示例使我有了使用Spring 4.1中引入的新测试事务管理系统的第一种真正能力（过去，我仅在Spring培训课程中提到过）。 可能，我会尽快写更多有关它的内容。

翻译自: https://www.javacodegeeks.com/2015/10/simpler-handling-of-asynchronous-transaction-bound-events-in-spring-4-2.html