-
Notifications
You must be signed in to change notification settings - Fork 38.4k
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
NoRollbackFor rule causes TransactionAspectSupport to log unwarranted "exception overridden" error on WebSphere #25253
Comments
I suppose you're running on WebSphere since this only seems to affect the In any case, it is indeed falling over its own feet in the exception handling code path there, that log statement needs to be avoided. We'll also backport this to 5.1.x, 5.0.x and 4.3.x once resolved here. |
Yes, this is on WebSphere. |
Observed using Spring 4.3.26, expecting same behavior from Spring 5.x after code comparison.
The application code throws custom
NoDataFoundException
checked exception in normal conditions to report absence of data, which is then handled outside the transaction. Certainly not the best pattern, but unsolvable for now due to a myriad of possible side effects.To alleviate the issue, we're using
NoRollbackRule
attribute in the form of+NoDataFoundException
onTransactionProxyFactoryBean
like so:This results in
NoDataFoundException
being correctly rethrown outside tx, but still emitting an error log statement like so:Stepping into
invokeWithinTransaction
code, it appears that the checked exception being rethrown is mistaken as a "new" transaction commit exception, overriding... itself.Initial capture of the checked exception:
Rethrowing outside of tx:
Exception re-handled on exit, triggering extraneous logging:
Fixing this situation should be as simple as comparing
ex2
andthrowableHolder.throwable
for equality (in addition to the null check already in place), or resettingthrowableHolder.throwable
tonull
upon rethrowing the checked exception. A PR can be submitted to this effect if requested.A quick workaround would be to disable logging for the
TransactionProxyFactoryBean
, which is unpalatable because of the many other serious error conditions that could go unreported. A more sophisticated patch would apply a targeted logging filter to ignore error entries mentioning the checked exception class.The text was updated successfully, but these errors were encountered: