Проблема потерянного обновления

Параллельная обработка, изображенная на рис. 3, не вызывает проблем, посколь­ку пользователи обрабатывают различные данные. Но предположим, что оба поль­зователя хотят обратиться к элементу 100. Например, пользователь А хочет зака­зать пять единиц товара 100, а пользователь В – три единицы этого же товара.

Рис.4 иллюстрирует возникающую проблему. Пользователь А считыва­ет запись о товаре 100 в свою рабочую область. В соответствии с этой записью, в наличии имеется 10 единиц товара. Затем пользователь В читает запись о това­ре 100 в свою рабочую область. Опять-таки, согласно этой записи, в наличии имеется 10 единиц товара. Теперь пользователь А берет пять единиц товара, умень­шает количество единиц товара в своей рабочей области до пяти и обновляет запись для товара 100. После этого пользователь В берет три единицы товара, уменьшает количество товара в своей рабочей области до семи единиц и запи­сывает это количество в базу данных. Теперь БД ошибочно показыва­ет, что в наличии имеется семь единиц товара 100. Итак: мы начали с 10 единиц в наличии, пользователь А взял пять, пользователь В взял три, а база данных показывает, что осталось семь. Ясно, что это не так.

Данные обоих пользователей были верными на момент считывания. Но когда пользователь В считывал запись, у пользователя А уже была ее копия, которую он вот-вот собирался изменить. Эта ситуация носит название проблемы потерян­ного обновления (lost update problem), или проблемы параллельного обновления (concurrent update problem).

Существует другая, схожая проблема, называемая проблемой несогласованного чтения (inconsistent read problem). В этом случае пользователь А читает данные, которые были обработаны некоторым фрагмен­том транзакции пользователя В. Как следствие, у пользователя А оказываются ошибочные данные.

Рис. 4. Проблема потерянного обновления

38, БЛОКИРОВКА РЕСУРСОВ. НЕЯВНЫЕ И ЯВНЫЕ БЛОКИРОВКИ. ГЛУБИНА ДЕТАЛИЗАЦИИ БЛОКИРОВКИ. МОНОПОЛЬНАЯ И КОЛЛЕКТИВНАЯ БЛОКИРОВКИ.

Блокировка ресурсов

Одно из средств против несогласованностей, вызванных параллельной обра­боткой, состоит в том, чтобы не давать нескольким приложениям получать копии одной и той же записи, когда предполагается скорое изменение данной записи. Это средство называется блокировкой ресурсов (resource locking).

Один из способов предотвратить проблемы при параллельной обработке – за­претить совместное использование ресурсов путем блокировки данных, которые считываются для обновления. На рис. 5 изображен порядок обработки при ис­пользовании команды lock. Из-за блокировки транзакция пользователя В должна ждать, пока пользователь А не закончит работу с данными по товару 100. При та­кой стратегии пользователь В сможет прочесть запись о товаре 100 только после того, как пользователь А завершит ее модификацию. В этом случае результиру­ющее количество единиц товара в базе данных будет равно двум, как и должно быть (было десять, А взял пять, В взял три, осталось два).

Блокировочная терминология

Блокировка может налагаться либо автоматически, по инициативе СУБД, либо по команде, которая передается СУБД прикладной программой или запросом пользователя. Блокировка, налагаемая СУБД, называется неявной блокиров­кой (implicit locks), а блокировка, налагаемая по команде, — явной блокировкой (explicit locks).

В предыдущем прим. блокировка налагалась на строки данных. Однако не все типы блокировки налагаются на этом уровне. Одни СУБД предусматривают бло­кировку на уровне страницы, другие — на уровне таблицы, а третьи — на уровне базы данных. Размер блокируемого ресурса называется глубиной детализации блокировки (lock granularity). При малой глубине детализации СУБД легче справ­ляется с администрированием блокировки, но такие блокировки часто являются причиной конфликтов. Блокировки с большой глубиной детализации сложно ад­министрировать (СУБД приходится отслеживать и проверять гораздо больше деталей), но конфликты при этом менее часты.

Блокировки различаются также по типу. При монопольной блокировке (exclusive lock) блокируются все виды доступа к элементу. Ни одна другая транзакция не может читать или изменять данные. Коллективная блокировка (shared lock) защи­щает элемент от изменения, но не от чтения. Т.е.др. транзакции могут свободно читать данный элемент, если они не пытаются изменить его.

Рис. 5. Параллельная обработка с явными блокировками

39,БЛОКИРОВКА РЕСУРСОВ: СЕРИАЛИЗУЕМЫЕ ТРАНЗАКЦИИ.