Handle account balance during concurrent transactions - concurrency

Question

I've been developing an application that handles accounts and transactions made over all the accounts.
Currently the MariDB database table the application uses is modeled the following way:
id column in account_transaction is primary key and it will auto increment
account_transaction
+------+-------------+----------------------+---------+------------------+-----+
| id | account_id | date | value | resulting_amount | ... |
+------+-------------+----------------------+---------+------------------+-----+
| 101 | 100 | 03/may/2012 10:13:33 | 2000 | 2000 | ... |
| 102 | 100 | 03/may/2012 10:13:33 | 500 | 2500 | ... |
| 103 | 100 | 03/may/2012 10:13:34 | -1000 | 1500 | ... |
| 104 | 200 | 03/may/2012 10:13:35 | 1300 | 1300 | ... |
| 105 | 200 | 03/may/2012 10:13:36 | 200 | 1500 | ... |
| 106 | 200 | 03/may/2012 10:13:37 | -500 | 1000 | ... |
+------+-------------+----------------------+---------+------------------+-----+
The query to credit the amount 300 to the account_id (100) the query is
INSERT INTO account_transaction (account_id,date, value, resulting_amount)
VALUES (100, NOW(), 300, COALESCE((SELECT at.resulting_amount
FROM account_transaction at
WHERE at.account_id = 100
ORDER BY at.date DESC, at.id DESC
LIMIT 1), 0) + 300)
The query to debit the amount 300 to the account_id (100) the query is
INSERT INTO account_transaction (account_id,date, value, resulting_amount)
VALUES (100, NOW(), -300, COALESCE((SELECT at.resulting_amount
FROM account_transaction at
WHERE at.account_id = 100
ORDER BY at.date DESC, at.id DESC
LIMIT 1), 0) - 300)
I am using sub query to find latest balance while inserting new transaction. I have used coalesce if there are no transactions for the account.
I could have ran the below subquery separately to find the current balance of the account and use it in the new transaction but the problem is multiple concurrent transactions are reading same balance which leads to account balance discrepancy and it is loss to the company.So I have written the subquery inside insert query to avoid balance discrepancy
SELECT at.resulting_amount
FROM account_transaction at
WHERE at.account_id = 100
ORDER BY at.date DESC, at.id DESC
LIMIT 1
Subquery inside insert query approach was able to handle balance discrepancy if concurrent requests are lesser than 50.
If number of transactions are more than 50 then balance discrepancy is occurring some times.
Example of balance discrepancy: If account balance is 1000 and if 2 concurrent transactions wants to debit 100 then resulting_amount for both transactions would be 900 which is incorrect.
Please suggest better approach to handle balance discrepancy when large number concurrent transactions are placed. If you want to suggest locks approach then use column level lock (lock account_id column).

Answer 1

The easy answer is don't keep resulting_amount in the transaction table, just a balance in a separate table (with primary key account_id).
Or do that and in a transaction update the account balance and use the new balance as the resulting_amount to insert.
Your existing code just assumes ORDER BY at.date DESC, at.id DESC will always find the most recently inserted record, and that isn't going to hold true with concurrent requests.