Доступ к информации базы данных в ASP.NET 2.0 - Использование оптимистичного параллелизма

Использование оптимистичного параллелизма

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

Данное поведение обоснованно для приложений, где в редких случаях пользователи могут работать с одной и той же информацией. Если пользователи чаще всего работают с одной и той же информацией, то вам необходимо продумать реализацию какого-либо элемента управления параллелизмом (concurrency control). Существует два типа таких элементов: оптимистичные и пессимистичные. Оптимистичные элементы предполагают то, что нарушения параллелизма происходят не так часто, и в случае возникновения стоит попросить одну из сторон повторить ввод информации. Пессимистичная конкуренция реализует политику обеспечения  предотвращения нарушений параллелизма. Данные политики могут в результате дать противоречия в введенной пользователем информации.

Microsoft предлагает некоторую форму элемента управления оптимистичным параллелизмом из элемента SqlDataSource, который может быть активирован, если отметить кнопку с независимой фиксацией (checkbox). Данная статья рассматривает различные типы элементов управления параллелизмом, а затем демонстрирует реализацию встроенного элемента управления оптимистичным параллелизмом, который предоставляет SqlDataSource. Читайте далее, чтобы узнать больше об этом!

Необходимость в элементе управления параллелизмом

До того, как мы начнем рассматривать возможности элемента управления параллелизмом, и применим функциональность встроенного в SqlDataSource  элемента управления оптимистичным параллелизмом, давайте сначала уделим немного внимания обсуждению необходимости в данном элементе.

Представьте себе веб-приложение интернет-магазина, обладающее интерфейсом администратора, который представляет собой редактируемый элемент GridView, где менеджеры могут изменить название продукта, цену и статус скидки на инвентарь. Допустим, что компания следует правилу, согласно которому товар, дешевле $5.00, не должен быть в продаже. Теперь представьте двух менджеров, которые, посетив страницу с двух разных компьютеров, замечают, что товар "Scott's Tea" стоит дешевле $5.00. Первый менеджер, увидев это, может понять, что была допущена ошибка, и что на самом деле цена должна быть $15.00. Он нажимает на кнопку редактирования (Edit) и изменяет цену. В это же время другой менеджер посещает страницу и, увидев цену ниже $5.00, согласно правилу компании, решает убрать товар с прилавка. Нажав кнопку редактирования (Edit), он начинает совершать необходимые изменения.

Так что же мы получим в конце концов? Будет ли товар "Scott's Tea":

• отмечен как недоступный из-за цены ниже $5.00,
• иметь цену в $15.00 и не быть недоступным, или
• быть недоступным, при этом стоить $15.00?

Элементы управления SqlDataSource и GridView по умолчанию работают таким образом, что обновляются все редактируемые поля, вне зависимости от того, были ли они отредактированы пользователем, или нет. Это означает, что мы можем быть уверены в том, что последний вариант нереален. Тем самым тот менеджер, который сохранит свои изменения последним, перепишет изменения, сделанные до данного момента. Следующий рисунок демонстрирует данные действия, когда менеджер A - тот, кто  меняет цену на $15.00 - нажимает кнопку обновления (Update) после того, как менеджер B уже сохранил изменения.

Как уже отмечено в начале статьи, данное поведение описывается как "в выигрыше последний", и это стандартное поведение элемента SqlDataSource (а также большинства веб-приложений). Данное поведение отлично подходит многим веб-приложениям, тем не менее, конфликты могут происходить в случаях, когда несколько пользователей обновляют или удаляют одну и ту же информацию. Во многих веб-приложениях пользователи могут изменять информацию, относящуюся только к их учетной записи - в таких случаях нет никакой необходимости в элементе управления параллелизмом. Но в приложениях, где могут произойти конфликты, все же есть смысл в добавлении какого-либа элемента управления параллелизмом.