database locking

Say you're dealing with a legacy app that uses a database as a messsage passing system. It happens to be a transactional database which defaults to rough table locking when complex views are queries (SQL Server, MSDE to be specific). Just for fun lets add a couple processes writing data once every few seconds to a table that the view uses. Shake, stir and wait for it to explode. If you happen to be using MS ODBC to connect to said database of doom, you will encounter the executioners axe by way of the SQL Server task manager killing a blocking process and making your ODBC session junk. To make matters worse, this process takes a good bit of time so if your doing the query to the view from a legacy ASP page you will encounter a script timeout.

Once you figure out that you can trap the script timeout using ASP's transaction support, it will become apparent that the database is the culprit. What to do, oh what to do... Which is where with (NOLOCK) comes into play. NOLOCK allows you to tell sql server that you will accept dirty reads. This bypasses the locking system allowing you to read your data while someone else writes to the database, which is what you want in most cases. Unless your dealing with sensative data (which you probably wouldn't be updating in this manner anyway), who cares if the end is slightly off. The immediate session was "close enough", at least for data display purposes.

As a note, when working with any database server its a good idea to investigate the locking and transaction support provided by the database. You never know what kind of performance issues could be lurking in wait.