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

TransactionalEventListener [SPR-17316] #21849

Closed
spring-projects-issues opened this issue Oct 1, 2018 · 4 comments
Closed

TransactionalEventListener [SPR-17316] #21849

spring-projects-issues opened this issue Oct 1, 2018 · 4 comments
Assignees

Comments

@spring-projects-issues
Copy link
Collaborator

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

clembo590 opened SPR-17316 and commented

When using

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)

public void notificationOnCommit(Data myDataSaved){}

it is possible to receive the event even though the data has not been saved successfully.

I posted an example with the use of normal "``@EventListener"

--> the behaviour is "as expected" because of the use of "TransactionSynchronizationManager.isActualTransactionActive()"

 

my guess is that when using "TransactionalEventListener"

it does not work correctly because in the class "ApplicationListenerMethodTransactionalAdapter" the method "onApplicationEvent" is calling "TransactionSynchronizationManager.isSynchronizationActive()" instead of  "TransactionSynchronizationManager.isActualTransactionActive()"

 


Affects: 5.0.8

Attachments:

@spring-projects-issues
Copy link
Collaborator Author

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

Juergen Hoeller commented

From my point of view, this works as expected since TransactionalEventListener are only really defined along with transaction synchronization and do not provide datastore-level guarantees per se. If you choose to use such a listener with a synchronization-only transaction boundary not backed by a resource transaction, you get plain commit-time synchronization, just like you would when implementing a TransactionSynchronization callback against TransactionSynchronizationManager. Us rejecting such a scenario won't help here in any case; the real solution is to turn your transaction boundary into an actual resource transaction.

@spring-projects-issues
Copy link
Collaborator Author

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

clembo590 commented

First, thank you for your answer.

I updated the attachments with a full project (it only contains the necessary class to test and is very easy).

I have 2 "transaction listener"

one is "old school" and works the way I would expect it to work.

the second is "new school"... and I thought I would be able to replace "old school" by new school and get the same behaviour.... 

 

Can you elaborate a bit more on your answer about turning my transaction boundary into an "actual resource transaction"?

Thank you

 

 

 

 

 

 

@spring-projects-issues
Copy link
Collaborator Author

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

clembo590 commented

@Juergen Hoeller 

it would be great if you can give me just a few more info...

 

@spring-projects-issues
Copy link
Collaborator Author

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

Anthony Vito commented

I was experiencing a similar issue. For me it was caused by using Asynchronous events. It looks like the bit of code that registers a callback on the transaction itself wasn't getting a) run on the same thread or b) run before the transaction was gone. In either or both cases, the method annotated TransactionalEventListener would not be executed.

Dropping back to fully synchronous events resolves the issue. I don't believe TransactionalEventListener supports asynchronous event handling.

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
2 participants
You can’t perform that action at this time.