Реклама:

_I

Пример. Пусть таблица данных после заполнения ее данными (т. е. первого выполнения метода Fill) имеет вид, показанный на рис. 6.26:

Пусть после того, как наше приложение отсоединилось от источника данных, другое приложение изменяет запись с кодом 2 (название кафедры с Информатика на Информактика и выч. техники).

Когда мы вновь соединимся с источником данных и выполним освежение таблицы текущими данными из источника, внесенные другим приложением изменения станут видны и у нас

(рис. 6.27).

Шумаков П. В.  ADO.NET и создание приложений баз данных в среде Microsoft Visual Studio .NET. Руководство разработчика с примерами на C#.

рис. 6.26

Шумаков П. В.  ADO.NET и создание приложений баз данных в среде Microsoft Visual Studio .NET. Руководство разработчика с примерами на C#.

рис. 6.27

6.2. Конкуренция пользователей при изменении данных

Когда несколько пользователей одновременно изменяют одни и те же данные, между ними неизбежно возникает конкуренция.

Имеет место следующая ситуация. Пусть некая запись хранится в базе данных и пребывает в состоянии Снач. Пусть пользователи А и Б считывают эту запись и как-то с нею работают. Затем пользователь А вносит в запись изменения и запоминает их в базе данных. Запись в базе данных переходит в состояние СА. Потом пользователь Б, работающий у себя в приложении с копией записи, находящейся в состоянии Снач, изменяет эту запись и также пытается записать изменения в базу данных. Однако в базе данных записи в состоянии Снач нет; та же запись, как уже сказано, находится в базе в состоянии СА. Тут возникают вопросы:

• позволить ли перевести запись в состояние СБ, возможно, потеряв при этом изменения, внесенные пользователем А?

• как сообщить пользователю Б, что запись уже изменена в базе данных (быть может, если он узнает об этом, то сочтет дальнейшую работу с записью бессмысленной)?

Эти вопросы решаются при помощи различных стратегий, сущность которых состоит в том, что, когда один пользователь изменяет (или даже просто читает) данные, права других пользователей по применению этих данных ограничиваются. Известны три общие стратегии конкурентного обновления данных:

• пессимистическая;

• оптимистическая;

• по принципу "последний победивший".

6.2.1. Пессимистическая стратегия

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

В рамках пессимистической стратегии исходят из того, что, когда мы записываем данные в источник данных, нам обязательно кто-нибудь будет мешать.

ADO.NET, как известно, использует данные в отсоединенном от источника данных режиме и не поддерживает постоянного соединения с источником. В таких условиях пессимистическая стратегия как общий подход к изменению данных практически невозможна. Ведь данные, с которыми работает пользователь, на все это время блокируются для оставшихся пользователей. Если учесть, что заранее неизвестно, сколько времени монопольный пользователь будет работать с копиями данных в своем приложении и когда ему придет в голову записать внесенные изменения обратно в источник, то в рамках пессимистической стратегии все остальные пользователи потеряют доступ к данным на неопределенное время. А это немыслимо.


⇐ Предыдущая страница| |Следующая страница ⇒