Хранение токенов блокировки записи в ASP.NET
В приложении, над которым я сейчас работаю, несколько пользователей могут захотеть редактировать что-то одновременно, что означает, что нам нужно реализовать оптимистическую блокировку. Однако для этого приложения редактируемый элемент представляет собой научный протокол, который содержит записи из нескольких разных таблиц в базе данных.
Таким образом, мы хотим иметь возможность указать, что весь протокол заблокирован для редактирования одним пользователем, что приводит к моему вопросу: предпочтителен ли этот метод для обработки изменений на уровне базы данных (например, иметь таблицу с уникальный идентификатор протокола и проверьте, не заблокирован ли он) или будет ли принято отслеживать текущие заблокированные протоколы на самом веб-сервере в памяти?
В настоящее время мы ожидаем только около 100 пользователей (около 20 одновременно) для приложения, но это число может увеличиться в будущем, поэтому мы стремимся использовать наиболее масштабируемый вариант.
3 ответа
Этот вопрос также действительно зависит от того, насколько хорошо спроектирована ваша кодовая база?
Если все вызовы для изменения этих записей проходят через одну точку входа, тогда да, я рекомендую хранить весь код блокировки целиком в вашем приложении, чтобы вы могли хранить свою базу данных в качестве тупого хранилища данных.
Если у вас есть несколько точек входа, которые могут изменять ваши таблицы, вам потребуется реализовать блокировку на уровне базы данных.
Я бы внедрил таблицу в базе данных, которая управляла блокировкой. Например:
Строки: ProtocolID, EditingBeginDate, EditingEndDate
Затем вы можете просто запросить, когда выполняется попытка редактирования в приложении, и если данный протокол не имеет завершенного периода времени, тогда вы знаете, что он все еще редактируется данным пользователем. Вы можете установить определенный период времени, в течение которого сеансы редактирования должны быть закрыты, чтобы предотвратить постоянную блокировку записей. Просто предложение:-D
Итак, кажется, вам нужны грубозернистые замки.
Если вы хотите иметь наиболее масштабируемое решение, вам нужно хранить информацию о блокировке либо в базе данных, либо в распределенном кэше (распределенный кеш будет быстрее в этом случае). Подход в оперативной памяти вообще не масштабируется - он потерпит неудачу, если вам потребуется больше серверов. Не забудьте также ввести тайм-ауты блокировки, чтобы предотвратить возможные тупики.