У меня есть действительно простое приложение направляющих, которое позволяет пользователям регистрировать свое присутствие на ряде курсов. Модели ActiveRecord следующие:
class Course < ActiveRecord::Base
has_many :scheduled_runs
...
end
class ScheduledRun < ActiveRecord::Base
belongs_to :course
has_many :attendances
has_many :attendees, :through => :attendances
...
end
class Attendance < ActiveRecord::Base
belongs_to :user
belongs_to :scheduled_run, :counter_cache => true
...
end
class User < ActiveRecord::Base
has_many :attendances
has_many :registered_courses, :through => :attendances, :source => :scheduled_run
end
Экземпляр ScheduledRun имеет конечное число в наличии мест, и после того как предел достигнут, больше присутствия не может быть принято.
def full?
attendances_count == capacity
end
attendances_count является встречным столбцом кэша, содержащим число ассоциаций присутствия, созданных для конкретной записи ScheduledRun.
Моя проблема состоит в том, что я не полностью знаю корректный способ гарантировать, что состояние состязания не происходит, когда 1 или более человек пытаются зарегистрироваться для последнего доступного места на курсе одновременно.
Мой контроллер Присутствия похож на это:
class AttendancesController < ApplicationController
before_filter :load_scheduled_run
before_filter :load_user, :only => :create
def new
@user = User.new
end
def create
unless @user.valid?
render :action => 'new'
end
@attendance = @user.attendances.build(:scheduled_run_id => params[:scheduled_run_id])
if @attendance.save
flash[:notice] = "Successfully created attendance."
redirect_to root_url
else
render :action => 'new'
end
end
protected
def load_scheduled_run
@run = ScheduledRun.find(params[:scheduled_run_id])
end
def load_user
@user = User.create_new_or_load_existing(params[:user])
end
end
Как Вы видите, это не принимает во внимание, где экземпляр ScheduledRun уже достиг способности.
Любая справка на этом значительно ценилась бы.
Обновление
Я не уверен - ли это правильный способ выполнить оптимистическую блокировку в этом случае, но здесь - то, что я сделал:
Я добавил два столбца к таблице ScheduledRuns -
t.integer :attendances_count, :default => 0
t.integer :lock_version, :default => 0
Я также добавил метод к модели ScheduledRun:
def attend(user)
attendance = self.attendances.build(:user_id => user.id)
attendance.save
rescue ActiveRecord::StaleObjectError
self.reload!
retry unless full?
end
Когда модель Attendance сохраняется, ActiveRecord идет вперед и обновляет встречный столбец кэша на модели ScheduledRun. Вот вывод журнала, показывающий, где это происходит -
ScheduledRun Load (0.2ms) SELECT * FROM `scheduled_runs` WHERE (`scheduled_runs`.`id` = 113338481) ORDER BY date DESC
Attendance Create (0.2ms) INSERT INTO `attendances` (`created_at`, `scheduled_run_id`, `updated_at`, `user_id`) VALUES('2010-06-15 10:16:43', 113338481, '2010-06-15 10:16:43', 350162832)
ScheduledRun Update (0.2ms) UPDATE `scheduled_runs` SET `lock_version` = COALESCE(`lock_version`, 0) + 1, `attendances_count` = COALESCE(`attendances_count`, 0) + 1 WHERE (`id` = 113338481)
Если последующее обновление происходит с моделью ScheduledRun, прежде чем новая модель Attendance будет сохранена, это должно инициировать исключение StaleObjectError. В которой точке, все это повторено снова, если способность не была уже достигнута.
Обновление № 2
При следовании за ответом @kenn вот обновленный, посещают метод на объекте SheduledRun:
# creates a new attendee on a course
def attend(user)
ScheduledRun.transaction do
begin
attendance = self.attendances.build(:user_id => user.id)
self.touch # force parent object to update its lock version
attendance.save # as child object creation in hm association skips locking mechanism
rescue ActiveRecord::StaleObjectError
self.reload!
retry unless full?
end
end
end
Оптимистическая блокировка - это то, что нужно, но, как вы уже могли заметить, ваш код никогда не вызовет ActiveRecord::StaleObjectError, поскольку создание дочерних объектов в ассоциации has_many пропускает механизм блокировки. Посмотрите на следующий SQL:
UPDATE `scheduled_runs` SET `lock_version` = COALESCE(`lock_version`, 0) + 1, `attendances_count` = COALESCE(`attendances_count`, 0) + 1 WHERE (`id` = 113338481)
Когда вы обновляете атрибуты в объекте parent, вы обычно видите следующий SQL:
UPDATE `scheduled_runs` SET `updated_at` = '2010-07-23 10:44:19', `lock_version` = 2 WHERE id = 113338481 AND `lock_version` = 1
Приведенный выше оператор показывает, как реализована оптимистическая блокировка: Обратите внимание на lock_version = 1
в предложении WHERE. Когда возникает состояние гонки, параллельные процессы пытаются выполнить именно этот запрос, но только первый из них преуспевает, потому что первый атомарно обновляет lock_version до 2, а последующие процессы не смогут найти запись и вызовут ActiveRecord::StaleObjectError, поскольку та же запись уже не имеет lock_version = 1
.
Итак, в вашем случае возможным обходным решением является касание родителя непосредственно перед созданием/уничтожением дочернего объекта, например, так:
def attend(user)
self.touch # Assuming you have updated_at column
attendance = self.attendances.create(:user_id => user.id)
rescue ActiveRecord::StaleObjectError
#...do something...
end
Это не предназначено для строгого предотвращения условий гонки, но практически это должно работать в большинстве случаев.
Разве вам не нужно просто проверить, если @run.full?
?
def create
unless @user.valid? || @run.full?
render :action => 'new'
end
# ...
end
Edit
Что если вы добавите валидацию типа:
class Attendance < ActiveRecord::Base
validate :validates_scheduled_run
def scheduled_run
errors.add_to_base("Error message") if self.scheduled_run.full?
end
end
Она не сохранит @attendance
, если связанный scheduled_run
заполнен.
Я не тестировал этот код... но думаю, что все в порядке.