On Jan 23, 2013, at 4:03 AM, Gabriel Sobrinho wrote:

> It makes sense!
> 
> I have a debt entity in my application and payments this entity can happen 
> three or more times in parallel (stupid brazilian banks, don't ask me why 
> they do it).
> 
> Since I have to keep a cache column of the paid value for the debt, I have 25 
> workers (sidekiq) that can call `increment!(:paid_value, paid_value)` and it 
> should keep the total paid value.
> 
> I'm not sure if it will be a problem to happen something like that:
> 
> debt.paid_value
> # => 100.0
> 
> debt.increment!(:paid_value, 100.0)
> # => 300.0
> 
> We can have problems if other columns relies on that value.
> 
> Let suppose I have another column called paid_interest and with the 
> paid_value, I get the total paid:
> 
> debt.paid_value
> # => 100.0
> 
> debt.paid_interest
> # => 10.0
> 
> debt.total_paid
> # => 110.0
> 
> debt.increment!(:paid_value, 100.0)
> # => 300.0
> 
> debt.total_paid
> # => 310.0
> 
> The paid_interest in this case is updated in another process.
> 
> It's a contrived example but if that's the case, I will need to reload the 
> entire record to get the right total paid.
> 
> At least some documentation telling that increment and increment! are subject 
> to race conditions is needed.

I believe the suggested solution in this case is to use optimistic locking (via 
a lock_version column) and then handle collisions manually.

--Matt Jones

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-core+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Reply via email to