Rails 3.1 риски параллелизма

Question

Я создаю новый проект на Rails 3.1 и свои проекты вижу некоторые риски для параллелизма и мне интересно, как Rails справляется с этим.

Допустим, у меня есть 2 разных пользователя (отдельные сеансы) и несколько задач, которые должны быть назначены на базе FIFO (первое созданное задание должно быть назначено первым). Оба пользователя входят в систему и принимают задание. Боюсь, это может быть связано с тем, что одна и та же задача назначена обоим пользователям или последней, которая выполнила обновление задачи.

Меня ни о чем не беспокоит? Хорошо ли обрабатывает Rails 3.1 тип ситуации? Я должен решить это в моем SQL вместо этого?

Answer 1

Вам необходимо четко определить свою логику очередей - в вашем случае назначать задачи, если я прав. Любая параллельная система определенно должна пройти цикл получения блокировки и освобождения блокировки объекта или объекта, с которым выполняется действие. В мире Rails каждый запрос, который вы делаете из браузера, является запросом, который выполняется в отдельном потоке или процессе. Они все еще могут мчаться и бороться за ресурс. Таким образом, это зависит от вас, чтобы определить это разрешение конфликта.

Один из способов сделать это - использовать прикладную переменную, получающую блокировку и использующую: синхронизация вокруг метода ( source ).

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