5. Блокировки.

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

При параллельной обработке базы данных возникает три основных проблемы:

• Пропавшие изменения. Эта ситуация возникает в тех случаях, когда 2 транзакции одновременно изменяют одну и ту же запись в БД. Например, работают 2 оператора на приеме заказов, первый оператор принял заказ на 30 мониторов. Когда он обращался на склад, то там числилось 40 мониторов, и он, получив подтверждение от клиента, оформил продажу 30 мониторов из 40. Параллельно с ним работает второй оператор, который принимает заказ на 20 таких же мониторов, и в свою очередь, обратившись на склад, он получает то же значение 40, и оформляет заказ для своего клиента. Заканчивая работу с данными, он выполняет команду Обновить, которая заносит 20 как остаток мониторов на складе. После этого первый оператор заканчивает работу со своим заказчиком и тоже выполняет команду Обновить, которая заносит остаток 10 как число мониторов, имеющихся на складе. В общей сложности они продали 50 мониторов при имеющихся 40, и при этом на складе будет числиться 10 мониторов.

• Проблемы промежуточных данных. Связано с возможностью доступа к промежуточным данным. Допустим первый оператор, ведя переговоры со своим заказчиком, ввел заказанные 30 мониторов, но перед окончательным оформлением заказа клиент захотел выяснить еще некоторые характеристики товара. Приложение, с которым работает 1-й оператор, уже изменило остаток мониторов на складе, и там сейчас хранится информация о 10 оставшихся мониторах. В это время второй оператор пытается принять заказ от своего заказчика заказ на 20 мониторов, но его приложение показывает, что на складе осталось всего 10 мониторов и оператор вынужден отказать своему заказчику. В это время заказчик первого оператора принимает решение не покупать мониторы, оператор делает откат транзакции и на складе снова оказывается 40 мониторов. Такая ситуация стала возможной потому, что приложение второго оператора имело доступ к промежуточным данным, которые сформировало первое приложение.

• Проблемы несогласованных данных. Связана с возможностью изменения данныx, уже прочитаныx другим приложением. Оба оператора начинают работать практически одновременно, получают начальное состояние склада 40 мониторов, а затем первый оператор продает своему заказчику 30 мониторов. Он завершает работу своего приложения, и оно выполняет команду фиксации транзакции COMMIT. Состояние БД непротиворечивое. В этот момент заказчик второго оператора решает сделать заказ и второй оператор, обращаясь повторно к данным, видит, что количество мониторов изменилось. Второй оператор считает, что нарушена целостность транзакции, т.к. в течение выполнения одной работы он получил 2 различных состояния склада. Эта ситуация возникла потому, что приложение 1-го оператора смогло изменить кортеж с данными, который уже прочитало приложение второго оператора.

Обобщая перечисленные проблемы, можно выделить следующие типы конфликтов между двумя параллельными транзакциями:

• W-W – транзакция 2 пытается изменить объект, измененный не закончившейся транзакцией 1;

• R-W – транзакция 2 пытается изменить объект, прочитанный не закончившейся транзакцией 1;

• W-R транзакция 2 пытается читать объект, измененный не закончившейся транзакцией 1;