Хранение токенов блокировки записи в ASP.NET

Question

В приложении, над которым я сейчас работаю, несколько пользователей могут захотеть редактировать что-то одновременно, что означает, что нам нужно реализовать оптимистическую блокировку. Однако для этого приложения редактируемый элемент представляет собой научный протокол, который содержит записи из нескольких разных таблиц в базе данных.

Таким образом, мы хотим иметь возможность указать, что весь протокол был заблокирован для редактирования одним пользователем, что приводит к моему вопросу: предпочтительный способ сделать это - обработать изменения на уровне базы данных (например, иметь таблицу с уникальным идентификатором протокола и проверьте, не заблокирован ли он) или будет ли принято отслеживать в настоящий момент заблокированные протоколы на самом веб-сервере в памяти?

В настоящее время мы ожидаем около 100 пользователей (не более 20 одновременно) для приложения, но в будущем это число может увеличиться, поэтому мы стремимся использовать наиболее масштабируемый вариант.

Answer 1

Этот вопрос также действительно зависит от того, насколько хорошо спроектирована ваша кодовая база?

Если все вызовы для изменения этих записей проходят через одну точку входа, тогда да, я рекомендую хранить весь код блокировки целиком в вашем приложении, чтобы вы могли хранить свою базу данных в качестве хранилища данных.

Если у вас есть несколько точек входа, которые могут изменять ваши таблицы, вам потребуется реализовать блокировку на уровне базы данных.

Answer 2

Я бы внедрил таблицу в базе данных, которая управляла блокировкой. Например:

Строки: ProtocolID, EditingBeginDate, EditingEndDate

Затем вы можете просто запросить, когда выполняется попытка редактирования в приложении, и если данный протокол не имеет завершенного периода времени, то вы знаете, что он все еще редактируется данным пользователем. Вы можете установить определенный период времени, в течение которого сеансы редактирования должны быть закрыты, чтобы предотвратить постоянную блокировку записей. Просто предложение: -D

Answer 3

Итак, похоже, вам нужны крупнозернистые замки.

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