Доступ к информации базы данных в ASP.NET 2.0 - Реализация оптимистичного параллелизма при помощи элемента управления SqlDataSource
ОГЛАВЛЕНИЕ
Реализация оптимистичного параллелизма при помощи элемента управления 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 не были слепо переписаны.
Следующее изображение отображает процесс использования оптимистичного параллелизма.
