40. Параллельная обработка данных: необходимость в атомарных транзакциях

В большинстве приложений баз данных работа пользователей организована в фор­ме транзакций (transactions), известных также как логические единицы работы (logical units of work, LUW). Транзакция - это последовательность действий с базой данных, в которой либо все действия выполняются успешно, либо не вы­полняется ни одно из них (в последнем случае база данных остается без измене­ний). Такая транзакция иногда называется атомарной (atomic), поскольку она выполняется как единое целое.

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

1. Изменить запись данного покупателя, увеличив сумму к оплате.

2. Изменить запись продавца, увеличив сумму комиссионных.

3. Вставить в базу данных запись о новом заказе.

Предположим, что на последнем шаге нас постигла неудача – например, из-за недостатка файлового пространства. Представьте себе недоразумение, которое возникло бы, если бы выполнены были только первые два действия, но не третье. Покупателю был бы выставлен счет за заказ, который он не получал, а продавец получил бы комиссионные за товар, который он не отправлял покупателю. Ясно, что эти три действия должны выполняться как единое целое: либо все сразу, ли­бо ни одного.

На рис. 1 и 2 приведено сравнение результатов этих действий в виде после­довательности независимых шагов (рис. 1) и в виде атомарной транзакции (рис. 2). Обратите внимание, что когда терпит неудачу одно из действий, со­ставляющих атомарную транзакцию, то изменения в базе данных не производят­ся. Также обратите внимание, что для указания рамок транзакции прикладная программа должна дать команды на начало транзакции (Start Transaction), сохра­нение транзакции (Commit Transaction) и откат транзакции (Rollback Transaction). Конкретная форма этих команд различается в разных СУБД.

41. Параллельная обработка данных: проблема потерянного обновления, проблема несогласованного чтения

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

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

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

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

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