If we get an exception, but the transaction completed, log to indicate we rolled back the transaction, but do not re-throw the exception. If the transaction did not complete, then throw the exception as there was likely an infrastructure failure and this listener needs to retry.
Comment From: drewtul
@jhoeller Given your thoughts on #1778 I thought this might be a better more generic approach for handling exceptions on transaction manager commit to avoid recycling listeners unless the exception was fatal from the transaction managers perspective i.e. it failed to complete the transaction.
Comment From: drewtul
@jhoeller Did you have any further thoughts about this issue and this PR changing the exception handling to throw less infrastructure failure exceptions when the transaction completed with a rollback?
Comment From: jhoeller
Revisit this topic, I've arrived at a straightforward change where we can process non-TransactionExceptions from transactionManager.commit as listener exceptions instead of infrastructure exceptions, assuming that they are typically late-triggered persistence exceptions from a listener-used resource (and therefore to be handled like similar exceptions coming out of the listener invocation itself).
I'll repurpose this PR ticket for the specific purpose suggested but with a custom commit of mine that aligns it with listener exception processing. Thanks for raising the pull request, in any case - and sorry that it took so long to act here.
Comment From: drewtul
Thanks for coming back to this! Hopefully it fixes the problem, I'm no longer working on the project in question so can't test I'm afraid.