Why does SQL Server explicit predicate locking disallow INSERT statements outside of the predicate lock - sql-server

Question

Assuming we have the following database tables:
create table department (
id bigint not null,
budget bigint not null,
name varchar(255),
primary key (id)
)
create table employee (
id bigint not null,
name varchar(255),
salary bigint not null,
department_id bigint,
primary key (id)
)
alter table employee
add constraint FKbejtwvg9bxus2mffsm3swj3u9
foreign key (department_id) references department
And we have 3 department rows:
insert into department (name, budget, id)
values ('Department 1', 100000, 1)
insert into department (name, budget, id)
values ('Department 2', 75000, 2)
insert into department (name, budget, id)
values ('Department 3', 90000, 3)
And we also have 3 employee rows:
insert into employee (department_id, name, salary, id)
values (1, 'CEO', 30000, 1)
insert into employee (department_id, name, salary, id)
values (1, 'CTO', 30000, 2)
insert into employee (department_id, name, salary, id)
values (2, 'CEO', 30000, 3)
Assuming we have two concurrent users: Alice and Bob.
First, Alice locks all the employee belonging to the 1st department:
SELECT *
FROM employee
WITH (HOLDLOCK)
WHERE department_id = 1
Now, in the meanwhile, it's expected that Bob cannot insert a new employee using the same department_id:
INSERT INTO employee WITH(NOWAIT) (department_id, name, salary, id)
VALUES (1, 'Carol', 9000, 6)
The insert statement above ends with Lock request time out period exceeded which is fine since Alice locked that particular range.
However, why is the following insert blocked as well:
INSERT INTO employee WITH(NOWAIT) (department_id, name, salary, id)
VALUES (3, 'Dave', 9000, 7)
This insert statement uses a department_id value which is beyond the range of Alice's predicate lock. But then, this insert statement also ends up with a Lock request time out period exceeded exception.
Why does the SQL Server HOLDLOCK predicate lock extend beyond its range?
UPDATE
By adding an index to the FK:
create index IDX_DEPARTMENT_ID on employee (department_id)
And increasing the number of employee entries in the 1st and 2nd department to 1000, I managed to see that the predicate lock behaves as expected.

Answer 1

The only way that the SELECT query could be satisfied was by performing a table scan. There's no natural resource by which it could locate and lock based only on department_id, and so it ends up locking all rows and preventing any insertions.
In this toy example, just adding an index on department_id will not help since the optimizer will still choose to perform a table scan. However, on a larger more realistic table, I believe that adding such an index would allow the query to apply locks in a more targeted fashion.

Answer 2

What Damien said was correct..When you dont have index on department id (predicate column) ,the range increases and HoldLock means
HOLDLOCK means SERALIZABLE and therefore allows SELECTS, but blocks UPDATE and DELETES of the rows selected by T1, as well as any INSERT in the range selected by T1 .
so in this case, an index of the below form would help and my test confirms the same
Below is a sample test i did
in session1:
create index nci_department_id on dbo.employee(department_id)
include
(id,name,salary)
go
begin tran
SELECT *
FROM employee
WITH (HOLDLOCK)
WHERE department_id = 1
in session2:
INSERT INTO employee WITH(NOWAIT) (department_id, name, salary, id)
VALUES (3, 'Dave', 9000, 7)
Now the above insert succeeds
References:
https://stackoverflow.com/a/7845331/2975396