Реализация оптимистичного параллелизма при помощи элемента управления SqlDataSource
Благодаря мастеру Data Source элемента управления SqlDataSource реализация элемента управления оптимистичным параллелизмом очень проста. Вы можете автоматически сгенерировать выражения INSERT, UPDATE и DELETE нажав кнопку Advanced в мастере Data Source и выбрав пункт "Generate INSERT, UPDATE, and DELETE statements". В дополнение к опции "Generate INSERT, UPDATE, and DELETE statements", диалоговое окно опции Advanced SQL Generation (Расширенная генерация SQL) также включает в себя опцию с названием "Use optimistic concurrency" (Использовать оптимистичный параллелизм).Отметьте ее для получения возможности использования данной опции.
Активировация оптимистичного параллелизма обновляет оператор WHERE выражений UPDATE и DELETE элемента SqlDataSource таким образом, что он включает в себя параметр, названный @original_ColumnName. К примеру, при создании элемента управления SqlDataSource, возвращающего поля ProductID, ProductName, UnitPrice и Discontinued из таблицы Products базы данных Northwind, будет сгенерировано следующее выражение UPDATE:
UPDATE [Products] SET
[ProductName] = @ProductName,
[UnitPrice] = @UnitPrice,
[Discontinued] = @Discontinued
WHERE [ProductID] = @original_ProductID AND
[ProductName] = @original_ProductName AND
[UnitPrice] = @original_UnitPrice AND
[Discontinued] = @original_Discontinued
Без оптимистичного параллелизма оператор WHERE содержал бы : WHERE [ProductID] = @ProductID. Активировав оптимистичный параллелизм вы добавляет дополнительные проверки к стандартным значениям других колонок, возвращаемых запросом SELECT.
При использовании оптимистичного параллелизма с редактируемым элементом управления данными элемент управления запоминает начальные значения при загрузке интерфейса редактирования. К примеру, возьмем GridView. Когда пользователь нажимает кнопку редактирования (Edit), GridView запоминает значения, загруженные в интерфейс редактирования. Данные значения затем будут загружены в параметры @original_ColumnName в момент нажатия кнопки обновления (Update) табличной сетки.
Для того, чтобы увидеть это в действии, давайте вернемся к нашему примеру с менеджерами A и B, но на этот раз представьте то, что был активирован оптимистичный параллелизм. Когда менеджер A нажмет кнопку редактирования для товара Scott's Tea, GridView запомни, что ProductName равен "Scott's Tea", UnitPrice равно $5.00 и то что Discontinued равно False. Аналогично в случае, когда B нажмет кнопку редактирования, GridView запомнит те же самые детали.
После того, как менеджер B отметит опцию Discontinued (убрать товар из списка предлагаемых) и нажмет кнопку обновления Update, вышеуказанное выражение UPDATE будет послано в базу данных . Выражение UPDATE (обладающее сохраненными данными), будет выглядеть следующим образом:
UPDATE [Products] SET
[ProductName] = "Scott's Tea",
[UnitPrice] = 5.00,
[Discontinued] = True
WHERE [ProductID] = 3 AND
[ProductName] = "Scott's Tea" AND
[UnitPrice] = 5.00 AND
[Discontinued] = False
Поскольку информация в базе данных совпадает с информацией, хранимой в GridView, то оператор WHERE возвратит одну запись и эта запись будет обновлена.
Когда менеджер A изменит цену на $15.00 и нажмет кнопку обновления, следующее выражение UPDATE (обладающее значениями параметров) будет послано базе данных:
UPDATE [Products] SET
[ProductName] = "Scott's Tea",
[UnitPrice] = 15.00,
[Discontinued] = False
WHERE [ProductID] = 3 AND
[ProductName] = "Scott's Tea" AND
[UnitPrice] = 5.00 AND
[Discontinued] = False
Оператор WHERE не возвратит никаких записей, потому что запись, в которой ProductID равно 3, будет иметь значение Discontinued, установленное в значение True (обновленное ранее менеджером B). Поэтому изменения, сделанные менеджером A, не будут осуществлены ни для единой записи. Ничего не будет изменено в базе данных, поскольку оригинальные значения и текущие значения не совпали, там самым означая то, что в то время как менеджер A осуществлял изменения, другой пользователь также изменял информацию. Вкратце, изменения, сделанные менеджером A, были утеряны, но хорошей новостью является то, что изменения менеджера B не были слепо переписаны.
Следующее изображение отображает процесс использования оптимистичного параллелизма.
