Проблема промежуточных данных

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

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

Рисунок 25 Проблема пропавшего обновления

Перед вводом заказа программы по таблице PRODUCTS проверяют, имеется ли требуемое изделие в наличии. На приведенном рисунке Пользователь 1 начинает вводить заказ от своего клиента на 100 изделий Samsung C110. В то же время Пользователь 2 начинает вводить заказ от своего клиента на 125 тех же изделий. Обе программы для ввода заказов выполняют запрос к таблице PRODUCTS, и каждая из них выясняет, что на складе имеется 139 требуемых изделий – количество, более чем достаточное для выполнения заказа. Пользователь 1 просит клиента подтвердить заказ; затем его копия программы обновляет таблицу PRODUCTS, показывая, что в наличии осталось 39 изделий Samsung C110, и добавляет в таблицу ORDERS новый заказ на 100 изделий. Через несколько секунд Пользователь 2 просит своего клиента подтвердить заказ. Его копия программы обновляет таблицу PRODUCTS, показывая, что на складе осталось 14 изделий Samsung C110, и добавляет в таблицу ORDERS новый заказ на 125 изделий.

Очевидно, что обработка этих двух заказов привела к возникновению противоречия в базе данных. Первое из двух обновлений таблицы PRODUCTS пропало. Заказы от обоих клиентов приняты, но на складе нет достаточного количества изделий для удовлетворения обоих заказов. Более того, таблица PRODUCTS показывает, что в наличии осталось еще 14 изделий. Данный пример показывает, что проблема “пропавшего обновления” может возникнуть всякий раз, когда две программы извлекают из базы одни и те же данные, используют их для каких – либо расчетов, а затем пытаются обновить эти данные.

Так же как и проблему пропавшего обновления проиллюстрируем данную проблему на примере. На рисунке 26 изображена схема работы той же программы для обработки заказов, что и на предыдущем рисунке.

Рисунок 26 Проблема промежуточных данных

На этот раз Пользователь 1 снова начинает принимать от клиента заказ на 100 изделий Samsung C110. На этот раз его копия программы запрашивает таблицу PRODUCTS, выясняет, что в наличии имеется 139 изделий, и обновляет ее, показывая, что после принятия заказа в наличии осталось 39 изделий. Тем временем клиент Пользователя 2 пытается заказать 125 вышеупомянутых изделий. Его копия программы запрашивает таблицу PRODUCTS, выясняет, что в наличии имеется только 39 изделий, и отказывается принять заказ. А клиент Пользователя 1 решает отказаться от заказа, и программа выполняет инструкцию ROLLBACK для отмены транзакции, после выполнения, которой СУБД восстанавливает в таблице число 139, хотя 39 изделий из них уже предназначены заказчика Пользователя 2. Такое противоречие в базе данных возникло из–за того, что информацию, которую извлекла программа Пользователя 2, являлись промежуточными, так как еще не были подтверждены программой Пользователя 1.