Why is NOLOCK implemented like that?

Question

Recently I have searched for NOLOCK option in SQL Server. What I've discovered is that when a transaction is active on a table, SQL Server does not allow even reading from a specific table until the transaction is either committed or rolled back (as far as I understood from When should you use “with (nolock)”).

At the same time, other RDBMSes, such as PostgreSQL, allow you to read values from a row that has an active writing transaction on it. They would just give you the values that were there prior to the writing. Particularly that seems to be the behaviour with PostgreSQL MVCC (as I have learned from the Introduction to Chapter 13. Concurrency Control).

And I have this burning question. Why is there a possibility for deadlocks in SQL Server while in other RDBMSes you just get the old value before the new one is written?

NOTE: I am asking because I may have understood incorrectly.

Answer 1

SQL Server by default operates under Read Committed isolation.

If you want SQL Server to behave more like other implementations, what you're looking for is either Read Committed Snapshot Isolation, or Snapshot Isolation.

You can read more about them here.

Full disclosure, I am a Brent Ozar Unlimited employee

Using NOLOCK or Read Uncommitted is generally frowned upon for serious production use, as it can allow dirty reads and other unintended artifacts while modification queries are in progress.

Answer 2

To decide how to manage you blocking problems first read:

SET TRANSACTION ISOLATION LEVEL (Transact-SQL) If you read this MSDN post you will see that there are several different configurations of how to manage how your data and throughput can be used.

On a highly-active server I have used Read Committed Snapshot Isolation, but usually Read Committed isolation is sufficient for less stressed systems.

And there are side-effects of every decision that you make.

Answer 3

SQL Standard defines Isolation levels as what is visible to concurrent transactions (and how to deal with Read Phenomena) , but vendors are free to choose any implementation that satisfies requirements.
SQLServer historically uses locks based concurrency control implementation and locks resources a way more aggressively compared to other RDMBS. To some extent you can control it (by enabling READ_COMMITTED_SNAPSHOT option), but as its' name implies, the option works only for READ_COMMITTED isolation level, so applications written for other RDBMS may still encounter problems.