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

На рис. 6.6 изображена та же программа для обработки заказов, что и на рис. 6.5. Джо снова начинает принимать от клиента заказ на 100 изделий ACI-41004. На этот раз его копия программы обработки заказов запрашивает таблицу products, выясняет, что в наличии имеется 139 изделий, и обновляет таблицу products, показывая, что после принятия заказа в наличии осталось 39 изделий. После этого Джо начинает обсуждать с клиентом относительные достоинства изделий ACI-41004 и АСГ-41005. Тем временем клиент Мэри пытается заказать 125 изделий ACI-41004. Ее копия программы запрашивает таблицу products, выясняет, что в наличии имеется только 39 изделий, и отказывается принять заказ. Программа генерирует также сообщение для менеджера по снабжению о том, что необходимо закупить изделия ACI-41004, которые пользуются большим спросом. А первый клиент после беседы с Джо решает, что изделия ACI-41004 ему вовсе не нужны, и программа выполняет оператор rollback для отмены транзакции.

Поскольку программа Мэри имела доступ к промежуточным данным программы Джо, ее клиенту было отказано в приеме заказа, а менеджер по снабжению закажет дополнительное количество изделий ACI-41004, хотя их на складе уже есть 139 штук. Ситуация могла бы быть еще хуже, если бы клиент Мэри решил заказать 39 изделий. В этом случае программа Мэри занесла бы в таблицу products число нуль, показывая, что изделия ACI-41004 на складе отсутствуют. Но после операции rollback, отменяющей транзакцию Джо, СУБД восстановит в таблице число 139, хотя 39 изделий из них уже предназначены клиенту Мэри. В данном примере проблема заключается в том, что программа Мэри имела доступ к промежуточным результатам программы Джо и, опираясь на них, занесла в базу данных ошибочную информацию.

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

Проблема несогласованных данных

На рис. 6.7 изображена программа для обработки заказов. Джо снова начинает принимать от своего клиента заказ на 100 изделий ACI-41004. Вскоре после этого Мэри начинает со своим клиентом разговор об этих же изделиях, и ее программа выясняет их количество на складе. Затем клиент начинает расспрашивать Мэри об изделиях ACI-41005, и программа Мэри выполняет запрос о наличии этих изделий. Тем временем клиент Джо решает заказать изделия ACI-41004, поэтому его программа обновляет соответствующую строку и выполняет оператор commit, завершая транзакцию по приему заказа. После некоторых размышлений клиент Мэри решает заказать изделия ACI-41004, которые Мэри предлагала ему вначале. Ее программа вновь запрашивает информацию об изделиях ACI-41004. Но новый запрос показывает, что в наличии имеется только 39 изделий вместо 139, показанных предыдущим запросом несколько мгновений тому назад.

В данном примере, в отличие от двух предыдущих, состояние базы данных правильно отражает ситуацию в реальной жизни. В наличии осталось только 39 изделий ACI-41004, поскольку клиент заказал у Джо 100 штук. Из-за того что Мэри увидела промежуточные данные программы Джо, ничего особенного не произошло — заказ от Джо был успешно принят. Однако с точки зрения программы Мэри база данных не была целостной в течение выполняемой ею транзакции. В начале транзакции некоторая строка содержала одни данные, а позднее в той же самой транзакции она содержала другие данные, поскольку "внешние события" нарушили целостное восприятие базы данных этой программой. Такая несогласованность может привести к различным проблем даже в том случае, если программа Мэри не будет обновлять базу данных, опираясь на результаты первого запроса. Например, если ее программа накапливает итоговые суммы или собирает статистику, то нет гарантии, что она отражает правильные данные. В этом примере проблема заключается в том, что программа Мэри имела доступ к результатам обновления, выполненного программой Джо для строки, которую программа Мэри уже читала ранее.

Р исунок 6.7 - Проблема несогласованных данных