介紹

如您可能已經知道的（例如，從我以前的博客文章中 ），不再需要創建一個單獨的類，該類使用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

總結

以上是生活随笔為你收集整理的在Spring 4.2中更简单地处理异步事务绑定事件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。