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

Question

Мы пытаемся предложить нашей команде рекомендуемый шаблон проектирования, когда дело доходит до блокировки записей.Типичная школа мысли звучит примерно так:1.Пользователь выбирает запись из списка 2.Заблокируйте запись с помощью идентификатора пользователя 3.Загрузите заблокированную запись (нет блокировки, значит, кто-то вас опередил).

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

Answer 1

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

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

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

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

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