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 Exception thrown by TransactionSynchronization#afterCompletion is eaten and there is no way to catch and perform any operation [SPR-12560] #17162 Exception thrown by TransactionSynchronization#afterCompletion is eaten and there is no way to catch and perform any operation [SPR-12560] #17162 spring-projects-issues opened this issue Dec 19, 2014 · 7 comments

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

status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019

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

status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process labels Jul 14, 2023