Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
LINQ to SQL поддерживает оптимистичное управление конкурентностью. В следующей таблице описаны термины, которые применяются к оптимистическому параллелизму в документации по LINQ to SQL:
| Условия | Описание |
|---|---|
| конкурентность | Ситуация, в которой два или более пользователей одновременно пытаются обновить одну и ту же строку базы данных. |
| Конфликт одновременности | Ситуация, в которой два или более пользователей одновременно пытаются отправить противоречащие значения в один или несколько столбцов одного ряда. |
| Управление конкурентностью | Метод, используемый для разрешения конфликтов конкурентности. |
| Управление оптимистическим параллелизмом | Метод, который сначала исследует, изменили ли другие транзакции значения в строке, прежде чем разрешить отправку изменений. Контрастирует с пессимистическим управлением конкурентным доступом, которое блокирует запись, чтобы избежать конфликтов конкурентного доступа. Оптимистичный контроль так называется, потому что считает маловероятным вмешательство одной транзакции в другую. |
| Разрешение конфликтов | Процесс обновления конфликтующего элемента путем повторного запроса к базе данных и последующего согласования различий. При обновлении объекта средство отслеживания изменений LINQ to SQL содержит следующие данные: — Значения, первоначально взятые из базы данных и используемые для проверки обновления. — новые значения базы данных из последующего запроса. Затем LINQ to SQL определяет, находится ли объект в конфликте (т. е. изменяется ли один или несколько его значений-членов). Если объект находится в конфликте, LINQ to SQL следующий определяет, какие из его членов находятся в конфликте. Любой конфликт члена, обнаруженный LINQ to SQL, добавляется в список конфликтов. |
В объектной модели LINQ to SQL конфликт оптимистического параллелизма возникает, когда оба из следующих условий являются истинными:
Клиент пытается отправить изменения в базу данных.
Одно или несколько значений проверки обновления были обновлены в базе данных с момента последнего чтения их клиентом.
Решение этого конфликта включает обнаружение элементов объекта в конфликте, а затем решение о том, что вы хотите сделать с ним.
Замечание
Только члены, сопоставленные как Always или WhenChanged, участвуют в оптимистических проверках параллелизма. Проверка не выполняется для элементов, помеченных Never. Дополнительные сведения см. в разделе UpdateCheck.
Пример
Например, в следующем сценарии User1 начинает подготовку обновления, запрашивая базу данных для строки. User1 получает строку со значениями Альфредс, Мария и Sales.
User1 хочет изменить значение столбца "Менеджер" на Альфреда и значение столбца "Отдел" на "Маркетинг". Прежде чем Пользователь1 сможет отправить эти изменения, User2 отправил изменения в базу данных. Таким образом, теперь значение столбца Помощника изменено на Мэри, а значение столбца Отдела на Служба.
Когда сейчас Пользователь1 пытается отправить изменения, отправка завершается ошибкой ChangeConflictException, и выбрасывается исключение. Этот результат возникает из-за того, что значения базы данных для столбца Помощника и столбца "Отдел" не являются ожидаемыми. Члены, представляющие столбцы Ассистент и Отдел, конфликтуют. В следующей таблице приводится сводка ситуации.
| Государство | Менеджер | Помощник | Отдел |
|---|---|---|---|
| Исходное состояние | Альфредс | Мария | Продажи |
| Пользователь_1 | Альфред | Маркетинг | |
| Пользователь_2 | Мэри | Услуга |
Такие конфликты можно разрешать разными способами. Дополнительные сведения см. в статье "Управление конфликтами изменений".
Контрольный список по обнаружению конфликтов и разрешению конфликтов
Вы можете обнаруживать и разрешать конфликты на любом уровне детализации. В одном крайнем случае можно устранить все конфликты одним из трех способов (см RefreshMode. без дополнительных соображений). В другом крайнем случае можно назначить определенное действие для каждого типа конфликта для каждого члена в конфликте.
Укажите или пересматривайте UpdateCheck параметры в объектной модели.
Дополнительные сведения см. в разделе Как указать, какие элементы тестируются на конфликты параллелизма.
В блоке try/catch вызова SubmitChangesукажите, в какой момент нужно создать исключения.
Для получения дополнительной информации см. в разделе Как указать момент возникновения исключений параллелизма.
Определите, сколько сведений о конфликте требуется получить, и добавьте код в блок try/catch соответствующим образом.
Дополнительные сведения см. в разделе Практическое руководство: Получение сведений о конфликте сущностей и Практическое руководство: Получение сведений о конфликте участников.
Включите в
try/catchкод способ устранения различных обнаруженных конфликтов.Дополнительные сведения см. в статье "Практическое руководство. Устранение конфликтов путем сохранения значений базы данных", "Практическое руководство. Устранение конфликтов путем перезаписи значений базы данных" и "Практическое руководство. Устранение конфликтов путем объединения с значениями базы данных".
LINQ to SQL Types, поддерживающие обнаружение конфликтов и разрешение конфликтов
Классы и функции для поддержки разрешения конфликтов в оптимистическом параллелизме в LINQ to SQL включают следующее: