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