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

 count(*),
необходимо
было сначала выполнить:
select * from resources where resource_name = :room_name FOR UPDATE;
Ранее в этой главе рассматривался пример, когда использование конструкции
 FOR
UPDATE приводило к проблемам, но в этом случае она обеспечивает корректную ра-
53

---

54
Глава 1
боту бизнес-правила. Мы просто блокируем ресурс (учебный класс), использование
которого планируется непосредственно
 перед
его резервированием, до выполнения зап-
роса к таблице планов, выбирающего строки для данного ресурса. Блокируя ресурс,
который мы пытаемся зарезервировать, мы гарантируем, что никакой другой сеанс в это
же время не изменяет план использования ресурса. Ему придется ждать, пока наша тран-
закция не будет зафиксирована — после этого он сможет увидеть сделанное в ней ре-
зервирование. Возможность перекрытия планов, таким образом, устранена. Разра-
ботчик должен понимать, что в многопользовательской среде иногда необходимо
использовать те же приемы, что и при многопотоковом программировании. В данном
случае конструкция
 FOR UPDATE
работает как семафор. Она обеспечивает последова-
тельный доступ к конкретной строке в таблице ресурсов, гарантируя, что два сеанса од-
новременно не резервируют ресурс.
Этот подход обеспечивает высокую степень параллелизма, поскольку резервируемых
ресурсов могут быть тысячи, а мы всего лишь гарантируем, что сеансы изменяют конк-
ретный ресурс поочередно. Это один из немногих случаев, когда необходимо блокиро-
вание вручную данных, которые не должны изменяться. Требуется уметь распознавать
ситуации, когда это необходимо, и, что не менее важно, когда этого делать не нужно
(пример, когда не нужно, приведен далее). Кроме того, такой прием не блокирует чте-
ние ресурса другими сеансами, как это могло бы произойти в других СУБД, благодаря
чему обеспечивается высокая масштабируемость.
Подобные проблемы приводят к масштабным последствиям при переносе приложе-
ния с одной СУБД на другую (к этой теме я вернусь чуть позже), которых разработчи-
кам сложно избежать. Например, при наличии опыта разработки для другой СУБД, в
которой пишущие сеансы блокируют читающих, и наоборот, разработчик может пола-
гаться на это блокирование как защищающее от подобного рода проблем — именно так
все и работает во многих СУБД, отличных от Oracle. В Oracle приоритет отдан одновре-
менности доступа, и необходимо учитывать, что в результате все может работать по-
другому.
В 99 процентах случаев блокирование выполняется незаметно, и о нем можно не за-
ботиться. Но оставшийся 1 процент надо научиться распознавать. Для решения этой
проблемы нет простого списка критериев типа "в таком-то случае надо сделать то-то".
Нужно понимать, как приложение будет работать в многопользовательской среде и что
оно будет делать в базе данных.