@TransactionalEventListener cannot work with TaskExecutor

[weaselmetal]

Affects: Spring 4.2

I came to believe that a @TransactionalEventListener cannot work with a applicationEventMulticaster bean that uses a taskExecutor that invokes the listener call in a new / different thread.
Inside a new thread, which cannot be transaction synchronized in my understanding, the call to the listener will be discarded, unless the @TransactionalEventListener(fallbackExecution = true) is set. So, proper coupling to a transaction seems to be impossible.

Should you desire a true asynchronous invocation on other event handlers, you will have to provide a task executor that delegates the invocation to different threads.

JavaDoc doesn't indicate that @TransactionalEventListener cannot work with a non-synchronous task executor in place. But, I might be doing something wrong after all.
As far as I can tell, the code in spring-tx library behaves as it should, but can only work when no task executor is used at all in the event multicaster, or an executor like org.springframework.core.task.SyncTaskExecutor is used.

[snicoll]

What TransactionPhase do you use for this?

[weaselmetal]

I wanted to use BEFORE_COMMIT, but I believe that doesn't matter. Only fallbackExecution = true will have my event handler invoked. I made sure that the event is fired from within a transactional scope.

[snicoll]

I wanted to use BEFORE_COMMIT, but I believe that doesn't matter.

It does matter. A transaction, in essence, is request (thread-) scoped. If you run in the BEFORE_COMMIT propagation phase, you must be running in the transaction and you can't do that in a separate thread.

[weaselmetal]

Then I won't argue :D.
What I'm quite certain about is that in org.springframework.transaction.event.ApplicationListenerMethodTransactionalAdapter#onApplicationEvent
for a new thread from a task executor the TransactionSynchronizationManager.isSynchronizationActive() won't evaluate to true. At least that's what I debugged.

[snicoll]

Yes, it won't, for the reason I've exposed (the context, in the new thread, does not have a transaction at all). Considering that you should be able to impact the transaction at that phase, I am going to close this issue now.

[weaselmetal]

Wow, that was quick. What you say makes sense. What I was trying to say, though, is:
I would have to create my own applicationEventMulticaster bean, that ensures that any event handler is invoked on the very same thread, as the one that raises the event. I could do so by either not setting any task executor, or a task executor like SyncTaskExecutor.
If that's how it's supposed to be, then at least the documentation should point into that direction.
To me, it doesn't appear that the idea is that I create a applicationEventMulticaster (or a similar) bean, because the creation of that bean is pretty baked into the framework initialization.

[snicoll]

The default behaviour is to invoke events on the same thread so if you don't do anything you'll get the expected result.

I could do so by either not setting any task executor

I am not sure what you mean by that but if you are configuring the event multicaster yourself and you want to be able to handle transactional events, then, yes, it must run on the same thread.