Encountering Race Conditions Despite Using Django's Atomic Transactions and select_for_update

I'm encountering race conditions in my Django application despite implementing atomic transactions and utilizing the select_for_update method. Here's an overview of the problem and the steps I've taken so far:

Problem: I have two Django models, Transaction and Account, where Transaction instances affect the balance of associated Account instances. However, due to the large size of transactions, I'm experiencing race conditions, resulting in false outcomes and incorrect balance updates.

Database Schema:

Transaction:
    id (Primary Key)
    amount
    account_id (Foreign Key referencing Account.id)

Account:
    id (Primary Key)
    balance

Steps Taken

1. Atomic Transactions: I've wrapped the critical sections of my code that involve database operations within Django's atomic transactions using the @transaction.atomic decorator or transaction.atomic context manager.

2. Row-Level Locking: I've utilized the select_for_update method to lock the rows in the Account table during reads, ensuring that concurrent transactions don't interfere with each other's updates.

Despite implementing these measures, I'm still encountering race conditions, leading to incorrect balance calculations and data inconsistency.

Additional Context:

I'm using a PostgreSQL database for my Django application. The race conditions seem to occur when multiple transactions attempt to update the balances of related accounts simultaneously. I've verified that the critical sections of my code are indeed encapsulated within atomic transactions and that select_for_update is applied appropriately.

Question: What additional steps or considerations should I take to mitigate race conditions in my Django application? Are there any common pitfalls or overlooked factors that might be contributing to this issue despite using atomic transactions and row-level locking? Any insights or recommendations would be greatly appreciated.

I found solution is add one validation before actual business logic get execute which check the ownership of account/balance.

Follow these step to avoid race condition:

1. fetch current transaction from account.
2. Lock account for balance transfer using select_for_update
3. Check validation to current transaction is equal to account.transaction.
4. Transfer amount change balance.
5. store current transaction to account.

If initiate multiple transaction then it will lock then validate is that same then only proceed further.

Here is image for better intuition