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
Labels
in: transactions status: declined type: bug

Comments

@spring-projects-issues
Copy link

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 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 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 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

@spring-projects-issues spring-projects-issues added type: bug status: declined in: transactions labels Dec 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: transactions status: declined type: bug
Projects
None yet
Development

No branches or pull requests

1 participant