Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Oct 24, 2018 · 3 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Oct 24, 2018

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 7, 2018

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 7, 2018

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Oct 2, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant