Skip to content

Conversation

@sidshas03
Copy link
Contributor

Description

This PR fixes the duplicate interest posting issue reported in FINERACT-1659, where the Post Interest job could post interest multiple times for the same savings account within the same posting period.

What changed

  • Added a safeguard in SavingsSchedularInterestPoster to skip accounts where interest has already been posted for the current period, by comparing interestPostedTillDate with the current business date.
  • Updated the transaction isolation level to SERIALIZABLE to prevent duplicate postings caused by race conditions during parallel scheduler runs.

Tests

Added two integration tests to validate the behavior:

  • testPostInterestPreventsDuplicateOnSameDay
    Ensures running the job twice on the same day results in only one interest posting.
  • testPostInterestSkipsCurrentPeriodButAllowsNewPeriod
    Ensures the job skips reposting within the current period, while still allowing postings in a new period.

Expected outcome

  • Running the Post Interest job multiple times within the same posting period will not create duplicate transactions, and the savings account balance remains unchanged after subsequent runs.

private boolean backdatedTxnsAllowedTill;

@Transactional(isolation = Isolation.READ_UNCOMMITTED, rollbackFor = Exception.class)
@Transactional(isolation = Isolation.SERIALIZABLE, rollbackFor = Exception.class)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the SERIALIZABLE here might be better than the READ_UNCOMMITTED, i dont think we are addressing the underlying issue properly.

I would rather recommend a different approach:

  • Is it possible to ensure no two SavingsSchedularInterestPoster got the very same savings account? If we can ensure no two parallel executed postInterest work on the very same savings account, i see no reason why would any double posting and we dont need to enforce SERIALIZABLE isolation which usually means strict and heavy locking of the resource which does not help the performance.

Alternative solution:

  • Is it possible to introduce constraints which ensure no two interest to be posted on the very same date of the very same savings account? We can even build retry strategy too based on this constraints:
  • Read savings account -> post interest -> if fails, refetch the savings account and check again whether interest needed to be posted.

It might go beyond the scope of the original story, but to be frank, this would be the proper way to do it.

TLDR: 1 savings account should be processed by 1 thread entirely and avoid situations where 1 savings account might be processed by many threads.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants