Re:Race conditions on Facebook, DigitalOcean and others (fixed)
by codenut on Monday April 27, 2015 @04:38AM
(#9445018)
Can this issue be prevented if we use the promo code as the table primary key or document ID?
Re:Race conditions on Facebook, DigitalOcean and others (fixed)
by jaysh on Monday April 27, 2015 @05:08AM
(#9445107)
That won't be enough because the promo codes are shared amongst many users. If the promo code became the primary key, then only one user would be able to redeem it.
If you introduced some combination of a user ID and promo code, then it won't prevent a race of one user firing many queries with different promo codes and stacking them up. It would, however, fix the original problem.
Re:Race conditions on Facebook, DigitalOcean and others (fixed)
by some1else on Monday April 27, 2015 @06:03AM
(#9445280)
A simple Discount domain model with validations:
Class Discount
belongs_to :promo_code
belongs_to :customer
belongs_to :order
validates_presence_of :promo_code, :customer, :order
validates_associated :promo_code
validates_uniqueness_of :promo_code_id, :scope => [:customer_id, :order_id]
end
Limiting down to a single Promo-code per order: Class Discount
# ...
validates_uniqueness_of :order_id, :scope => :customer_id
end
Re:Race conditions on Facebook, DigitalOcean and others (fixed)
by gavingmiller on Monday April 27, 2015 @09:57AM
(#9446281)
This right here is the heart of race condition bugs, and is NOT race condition safe. When running multiple web servers and without a "validates_uniqueness_of" constraint on your database, multiple requests hitting multiple different web servers can claim multiple discounts for the same user. Problem only grows as your number of web servers grow!
Re:Race conditions on Facebook, DigitalOcean and others (fixed)
by kawsper on Monday April 27, 2015 @02:24PM
(#9448199)
Read the part "Concurrency and integrity" in the Rails documentation: http://apidock.com/rails/ActiveRecord/Validations/ClassMetho...
You need to enforce the uniqueness in the DB.
1. Code sent.
2. Check if valid.
3. Redeem code.
4. Invalid code.
Now if i send 10 requests at the same time with the same code maybe 4-6 will hit the code part after 2.
And your window of opportunity is the time it takes to go from 3 to 4. Sometimes certain tasks are put inside async queue, you have a slight delay to your database server or you need to wait for db replication to kick in.
Because normally there is no code part to recheck how often this code was used.