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-projects-issues opened this issue Oct 23, 2017 · 1 comment
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

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-projects-issues
Copy link
Collaborator Author

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.

@spring-projects-issues spring-projects-issues added type: bug A general bug in: data Issues in data modules (jdbc, orm, oxm, tx) status: backported An issue that has been backported to maintenance branches labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.0.1 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants