Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 19
select count(*)
into l_cnt
from schedules
where resource_name = p_resource_name
and (start_time = p_start_time);
if ( l_cnt 0 )
then
raise_application_error
(-20001, 'Room is already booked!' );
end if;
If we get to this point in the code without raising an error, we can safely insert rows for
our resource into the SCHEDULES table without any overlaps:
insert into schedules
( resource_name, start_time, end_time )
values
( p_resource_name, p_start_time, p_end_time );
end schedule_resources;
This solution is still highly concurrent, as there are potentially thousands of resources to
be reserved. What we have done is ensure that only one person modifies a resource at any
time. This is a rare case where the manual locking of data we are not going to actually update
is called for. We need to be able to recognize where we need to do this and, perhaps as
important, where we do not need to do this (I present an example of when not to shortly).
Additionally, this does not lock the resource from other people reading the data as it might
in other databases, hence this solution will scale very well.
Issues such as the one described in this section have massive implications when you’re
attempting to port an application from database to database (I return to this theme a little
later in the chapter), and this trips people up time and time again. For example, if you are
experienced in other databases where writers block readers and vice versa, then you may have
grown reliant on that fact to protect you from data integrity issues. The lack of concurrency is
one way to protect yourself from this—that is how it works in many non-Oracle databases. In
Oracle, concurrency rules supreme and you must be aware that, as a result, things will happen
differently (or suffer the consequences).
■Note We will revisit this example again in Chapter 7. The code as provided works under the assumption
the transaction isolation level is READ COMMITTED. The logic will not work properly in SERIALIZABLE transaction
isolations. Rather than complicate this chapter with the differences between those two modes, I defer
that discussion until later.
Ninety-nine percent of the time, locking is totally transparent and you need not concern
yourself with it. It is that other 1 percent that you must be trained to recognize. There is no