-
Notifications
You must be signed in to change notification settings - Fork 37.8k
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
Detect invalid transaction configuration for transactional event listeners #30679
Comments
Good point, the check seems too restrictive now. I'll revise it to be lenient towards REQUIRES_NEW. |
AbstractTransactionManagementConfiguration.transactionalEventListenerFactory() creating a RestrictedTransactionalEventListenerFactory now. See gh-30679
I'm inclined to enforce |
Problem
It's common practice to use a simple (no custom attributes)
@Transactional
on methods to execute them wrapped in a transaction. Unfortunately, for methods declared as@TransactionalEventListener
, this doesn't work as expected:Those methods are invoked in the transaction cleanup phase of an original, other transaction. This means that this particular, other transaction is still running, although in an undefined state. With a simple
@Transactional
declared on those methods, the code would be executed in an undefined transactional state. An obvious solution to this problem is to declare aPropagation
ofREQUIRES_NEW
on the listener method, so that it will run in a new transaction:Proposed solution
It would be nice if the erroneous arrangement shown above would be rejected, ideally at bootstrap (potentially even AOT?) time. We have to consider that a plain
@Transactional
is still valid in the case of the method declared to be invoked asynchronously (using@Async
). In other words, a declaration like this is still valid, as the asynchronous invocation triggers the execution on a separate thread and thus a clean slate regarding transactions.The text was updated successfully, but these errors were encountered: