Mohammad opened SPR-12560 and commented
Exception thrown in TransactionSynchronization's afterComplete method doesn't be propagated back to calling method. Reason is org.springframework.transaction.support.TransactionSynchronizationUtils class invokeAfterCompletion has below implementation -
public static void invokeAfterCompletion(List\
synchronizations, int completionStatus) { if (synchronizations != null) { for (TransactionSynchronization synchronization : synchronizations) { try { synchronization.afterCompletion(completionStatus); } catch (Throwable tsex) { logger.error("TransactionSynchronization.afterCompletion threw exception", tsex); } } } }
Since it is calling multiple synchronizer in a row hence they are eating exception and just logging it(which is clearly written as java doc). I think there should be a way to throw exception so that if required client code can perform some operation.
One solution would be to run afterComplete method in different threads and propagate exceptions with that thread. For programmatic transaction management, we would get know exception (Considering declarative transaction interceptors would not help as control won't come to client code)
Reference question in stackoverflow is - http://stackoverflow.com/questions/27563561/transactionsynchronization-sallow-runtimeexception-that-is-thrown-while-aftercom?noredirect=1#comment43558721_27563561
Affects: 4.0.3
Comment From: spring-projects-issues
Mohammad commented
do we have any resolution date?
Comment From: spring-projects-issues
Bulk closing outdated, unresolved issues. Please, reopen if still relevant.
Comment From: slinstaedt
Yep, still relevant. Only issue is logging level had been decreased to debug, so devs won't even recognised, something went wrong, because in most setup's will filter debug level log messages.
Comment From: sbrannen
@slinstaedt, with which Spring Framework version(s) are you experiencing this?
Comment From: slinstaedt
org.springframework:spring-tx:jar:5.3.18 which should be part of spring boot 2.5.12.
Comment From: KSH-code
it was fixed by https://github.com/spring-projects/spring-framework/pull/30776 so it is included in https://github.com/spring-projects/spring-framework/releases/tag/v6.0.11 and https://github.com/spring-projects/spring-framework/releases/tag/v5.3.29
Comment From: bclozel
Thanks @KSH-code !
While the original issue was more about making that exception available through a callback of some sort, the reason for reopening it is indeed about the logging level.
Closing this issue as a superseded by #30776
Comment From: stefanrybacki
still relevant, logging alone does not help