Ищете рекомендации по блокировке записей в распределенной системе

Деталь, которая может усложнить администрирование вашего решения, - это избавление от блокировок после сбоев или сбоев подключения. Вот где действительно заключается компромисс между оптимистичной и пессимистической блокировкой. Ручное объединение или повторение правок, когда оптимистическая блокировка терпит неудачу, - это боль, но устранение после сбоев в пессимистичных и устойчивых моделях блокировки создает свои собственные головные боли (как вам подробно скажет любой, кто поддерживал пользователей систем учета с повсеместной поддержкой в ​​90-х годах. возможность)

Один из ответов - использовать механизмы вашей СУБД для управления транзакциями и параллелизмом: возьмите запись с помощью SELECT FOR UPDATE или любого другого синтаксиса, который подходит вашей среде и уровню изоляции. Если один из ваших клиентов выходит из строя или отключается, транзакция откатывается и блокировка снимается.

В среде без установления соединения, такой как Интернет, или в среде, где соединения часто теряются и восстанавливаются, модель на основе сеанса с тайм-аутом сеанса также может работать:

• Попытка снять существующую блокировку записи, если она предназначена для сеанса с истекшим сроком действия.
• Попытка заблокировать запись с идентификатором сеанса (завершается неудачно, если предыдущий шаг не удался)
• Выберите заблокированную запись (запись не возвращается, если предыдущий шаг не удался)

Таким образом, блокировка снимается по истечении сеанса. Отсутствие необходимости вручную снимать блокировки после сбоев и некоторая устойчивость к проблемам с клиентом / подключением. Однако для кодирования требуется немного больше работы.