Return to Question

EDIT: add example data

parent_table:
-------------
id
1
2

child_table:
------------
parent_id | col_1 | ...
1         | "A"   | ...
2         | "A"   | ...
...

2 threads:
1st thread is `DELETE FROM parent_table where id = 1`
2nd thread is `DELETE FROM parent_table where id = 2`

child_table has:

• composite primary key of (parent_id, col_1)
• fk parent_id references parent_table with ON DELETE CASCADE

• both <keylock> (in <resource-list>) have the same hobtid="72057594911457280" dbid="6" objectname="dbname.dbo.child_table" indexname="pk_child_table" attributes suggesting they are referring to the same index key
• I'm struggling to understand how one process can obtain a range lock for update (RangeS-U) that includes index key A, while another process owns an exclusive lock (X) on the same index key A? Shouldn't holding e.g. a X lock on index key A prevent a RangeS-U on key A being obtained, and vice-versa?
• Given 2 processes concurrently deleting the same parent_table record that has child_table records that are to be cascade deleted, and that there is a primary key on the child_table (meaning there is index on it)... Under what scenarios would this deadlock ever happen?

• I'm struggling to understand how one process can obtain a range lock for update (RangeS-U) that includes index key A, while another process owns an exclusive lock (X) on the same index key A? Shouldn't holding e.g. a X lock on index key A prevent a RangeS-U on key A being obtained, and vice-versa?
• Is my understand correct that: waitresource hash ((32da7da6dc73) vs (b6ebcc0466d0)) is different for the 2 processes, so they're trying to lock on different rows?
• Given 2 processes concurrently deleting the same parent_table record that has child_table records that are to be cascade deleted, and that there is a primary key on the child_table (meaning there is index on it)... Under what scenarios would this deadlock ever happen?