Подробности, которые могут сделать администрирование вашего решения интенсивным, - избавление от блокировок после сбоев или сбоев подключения. Вот где действительно лежит компромисс между оптимистическим и пессимистическим блокированием. Ручное слияние или повторное редактирование при сбое оптимистической блокировки - это боль, но при сбое после сбоев в моделях пессимистичной и постоянной блокировки возникают свои собственные головные боли (о чем подробно расскажет любой, кто поддерживал пользователей учетных систем с поддержкой Pervasive в 90-х годах, возможность)
Один из ответов - использовать механизмы вашей СУБД для управления транзакциями и параллелизмом: захватить запись с помощью SELECT FOR UPDATE или любого синтаксиса, подходящего вашей среде и уровню изоляции. Если один из ваших клиентов падает или отключается, транзакция откатывается и блокировка снимается.
В среде без установления соединения, такой как сеть или среда, где соединения теряются и часто восстанавливаются, также может работать модель на основе сеанса с тайм-аутом сеанса:
- Попытка очистить существующую блокировку записи, если это сеанс с истекшим сроком
- Попытка заблокировать запись для sessionid (Не удается, если предыдущий шаг не удался)
- Выберите заблокированную запись (в случае неудачи предыдущего шага запись не возвращается)
Таким образом, блокировка освобождается по истечении сеанса. Нет необходимости вручную удалять блокировки после сбоев и некоторый допуск проблем клиента / подключения. Хотя для написания кода требуется немного больше работы.