Алгоритм работы при оптимистической блокировке, несложен:
1. В таблицу базы данных добавляется новый столбец под названием «версия».
2. Прежде чем пользователь изменит строку, он должен считать номер версии.
3. Когда пользователь обновляет строку, номер версии увеличивается на 1.
4. В процессе проводится проверка базы данных; номер следующей версии должен превышать текущий номер на 1. Транзакция прерывается, если проверка не пройдена, и пользователь возвращается к шагу 2.
Оптимистическая блокировка обычно быстрее, чем пессимистическая, потому что мы не блокируем базу данных. Однако производительность оптимистической блокировки резко падает при большом количестве параллельных запросов.
Вот пример, рассмотрим случай, когда несколько клиентов одновременно пытаются забронировать номер в гостинице. Поскольку нет ограничений на количество клиентов, которые могут получить доступ к количеству доступных комнат, все они считывают одно и то же количество доступных комнат и текущий номер версии. Когда несколько клиентов делают бронирование, в ходе которого записывается информация в базу данных, только один из них добьется успеха, а остальные клиенты получат сообщение об ошибке проверки версии («Увы данный номер уже забронирован :(»). Эти клиенты должны повторить попытку. В последующем раунде повторных попыток снова есть только один успешный клиент, а остальные опять должны повторить попытку. Несмотря на то, что конечный результат правильный (имеется в виду что мы избегаем конфликтов в БД), повторные попытки вызывают очень неприятный пользовательский опыт.
