3 ms·
> Also, consider storing the transactions that change the balances (credits, debits, etc) in a ledger and calculate the balance. You can avoid the complex updat
by amw-zero 3y ago
> Also, consider storing the transactions that change the balances (credits, debits, etc) in a ledger and calculate the balance. You can avoid the complex update logic and keep your accountants and auditors happy.
This was written (to me) as if using a ledger alone would get rid of the race conditions caused by the read committed isolation level.
But what you described is manually implementing locking, which requires additional schema and application logic.
- stetrain 3y agoOptimistic concurrency and a ledger lets you do those checks without locking any rows and you don’t have multiple processes fighting to update a single row. Instead of leaving an AccountBalance row locked for the entirety of the Withdrawal process, you have a condition on the insert and a retry mechanism if that insert fails. You still have to implement concurrency logic, it’s just less likely to have the database isolation be your bottleneck.