Недавно мой коллега Крис Любомански добавил оптимистичную блокировку в одну из наших таблиц в базе данных. До этого я никогда не слышал об этом, но это оказалось очень легко понять. Официальная документация Rails достаточно хорошо объясняет этот тип блокировки.
Rails также позволяет выполнять пессимистическую блокировку таблицы базы данных, но, на мой взгляд, официальная документация по этому типу блокировки немного бедна и не объясняет тему достаточно хорошо.
Вот как я бы объяснил в простых терминах, что делает пессимистическая блокировка: если вы заблокируете запись базы данных в одном потоке (или процессе, неважно) и выполните транзакцию базы данных над этой записью (например, операцию обновления), вы не сможете прочитать/обновить/удалить эту запись из другого потока, пока транзакция в первом потоке выполняется.
Вот пример:
Я получаю первую запись из таблицы people, но предваряю метод .first методом .lock. Из-за этого запрос SELECT имеет в конце оператор FOR UPDATE. Это означает, что извлеченная запись заблокирована, пока выполняется транзакция, связанная с этой записью. Просто, правда?
Убедил ли я вас, что запись будет заблокирована во время транзакции? Скорее всего, нет. Позвольте мне показать пример, который должен вас убедить.
Поскольку эта транзакция выполняется очень быстро, я не смогу показать вам, что запись действительно заблокирована, если не внесу несколько небольших изменений в транзакцию. Я заставлю транзакцию «заснуть» на некоторое время, а затем открою еще одну консоль Rails и попытаюсь получить доступ к заблокированной записи. Вы увидите, что запись действительно блокируется, пока транзакция выполняется в первой консоли Rails. Взгляните:
Видите? Пока транзакция в левой консоли выполнялась, в правой консоли я даже не смог получить заблокированную запись из базы данных. Только после завершения транзакции я смог получить запись.
Надеюсь, этот пример помог вам лучше понять пессимистическую блокировку.
Примечание: я использовал базу данных MySQL.