FINERACT-2406: Transaction reprocessing fix

[adamsaghy]

Description

Describe the changes made and why they were made.

Ignore if these details are present on the associated Apache Fineract JIRA ticket.

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per https://github.com/apache/fineract/#pull-requests
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• Submission is not a "code dump". (Large changes can be made "in repository" via a branch. Ask on the developer mailing list for guidance, if required.)

FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.

[galovics]

I think there's one thing missing from this. Whether the annotation is applied to a class/method which is inside a running transaction (IIRC you can use the TransactionSynchronizationManager to check this).

Also, one thing that comes to my mind when combining these kind of things (Transactional and this annotation) is the ordering.

You need to make sure the ordering of this aspect is lower than the transactional annotation's, otherwise you might apply this first then the tx annotation.

[adamsaghy]

I accept the transactionSynchronizationManager one, but i dont think we should mess with the orders. In case "Transactional" annotation is used alongside with WithFlushMode, the only important to use Transactional first.

By default Transactional annotation is using Spring default ordering which is LOWEST_PRECEDENCE, alongside with Retry, Cacheable, etc. which also using this. If i am changing it to use LOWEST_PRECEDENCE-1, it might break all those logic: having retry inside transaction boundary, etc.