Если я прав, кажется, что вы говорите о форме рабочего процесса в стиле проверки / редактирования / регистрации. Вы хотите, чтобы когда один пользователь редактировал запись, другие пользователи не могли даже начать редактировать эту же запись.
Это форма пессимистического параллелизма. Многие веб-среды и структуры доступа к данным поддерживают (1003 * * оптимистический параллелизм), связанный с ними - то есть они сообщат вам, что кто-то другой уже изменил запись, когда вы пытались сохранить. На самом деле Optimistic не имеет понятия о блокировке - он гарантирует, что ни один другой пользователь не сэкономит между временем загрузки и сохранением.
То, что вы хотите, не является простым требованием в Интернете, поскольку сервер действительно не имеет возможности принудительно установить регистрацию, когда пользователь прерывает редактирование (скажем, закрывая браузер). Мне не известны какие-либо фреймворки, которые бы справились с этим вообще.
В основном вам нужно хранить информацию о проверке на сервере. Пользовательский процесс при редактировании должен будет запросить извлечение, а сервер предоставит / отклонит это на основании того, что они проверяют. Сервер также должен содержать информацию о том, что ресурс извлечен. Когда пользователь сохраняет данные, сервер снимает блокировку и разрешает новую проверку по запросу. Проблема возникает, когда пользователь прерывает редактирование - если это через пользовательский интерфейс, нет проблем ... просто скажите серверу снять блокировку.
Но если это происходит через закрытие браузера, выключение компьютера и т. Д., Значит, у вас есть сиротская блокировка. Большинство людей решают эту проблему одним из двух способов:
1. Тайм-аут. Замок в конечном итоге будет снят. Плюсом здесь является то, что это довольно легко и надежно. Недостатком является то, что запись заблокирована на некоторое время, когда она не редактируется. И вы должны сделать свой тайм-аут достаточно длинным, чтобы, если пользователю потребовалось действительно очень много времени для сохранения, он не получил ошибку, потому что тайм-аут блокировки (и он должен начать заново).
2. Сердцебиение. Пользователь периодически отправляет пинг обратно на сервер, чтобы сказать «да, все еще редактирую». Это, в основном, вариант тайм-аута из # 1, но с очень коротким тайм-аутом, который может быть обновлен по требованию. Плюс в том, что вы можете сделать его произвольно коротким. Недостатком является повышенная сложность и использование сети.
Токены регистрации / извлечения действительно не так сложны в реализации, если у вас уже есть транзакционное постоянное хранилище (например, БД): сложная часть - интеграция его в ваш пользовательский опыт.