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

WebSphereUowTransactionManager swallows original exception when commit fails for another reason [SPR-16102] #20650

Closed
spring-issuemaster opened this issue Oct 23, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Oct 23, 2017

Alexander Pinske opened SPR-16102 and commented

  • WebSphereUowTransactionManager stores an exception during the execution of a transactional method in UOWActionAdapter.exception
  • it would be rethrown during action.getResult()
  • but not if there is another exception during commit
  • in that case only the latter exception is thrown and the "inner" exception silently ignored

It would be nice if the previous exception could be logged, when it is shadowed by a subsequent commit failure.

Reasoning: We are currently analysing a problem, where a JMS-Publish takes a long time and aborts after some timeout. This is the inner exception. During this time the global transaction is rolled back, which leads to an exception during commit. The behaviour is okay, but we have "lost" the actual cause of the problem.

Of course there are workaround, e.g. using a LoggingInterceptor around the transaction method, but that would log any exception (that will usually still be there after commit/rollback) not only the "shadowed" ones.


Affects: 4.3.11

Referenced from: commits 75a813a, efe943d

Backported to: 4.3.13

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 24, 2017

Juergen Hoeller commented

From the perspective of our code paths, this is also an alignment issue: TransactionAspectSupport has such extra logging of swallowed exceptions for regular PlatformTransactionManager implementations but not for CallbackPreferringPlatformTransactionManager (where it is harder to implement due to the callback nature of the target, with the commit/rollback step automatically applied).

I'll add some extra logging in several places: debug-level when a callback exception is encountered (where we don't know the outcome yet), and error-level when we know it's been shadowed in a rollback case afterwards. We'll also store the original exception as application exception in our TransactionSystemException, like we do for the regular PlatformTransactionManager code path in TransactionAspectSupport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.