March 14, 2024 at 1:30 am
Hi All,
I'm certain this is normal behavior, I'm just not getting it.
Run this code to create table
CREATE TABLE test (id INT IDENTITY(1, 1), someval VARCHAR(20));
INSERT INTO dbo.test (someval)
VALUES
('row1' -- someval - varchar(20)
);then this code in a new window
BEGIN TRANSACTION;
SELECT TOP (1)
*
FROM dbo.test AS t WITH (TABLOCKX, HOLDLOCK);
WAITFOR DELAY '00:01';
SELECT TOP (1)
*
FROM dbo.test AS t WITH (TABLOCKX, HOLDLOCK);
COMMIT TRANSACTION
From what I expect, if I then run a select (from test) in a new session, I should be blocked until the transaction commits. Correct? However, the select works fine. DB is set to read committed. Thanks much for the help.
March 14, 2024 at 10:28 am
I just tried this, and for me the blocking occurs, exactly as you expected.
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
March 14, 2024 at 11:28 am
you said " DB is set to read committed" - does this mean your db has Read Committed Snapshot Isolation on? if so this is likely why.
March 14, 2024 at 2:08 pm
So very strange. Trying those exact queries again today, and working exactly as expected. Even tried setting RCSI on and off, no change. Thanks for checking. Much appreciated.
Interestingly enough, I used that technique for queueing records that can have multiple applications processing them. Thinking that didn't work forced me to find something new. Now I'm just using update with output inserted. (or delete with output) No additional locking needed and much safer/cleaner.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply