Question

Why is that, with default settings on Sql Server (so transaction isolation level = read committed), that this test:

CREATE TABLE test2 (
ID bigint,
name varchar(20)
)

then run this in one SSMS tab:

begin transaction SH
insert into test2(ID,name) values(1,'11') 
waitfor delay '00:00:30'
commit transaction SH

and this one simultaneously in another tab:

select * from test2

requires the 2nd select to wait for the first to complete before returning??

We also tried these for the 2nd query:

select * from test2 NOLOCK WHERE ID = 1

and tried inserting one ID in the first query and selecting a different ID in the second.

Is this the result of page locking? When running the 2 queries, i’ve also ran this:

select object_name(P.object_id) as TableName, resource_type, resource_description
from
sys.dm_tran_locks L join sys.partitions P on L.resource_associated_entity_id = p.hobt_id

and gotten this result set:

test2 RID 1:12186:5
test2 RID 1:12186:5
test2 PAGE 1:12186
test2 PAGE 1:12186

Answer 1

requires the 2nd select to wait for
the first to complete before
returning??

read commited prevents dirty reads and by blocking you will get a consistent result, snapshot isolation gets around this but you will get slightly worse performance because now sql server will hold the old values for the duration of the transaction (better have your tempdb on a good drive)

BTW, try changing the query from

select * from test2

to

select * from test2 where id <> 1 

assuming you have more than 1 row in the table and it will be over a page, insert a couple of thousand rows