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

184
CHAPTER 6 ■ LOCKING AND LATCHING
provide locking mechanisms for concurrency control, but there are deep and fundamental
differences in the way locking is implemented in each one. To demonstrate this, I’ll outline my
progression from a SQL Server developer to an Informix user and finally an Oracle developer.
This happened many years ago, and the SQL Server fans out there will tell me “But we have
row-level locking now!” It is true: SQL Server may now use row-level locking, but the way it is
implemented is totally different from the way it is done in Oracle. It is a comparison between
apples and oranges, and that is the key point.
As a SQL Server programmer, I would hardly ever consider the possibility of multiple
users inserting data into a table concurrently. It was something that just didn’t often happen
in that database. At that time, SQL Server provided only for page-level locking and, since all
the data tended to be inserted into the last page of nonclustered tables, concurrent inserts by
two users was simply not going to happen.
■Note A SQL Server clustered table (a table that has a clustered index) is in some regard similar to, but
very different from, an Oracle cluster. SQL Server used to only support page (block) level locking, and if every
row inserted was to go to the “end” of the table, you would never have had concurrent inserts, concurrent
transactions in that database. The clustered index in SQL Server was used to cause rows to be inserted
all over the table, in sorted order by the cluster key, and as such was used to improve concurrency in that
database.
Exactly the same issue affected concurrent updates (since an UPDATE was really a DELETE
followed by an INSERT). Perhaps this is why SQL Server, by default, commits or rolls back
immediately after execution of each and every statement, compromising transactional
integrity in an attempt to gain higher concurrency.
So in most cases, with page-level locking, multiple users could not simultaneously
modify the same table. Compounding this was the fact that while a table modification was in
progress, many queries were also effectively blocked against that table. If I tried to query a
table and needed a page that was locked by an update, I waited (and waited and waited). The
locking mechanism was so poor that providing support for transactions that took more than a
second was deadly—the entire database would appear to “freeze” if you did. I learned a lot of
bad habits here. I learned that transactions were “bad” and that you ought to commit rapidly
and never hold locks on data. Concurrency came at the expense of consistency. You either
wanted to get it right or get it fast. I came to believe that you couldn’t have both.
When I moved on to Informix, things were better, but not by much. As long as I remembered
to create a table with row-level locking enabled, then I could actually have two people
simultaneously insert data into that table. Unfortunately, this concurrency came at a high
price. Row-level locks in the Informix implementation were expensive, both in terms of time
and memory. It took time to acquire and “unacquire” or release them, and each lock consumed
real memory. Also, the total number of locks available to the system had to be computed prior
to starting the database. If you exceeded that number, then you were just out of luck. Consequently,
most tables were created with page-level locking anyway, and, as with SQL Server,
both row and page-level locks would stop a query in its tracks. As a result, I found that once
again I would want to commit as fast as I could. The bad habits I picked up using SQL Server