Resolving Duplicate Income Splitting in a Financial System: Transaction Isolation, Spring Propagation, and Redis Lock

The financial system incorrectly split two incoming payments of ¥2000 and ¥3000, resulting in duplicated allocation of the first amount; both single‑payment and multi‑payment scenarios should have produced the same split of ¥2000 and ¥3000.

Initial investigation revealed that the two payments were processed by separate processes, each reading the same "pending" and "allocated" details, leading to a classic dirty‑read problem.

To address concurrency issues, the article reviews MySQL isolation levels—Read Uncommitted, Read Committed, Repeatable Read, and Serializable—highlighting which anomalies each level can prevent.

It then examines Spring's transaction propagation mechanisms, noting that the default PROPAGATION_REQUIRED caused the inner transaction to be ineffective, so the Redis lock only protected the outer transaction, allowing concurrent execution.

Two remediation strategies are proposed:

Change the propagation to PROPAGATION_REQUIRES_NEW so the inner transaction commits independently before the outer transaction releases the lock.

Move the Redis lock outside the transactional method to ensure the lock controls the entire operation.

Code examples illustrate the original and revised implementations, showing the @Transactional annotations and lock usage before and after the changes.

Finally, the article summarizes that proper transaction isolation, correct propagation settings, and appropriate lock placement are essential for preventing dirty reads and ensuring data integrity in high‑concurrency backend systems.