FINERACT-1659: Add optimistic lock to savings interest posting batch …

[nickus]

…UPDATE

The root cause of duplicate interest postings was fixed in FINERACT-2394 (commit 5281be4), which removed a race condition where both the main thread and a fetchData callable concurrently populated a non-thread-safe ArrayDeque in PostInterestForSavingTasklet.

This commit adds defense-in-depth by wiring the existing @Version column into the raw JDBC batch UPDATE in SavingsSchedularInterestPoster, which bypasses JPA's optimistic lock. The batch UPDATE now includes AND version=? in its WHERE clause and version = version + 1 in SET. If a concurrent modification is detected (updateCounts[i] == 0), the account is skipped and logged rather than double-posted.

Changes:

• SavingsAccountData: add transient version field
• SavingsAccountReadPlatformServiceImpl: select sa.version and extract it in the ResultSetExtractor
• SavingsSchedularInterestPoster: add version check to batch UPDATE, skip accounts with version mismatch, filter downstream operations
• New integration test: testPostInterestJobRunTwiceSameDayNoDuplicate

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 our guidelines
• 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 our 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
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[adamsaghy]

@nickus Please fix the failing checks!

[nickus]

@adamsaghy done

[adamsaghy]

@nickus I dont think this is correct approach... based on this PR you are not ensuring optimistic locking at all for batch updates: if a version is mismatched it must be rolled back and throw an error, i dont see any rollback mechanism at place... all updates that are sent are final....

[awaneetdecoder]

Hi @adamsaghy,
I have opened a new PR that directly addresses your concern about the missing rollback mechanism from PR #5550:
#5671
Key changes:

ConcurrentModificationException thrown on version mismatch instead of silent skip
@transactional on postInterest() automatically rolls back the entire batch

Thank you for the clear feedback!

[Aman-Mittal]

@nickus Are you still working on this ticket? as @awaneetdecoder also working on same ticket.

[nickus]

Hi @Aman-Mittal sorry, I do not have much free time currently to continue this PR so please feel free to continue. I will close it