Why is SQL Server 2008 blocking SELECT's on long transaction INSERT's?

Question

We are trying to have a transactional table that only takes new records inserted on a regular basis.

This simple table requires us to continuously add new records to it

Answer 1

This is completely standard behaviour in SQL Server and Sybase (at least).

Data changes (Insert, update, delete) require exclusive locks. this causes readers to be blocked:

With an exclusive (X) lock, no other transactions can modify data; read operations can take place only with the use of the NOLOCK hint or read uncommitted isolation level.

With SQL Server 2005 and above, they introduced snapshot isolation (aka row versioning). From MS BOL: Understanding Row Versioning-Based Isolation Levels. This means a reader has latest committed data but if you then want to write back, say, then you may find the data is wrong because it changed in the blocking transaction.

Now, this is why best practice is to keep transactions short. For example, only process what you need to between BEGIN/COMMIT, don't send emails from triggers etc.

Edit:

Locking like this happens all the time in SQL Server. However, locking for too long becomes blocking that reduce performance. Too long is subjective, obviously.