Управление параллелизмом в веб-приложениях является одной из проблем, которой мы должны уделить немного времени, поскольку из-за характера приложения мы можем обнаружить случаи, когда нескольким пользователям приходится взаимодействовать с тот же пункт.
Само по себе это взаимодействие не является проблемой, реальная проблема возникает, когда после изменения или прикосновения к этому элементу необходимо сохранить данные в базе данных, а затем два или более пользователей хотят одновременно выполнить действие над одним и тем же элементом, там это происходит. где наша логика должна определять поведение, чтобы знать, что является подходящим способом справиться с этим.
Совпадение в базах данных
Как мы объяснили в начале, совпадение - это когда два или более действующих лица работают над элементом в нашем приложении, генерируя действие против базы данных.
Случай совпадения
Проблемы могут возникать, когда изменения противоречат друг другу, например: пользователь A сохранил значение, но пользователь B в то время также изменил и сохранил другое значение в глазах пользователя. Его содержимое не было изменено и в глазах пользователя. B не было ничего, что мешало бы ему сделать его изменение
Этот тип конфликта может бросить тень на производительность нашего приложения в глазах пользователя, поэтому мы должны оценить, будут ли доступные области полезными или не запланированы для параллелизма.
Типы совпадений
Давайте посмотрим на некоторые типы параллелизма. Таким образом, мы можем немного больше понять, какие действия мы можем выполнять в наших приложениях:
Пессимистическое совпадение
Этот подход предполагает, что при использовании базы данных мы предотвращаем блокировку используемого реестра, тем самым предотвращая одновременное изменение значения несколькими пользователями, что приводит к тому, что в веб-среде невозможно использовать его полностью, так как Поскольку состояний нет, мы на самом деле не знаем, был ли блок применен или удален, пока мы не свяжемся с сервером, что приведет к путанице и медленному использованию.
Оптимистичное совпадение
Этот другой подход, с другой стороны, делает что-то более совместимое с сетью, при изменении перед сохранением в базе данных убедитесь, что данные не были изменены с момента чтения, для этого мы проводим сравнение значений реестра и связанного поля, которое имеет временный отпечаток с датой, временем и секундами для большей точности.
Как ASP.NET MVC решает эту проблему?
ASP.NET MVC не поддерживает пессимистический подход, поэтому мы должны работать с оптимистом, для этого мы должны предоставить нашим структурам поля даты, чтобы сохранить время последнего изменения, чтобы мы могли знать, изменилось ли значение позже что мы получили запись и, прежде чем сохранить ее, мы можем получить предупреждение и, таким образом, решить, следует ли перезаписать эти значения.
Давайте посмотрим на небольшой пример кода, как мы могли бы проверить это:
Затем мы отмечаем, что мы проверяем при внесении изменений в базу данных, если поле было изменено после того, как мы сделали чтение, если мы создаем исключение, с этим мы уже можем предпринять соответствующие действия, мы также оставляем место для работы различные исключения, которые могут быть сгенерированы.
Завершая этот урок, мы уже знаем немного больше о параллелизме в базах данных и о том, как решить проблему в ASP.NET MVC .
СТАТЬИ