News for hackers. Stuff that matters.
Re:Race conditions on Facebook, DigitalOcean and others (fixed) by spdy on Monday April 27, 2015 @04:02AM (#9444895)
Its actually quite simple as example for the promo code the code looks like this:

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.

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.

Re:Race conditions on Facebook, DigitalOcean and others (fixed) by some1else on Monday April 27, 2015 @02:58PM (#9448422)
Therefore the only thing left to do is run the following migration:

  add_index :discounts, [:promo_code_id, :customer_id, :order_id], :unique => true