CODEWITHSUNDEEP
ruby-on-railsconcurrency
Ben
Ben

Reputation: 13615

Rails 3.1 concurrency risks

I am creating a new Rails 3.1 project and I my designs I see some risks for concurrency and I wonder how Rails handles it.

Lets say I have 2 different users (seperate sessions) and several tasks to be assigned on FIFO base (first created task should be assigned first). Both users log in and accept a task. I fear it could be where the same task is assigned to both users or the last one that excecuted the update on task.

Am I being worried about nothing? Does Rails 3.1 handle type of situation this well? Should I solve this in my SQL instead?

Upvotes: 3

Views: 317

Answers (1)

bragboy
bragboy

Reputation: 35542

You need to clearly define your Queuing Logic - in your case assigning the tasks if I am correct. Any concurrent system will definitely have to go through the cycle of acquiring a lock and releasing the lock on the object or entity that is being acted upon. In Rails world, each request you do from the browser is a request which executes in a separate thread or process. They still can race and contend for the resource. So, it is up to you on defining this collision resolution.

One way of doing it would be to use an application variable acquiring a lock and using :synchronize around a method (source).

class SharedCache
  @@lock = Mutex.new
  def expire
    ...
  end
  synchronize :expire, :with => :@@lock
end

Upvotes: 2

Related Questions