Базы данных Oracle - статьи


Проблема моды изоляции чтения. - часть 2


Нетрудно заметить, что данная транзакция не изменяет общей суммы на счетах, но если отчет выполняется в любой стандартной моде изоляции, отличной от “повторяемого” чтения, он неизбежно выдаст результат на 50000 больший! Причина в том, что с первого счета будет считана старая сумма, с последнего же - новая. Если при этом используется устанавливаемая по умолчанию в большинстве СУБД мода изоляции “завершенное чтение” (гарантирующая считывание данных только завершенных транзакций), то это только усугубит ситуацию: даже если транзакция не успеет завершиться до конца выполнения отчета, последний попросту остановится и будет ждать ее завершения, поскольку реализуется данная мода именно с помощью такой блокировки. Наличие указанных блокировок может привести и к еще более неприятным последствиям, если подключить третьего пользователя: нетрудно изменить пример так, что система попросту войдет в “клинч”: пользователи окажутся в состоянии взаимного ожидания.

Если все моды изоляции, кроме “повторяемого чтения”, столь опасны, то спрашивается: зачем они вообще допускаются? Дело в том, что при традиционном подходе реализация всех этих мод изоляции достигается с помощью блокировок того или иного уровня, причем чем “сильнее” мода изоляции, тем обременительнее блокировки: не блокирующим является лишь “грязное” чтение, а в случае “повторяемого чтения” на время выполнения отчета блокируются все записи, которые им могут быть считаны - т.е. фактически СУБД может почти потерять свои многопользовательские свойства!




Начало  Назад  Вперед



Книжный магазин