Confirm that @TransactionalEventListener will work for @Transactional services [DATAGEODE-152]

[spring-projects-issues]

kohlmu-pivotal opened DATAGEODE-152 and commented

When enabling transaction management, it seems the Spring Framework Transaction Management @TransactionalEventListener does not "fire" when a matching transaction phase is reached.

Investigation into this needs to be made to understand what needs to be configured for this functionality to work

---

Affects: 2.0.11 (Kay SR11), 2.1.1 (Lovelace SR1), 2.2 M1 (Moore)

Referenced from: pull request #27

Backported to: 2.2.2 (Moore SR2), 2.1.13 (Lovelace SR13)

[spring-projects-issues]

Anthony Vito commented

We recently ran into the same issue. It appears that "TransactionalEventListener" does not function in an asynchronous event publishing environment. Perhaps that is your issue as well?

[spring-projects-issues]

John Blum commented

Hi Anthony Vito - Thank you for your comments and I am very sorry to hear this problem has affected you as well.

After further analysis, I have determined the cause of the problem to be incomplete resource (i.e. GemFire/Geode cache instance) synchronization with Spring's SynchronizationManager as compared with other SD stores like Spring Data MongoDB, for instance.

I have a plan for addressing this and hope to have resolution on this issue soon.

In the meantime, you can register 1 or more Transaction callbacks directly with either Apache Geode or Pivotal GemFire using SDG's o.s.d.g.CacheFactoryBean or o.s.d.g.client.ClientCacheFactoryBean when creating a GemFire/Geode cache instance in a Spring context by calling the setTransactionListeners(:List) method and implement Apache Geode/Pivotal GemFire's o.a.g.cache.TransactionListener interface.

Once this issue is resolved, then you will no longer need to use the workaround and instead, you may rely on Spring Transaction Event Listener infrastructure.

Again, my apologies for the inconvenience.

[spring-projects-issues]

yozaner1324 commented

After further investigation, it appears that this is not a bug and @TransactionalEventListener works as intended. 

 

In order for the TransactionalEventListener to fire, an event must be published within a transaction (unless fallback is set to true, in which case it will fire the listener even when a transaction is not present); the event is not published automatically by the framework. When explicitly publishing an event from inside a method annotated with @Transactional, the listener fires as expected.

 

This realization was reached after reading this blogpost: https://spring.io/blog/2015/02/11/better-application-events-in-spring-framework-4-2 and this javadoc: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/event/TransactionalEventListener.html#classes--.

 

To verify that this was correct behavior, I setup a quick test using @TransactionalEventListener with Spring Data JPA and saw behavior consistent with that of Spring Data Gemfire.

 

Solution to this ticket should be an addition to documentation to better explain the @TransactionalEventListener annotation