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

create table resources(resource_name varchar2(25) primary key, . . . ) ;
create table schedules(resource_name varchar2(25) references resources,
start_time date,
end_time date);
И прежде чем зарезервировать на определенный период, скажем, учебный класс, при-
ложение выполняло запрос вида:
select count(*)
from schedules
where resource_name = :room_name
and (start_tiroe between :new_start_time and :new_end_time
or
end_time between :new_start_time and :new_end_time)
Он казался разработчику простым и надежным: если возвращено значение 0, учеб-
ный класс можно занимать; если возвращено ненулевое значение, значит, учебный класс
на этот период уже кем-то занят. Ознакомившись с используемым алгоритмом, я под-
готовил простой тест, показывающий, какая ошибка будет возникать при реальной эк-
сплуатации приложения. Эту ошибку будет крайне сложно обнаружить и тем более ус-
тановить ее причину, — кому-то может даже показаться, что это
 ошибка СУБД.
Я
предложил его коллеге сесть за соседний компьютер, перейти на тот же экран и
попросил на счет три обоих нажать на кнопку Go и попытаться зарезервировать класс
на одно то же время. Оба смогли это сделать — то, что прекрасно работало в изолиро-
ванной среде, не сработало в среде многопользовательской. Проблема в этом случае была
вызвана неблокирующим чтением в Oracle. Ни один из сеансов не блокировал другой.
Оба сеанса просто выполняли представленный выше запрос и применяли алгоритм ре-
зервирования ресурса. Они оба могли выполнять запрос, проверяющий занятость ресурса,
даже если другой сеанс уже начал изменять таблицу планов (это изменение невидимо
для других сеансов до фиксации, то есть до тех пор, когда уже слишком поздно). По-
скольку сеансы никогда не пытались изменить одну и ту же строку в таблице планов,
они никогда и не блокировали друг друга, вследствие чего бизнес-правило не срабаты-
вало так, как ожидалось.
Разработчику необходим метод реализации данного бизнес-правила в многопользо-
вательской среде, способ, гарантирующий что в каждый момент времени только один
сеанс резервирует данный ресурс. В данном случае решение состояло в программном
упорядочении доступа — кроме представленного выше запроса