7.3. Параллельное выполнение транзакций

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

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

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

7.3.1. Пропавшие обновления

Рассмотрим пример работы двух диспетчеров с модифицированной БД «Сессия». Пусть Диспетчер 1 вносит в текущий учебный план для каждой дисциплины, читаемой на третьем курсе, сведения о преподавателях, параллельно изменяя при этом значение столбца Нагрузка в таблице «Кадровый состав», а Диспетчер 2 выполняет такую же операцию для дисциплин второго курса.

Диспетчер 1 начинает работу по изменению таблицы «Учебный план» для Дисциплины 1 с количеством часов, равным 50.

В столбец ID_Преподаватель для этой дисциплины предполагается внести значение 5. Запрос текущей нагрузки преподавателя возвра­щает значение 350, и Диспетчер 1 подтверждает изменение таблицы «Учебный_план». При этом выполняются дополнительные действия по изменению столбца Нагрузка в таблице «Кадровый_состав» для строки с ID_Преподаватель = 5 (в столбец заносится значение 400).

Рис. 7.4. Проблема пропавшего изменения

До завершения операции Диспетчер 2 начинает те же действия для Дисциплины 2 с количеством часов 32, которую должен читать тот же преподаватель (ID_Преподаватель = 5). Запрос текущей на­грузки преподавателя также возвращает значение 350, с которым и работает дальше Диспетчер 2. Выполнив те же операции, что и Дис­петчер 1 (но после него), Диспетчер 2 помещает в столбец Нагрузка значение 382, отменив тем самым предыдущие изменения (рис. 7.4).

Во избежание подобных ситуаций к СУБД по части синхрони­зации параллельно выполняемых транзакций предъявляется мини­мальное требование — отсутствие потерянных изменений.

7.3.2. Чтение «грязных» данных

Другой пример коллизий при несогласованной работе двух парал­лельных транзакции представлен на рис. 7.5.

Рис. 7.5. Проблема чтения «грязных» данных

Как показано па рисунке, Диспетчер 1 и Диспетчер 2 опять вы­полняют действия, описанные в предыдущем примере, но Диспет­чер 2 начинает запрашивать данные о нагрузке преподавателя в тот момент, когда изменения, сделанные Диспетчером 1, уже зафикси­рованы в столбце Нагрузка, а транзакция еще не закончилась. За­прос Диспетчера 2 возвращает значение 400, и Диспетчер 2 вынуж­ден отменить свои действия потому, что 400 часов — это макси­мальное разрешенное значение нагрузки. Между тем транзакция Диспетчера 1 закончилась возвратом к исходному состоянию, т. е. на самом деле Диспетчер 2 мог бы успешно завершить операцию.

Это тоже не соответствует требованию изолированности пользо­вателей (каждый пользователь начинает свою транзакцию при согласованном состоянии базы данных и вправе ожидать увидеть со­гласованные данные). Чтобы избежать ситуации чтения «грязных» данных, необходимо требовать, чтобы до завершения одной тран­закции, изменившей некоторый объект, никакая другая транзакция не могла читать изменяемый объект.