Oracle для профессионалов Том Кайт торгово-издательский дом DiaSoft

 SELECT FOR UPDATE.
Оказалось, что разработчики хотели добиться повторяемо-
сти при чтении.

---

Разработка успешных приложений для Oracle
Повторяемость при чтении — это такой режим работы приложения, когда повтор-
ное чтение в транзакции строки, которая уже один раз прочитана в этой транзак-
ции, дает тот же результат.
Зачем им это было нужно? Они слышали, что "это хорошо". Ладно, предположим,
повторяемость при чтении действительно необходима. В СУБД Oracle это делается пу-
тем установки уровня изолированности транзакции SERIALIZABLE (что дает не толь-
ко повторяемость при чтении строки, но и повторяемость при выполнении любого зап-
роса — если два раза выполнить один и тот же запрос в пределах транзакции с таким
уровнем изолированности, будут получены одинаковые результаты). Для обеспечения
повторяемости при чтении в Oracle не нужно использовать SELECT FOR UPDATE —
это делается только для обеспечения последовательного доступа к данным. К сожале-
нию, использованное разработчиками инструментальное средство это не учитывало —
оно было создано для использования с другой СУБД, где именно так повторяемость при
чтении и достигалась.
Итак, в данном случае для установки уровня изолированности транзакций
SERIALIZABLE пришлось создать триггер на регистрацию в базе данных, изменяющий
параметры сеанса (уровень изолированности транзакций) для данного приложения. За-
тем мы отключили все установки повторяемости при чтении в использовавшемся инст-
рументальном средстве и повторно запустили приложение. Теперь, без конструкции FOR
UPDATE, в базе данных определенные действия стали выполняться одновременно.
Это была далеко не последняя проблема данного проекта. Нам пришлось разобрать-
ся:
• как настраивать операторы SQL, не изменяя их кода (это сложно — некоторые
методы мы рассмотрим в главе 11);
• как измерять производительность;
• как находить узкие места;
• что и как индексировать, и так далее.
В конце недели разработчики, никогда ранее не работавшие с СУБД, были удивле-
ны тем, что в действительности она дает возможность сделать, как легко получить ука-
занную выше информацию и, что наиболее важно, как существенно все это может ска-
заться на производительности приложения. Тестированием производительности в течение
этой недели мы не занимались (им кое-что пришлось переделывать!), но в конечном
итоге проект завершился успешно — просто на пару недель позже запланированного
срока.
Это не критика инструментальных средств или современных технологий, таких как
компоненты EJB и поддержка постоянного существования на базе контейнеров. Это —
критика намеренного игнорирования особенностей СУБД, принципов ее работы и ис-
пользования. Технологии, выбранные в этом проекте, работали отлично, но лишь пос-
ле того, как разработчики немного разобрались в самой СУБД.
Подводя итоги: СУБД — это краеугольный камень приложения. Если она не работа-
ет как следует, все остальное не имеет значения. Если плохо работает черный ящик, что