Linq to SQL Data Concurrency - Безопасно ли использовать только ПК?

Question

Я получаю сообщение об ошибке на своем веб-сайте MVC, в котором содержится информация о параллелизме данных в Linq to SQL:

"Строка не найдена или изменена"

После прочтения нескольких сообщений здесь это выглядитхотя приемлемым решением является установка для всех полей, не относящихся к первичному ключу, значение UpdateCheck = false в конструкторе dbml.Прежде чем решиться на это, я хотел спросить, потеряю ли я что-нибудь, если сделаю это?

Если честно, мне кажется, что так должно быть всегда, так как использование первичного ключа должно быть самым быстрым способом найти запись в любом случае.Это предполагает, что у вас нет композитных ПК.Я не очень знаком со сценариями параллелизма данных, но я что-то здесь упускаю?

Спасибо за ваше время!

[EDIT]

Спасибо за отзывы ребята!Чтобы дать более подробную информацию, у меня есть конкретный сценарий:

У меня есть таблица Article с несколькими полями (заголовок, содержание, автор и т. Д.).Одним из полей, которое обновляется очень часто (каждый раз, когда кто-либо просматривает статью), является поле популярности, которое увеличивается с каждым кликом.Я увидел исходную ошибку, упомянутую выше, когда обновил текст статьи в базе данных.Затем перешел к этой статье на живом сайте (который пытался обновить поле популярности).

Для начала звучит так, будто мне НЕ нужно использовать общий DataContext.Кроме того, возможно, никогда не смотрите на установку определенных полей на UpdateCheck.При этом, Я определенно не хочу, чтобы популярность статьи не получала обновления из-за некоторой проблемы параллелизма.Так что в таком случае, есть ли способ для меня, чтобы обеспечить это с оптимистичным параллелизмом?

Еще раз спасибо !!

Answer 1

Иногда я изменяю UpdateCheck на Never на всех, кроме первичного (-ых) ключа (-ов) в классах сущностей в конструкторе.Что вы потеряете, так это уведомление о временных изменениях данных с момента их загрузки;то, что вы в конечном итоге, это тип сценария «последнее изменение выигрывает».Если это нормально в вашей ситуации, тогда ... хорошо.

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

Answer 2

установите все поля не первичного ключа в UpdateCheck = false в конструкторе dbml. Прежде чем решиться на это, я хотел спросить, потеряю ли я что-нибудь, если сделаю это?

Задача механизмов параллелизма состоит в том, чтобы запретить нескольким пользователям вносить изменения друг в друга. Пессимистический параллелизм достигает этого, блокируя изменения в записи, когда она читается. Затем разблокируйте запись, когда изменения будут завершены. Оптимистический параллелизм достигает этого, вспоминая, как выглядела запись, когда она читалась, и затем не изменяя запись, если она изменилась.

Linq to Sql использует оптимистический параллелизм . Если вы установите свойство UpdateCheck таким образом, вы отключите оптимистический параллелизм проверка.

Рассмотрим эту запись:

• Клиент (Имя = "Боб", Работа = "Программист", Зарплата = 35000,00)
• LinqToSql DataContext # 1 читает запись
• LinqToSql DataContext # 2 читает запись и фиксирует следующее изменение (Salary = 50000.00)
• LinqToSql DataContext # 1 пытается зафиксировать следующее изменение (Job = "Janitor")

С оптимистичным параллелизмом DataContext # 1 теперь получает исключение параллелизма для разрешения. Без оптимистичного параллелизма у нас теперь есть уборщик, который зарабатывает 50 тыс.