-
-
Notifications
You must be signed in to change notification settings - Fork 671
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Withdrawal Concurrency #219
Comments
Hi @jasoneisen, Thanks for pointing it out! At this time there is not transaction between reading the balance and updating it. One possible approach is to change the current Unit Of Work to include a transaction scope for the reading and update repositories. Would you suggest a particular approach? I am interested into implementing it. |
A transaction could be one approach for pessimistic concurrency control. Off the top of my head, another option would be using EF Core's |
I do not see any guard or pattern that ensures that two withdrawals occurring at the same instant will fail one if the first to commit sends the balance to zero. The current implementation appears to be a common read/compare/write without regard to any other debits that may be in flight.
Is this intended or out of scope for this project? This is a somewhat non-trivial but very common use case that I think this project could further shine in by showing one or more best practices and the impact on architecture.
The text was updated successfully, but these errors were encountered: