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

CHAPTER 1 ■ DEVELOPING SUCCESSFUL ORACLE APPLICATIONS 27
know exactly how each database works in great detail. And, if you knew how each database
worked in great detail, you would understand that database independence is not something
you really want to achieve (a very circular argument!).
For example, let’s revisit our initial resource scheduler example (prior to adding the
FOR UPDATE clause). Let’s say this application had been developed on a database with an
entirely different locking/concurrency model from Oracle. What I’ll show here is that if we
migrate our application from one database to another database, we will have to verify that it
still works correctly in these different environments and substantially change it as we do!
Let’s assume that we had deployed the initial resource scheduler application in a database
that employed blocking reads (reads are blocked by writes). Also consider that the business
rule was implemented via a database trigger (after the INSERT had occurred but before the
transaction committed, we would verify that only our row existed in the table for that time
slot). In a blocking read system, due to this newly inserted data, it would be true that insertions
into this table would serialize. The first person would insert his or her request for “room A” from
2:00 pm to 3:00 pm on Friday and then run a query looking for overlaps. The next person
would try to insert an overlapping request and, upon looking for overlaps, that request would
become blocked (while waiting for the newly inserted data that it had found to become available
for reading). In that blocking read database our application would be apparently well
behaved (well, sort of—we could just as easily deadlock, a concept covered in Chapter 6, as
well if we both inserted our rows and then attempted to read each other’s data)—our checks
on overlapping resource allocations would have happened one after the other—never concurrently.
If we migrated this application to Oracle and simply assumed that it would behave in the
same way, we would be in for a shock. On Oracle, which does row-level locking and supplies
non-blocking reads, it appears to be ill behaved. As shown previously, we had to use the
FOR UPDATE clause to serialize access. Without this clause, two users could schedule the same
resource for the same times. This is a direct consequence of our not understanding how the
database we have works in a multiuser environment.
I have encountered issues such as this many times when an application is being moved
from database A to database B. When an application that worked flawlessly in database A
does not work, or works in an apparently bizarre fashion, on database B, the first thought is
that database B is a “bad” database. The simple truth is that database B just works differently.
Neither database is wrong or “bad”; they are just different. Knowing and understanding how
they both work will help you immensely in dealing with these issues. Taking an application
from Oracle to SQL Server exposes SQL Server’s blocking reads and deadlock issues—in other
words, it goes both ways.
For example, I was asked to help convert some Transact-SQL (T-SQL, the stored procedure
language for SQL Server) into PL/SQL. The developer doing the conversion was complaining
that the SQL queries in Oracle returned the “wrong” answer. The queries looked like this:
declare
l_some_variable varchar2(25);
begin
if ( some_condition )
then
l_some_variable := f( ... );
end if;