Рассмотрим ключевые проблемы, с которыми могут столкнуться пользователи БД при совместном обращении к одним и тем же ресурсам.
Проблема потерянных обновлений возникает в ситуациях, когда одна транзакция переписывает изменения, осуществленные другой транзакцией. Рассмотрим элементарный пример. Допустим, что в некоторой таблице в поле Field1 хранятся данные о количестве товара, находящегося на складе. Пусть изначально это значение равно 10. Рассмотрим ситуацию, когда к этому полю обращаются две транзакции. Первая изымает 5 единиц товара с целью перевести их в торговый зал. Вторая транзакция приходует на складе только что полученные 10 единиц этого же товара. Простейший расчет показывает, что в результате последовательного выполнения вышеуказанных транзакций в поле Field1 должно оказаться значение 10 - 5 + 10 = 15.
А теперь рассмотрим ситуацию, в которой наши транзакции начинают выполняться совместно. В этом случае СУБД поочередно выполняет операции первой и второй транзакций. В момент времени ^ транзакция 1 читает содержимое поля Field1 и помещает его в локальную переменную X. То же самое делает и транзакция 2, но в момент времени t3. В момент времени t4 первая транзакция возвращает в поле результаты своих расчетов: 10 - 5 = 5. Несколько позже и вторая транзакция записывает в поле результат своих расчетов: 10 + 10 = 20. Поскольку транзакция 2 не знает, что во время ее выполнения значение поля Field1 было обновлено другой транзакцией, она не учитывает эти изменения. В итоге мы получили ошибочный результат.
Проблема неактуальных чтений имеет место, когда незафиксированные изменения, осуществленные одной транзакцией, читаются другой транзакцией.
В случае перезаписи этих промежуточных значений или отката первой транзакции незафиксированные изменения могут быть отменены, а прочитавшая их транзакция с этого момента будет работать с мусором.
В основу нового примера положим уже знакомый нам склад. Теперь первая транзакция приходует 10 единиц товара, но потом по какой-то причине производит откат. Вторая транзакция передает в торговый зал 5 единиц товара. В случае последовательного выполнения этих транзакций в поле Fieldl должно оказаться значение 5. Рассмотрим вариант параллельной работы транзакций 1 и 2. Стартующая позже вторая транзакция в момент времени ?5 читает из поля Fieldl незафиксированные изменения первой транзакции. И хотя в результате отката первой транзакции в момент времени t& в поле было возвращено изначально правильное значение, вторая транзакция уже успела считать неверное промежуточное значение работы своей визави и в конце концов вернет в базу ошибочное число 15.
Проблема неповторяемых чтений возникает тогда, когда первая транзакция считывает из базы значение, после чего вторая транзакция обновляет это значение. Если в этот момент времени первая транзакция продолжает выполняться, то имеющиеся в ее распоряжении данные становятся неактуальными. Допустим, что заведующий складом составляет инвентаризационную ведомость товара на складе. Эта задача решается первой транзакцией. В процессе подготовки ведомости на склад поступает товар, но в отчет уже внесены устаревшие данные. На первый взгляд это не очень серьезная проблема. Но представьте себе, что это ошибка не в инвентаризационной ведомости склада (что, кстати, тоже неприятно), а в ведомости загрузки урана в ядерный реактор.
Самым эффективным решением, полностью исключающим эти и другие потенциальные проблемы параллельного выполнения транзакций, считается разработка специального графика выполнения транзакций. Задача графика -обеспечить выполнение только одной транзакции в каждый момент времени. Решение на запуск очередной транзакции выдается только после фиксации изменений, сделанных предыдущей транзакцией. Впрочем, в ежовых рукавицах целесообразно держать только транзакции, обращающиеся к одному
и тому же ресурсу. Если же транзакции обслуживают разные части базы данных, то в их параллельном выполнении нет ничего предосудительного.
