Оптимистичная блокировка.
Пессимистично сложнее реализовать, и это вызовет проблемы в веб-среде. Какое действие снимет блокировку, закрыв браузер? Оставить сеанс на время? А что если они сохранят свои изменения?
Вы не указываете, какую базу данных вы используете. Сервер MS SQL имеет тип данных временной метки. Это не имеет ничего общего со временем, хотя. Это просто число, которое будет меняться при каждом обновлении строки. Вам не нужно ничего делать, чтобы убедиться, что оно изменилось, вам просто нужно это проверить. Вы можете добиться аналогичных результатов, используя дату / время, которые были изменены в последний раз, как предполагает @KM. Но это означает, что вы должны помнить, чтобы изменить его каждый раз, когда вы обновляете строку. Если вы используете datetime, вам нужно использовать тип данных с достаточной точностью, чтобы гарантировать, что вы не сможете получить значение, не меняющееся, когда оно должно. Например, кто-то сохраняет строку, затем кто-то читает ее, затем происходит другое сохранение, но оставляет измененную дату / время без изменений. Я использовал бы метку времени, если не было необходимости отслеживать дату последнего изменения в записях.
Чтобы проверить это, вы можете сделать так, как подсказывает @KM, и включить его в предложение update where. Или вы можете начать транзакцию, проверить метку времени, если все в порядке, а затем зафиксировать транзакцию, если нет, вернуть код ошибки или ошибку.
Удержание открытых транзакций (как предлагает @le dorfier) похоже на пессимистическую блокировку, но объем заблокированных данных может превышать строку. Большинство RDBM блокируется на уровне страницы по умолчанию. Вы также столкнетесь с теми же проблемами, что и с пессимистической блокировкой.
Вы упоминаете в своем вопросе, что беспокоитесь о конфликтующих обновлениях. Это то, что блокировка обязательно предотвратит. И оптимистическая, и пессимистическая воля при правильном применении предотвратят именно это.