On 20-8-2012 19:37, Thomas Orozco wrote: > Circumvent the problem with smarter design: don't store the money on the > object, make the user's money the sum of all their transactions (credit - > debit). > You get lesser performance, but you also get history!
This does not circumvent the problem but aggravates it. The problem is how to determine if a withdrawal is allowed before doing the withdrawal. Not having the current balance available but instead having to do complex queries on a possibly huge set of rows, increases the chances of transactions being OK'd that should not be when multiple withdrawals are sent in parallel. Alexis has mentioned some options, but the real safeguard is to make current balance field a positive decimal field and propagate this to the database layer by ensuring a constraint is created. Even if two transactions in parallel are working with the same initial balance, the constraint will deny at least one of them. This is also why you should enclose the entire process (add withdrawal to statement, decrease the balance) in a single transaction. Possibly the @transaction.commit_on_success decorator may prove useful. -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
