I am seeing SQL Server reporting deadlock errors and after some investigation, I found that they are not really deadlocks, but rather connections running into timeouts while waiting for a lock.
I have an application that uses multiple threads and connections (each thread has its own connection) to insert new data. All threads basically populate the same tables (say ORDER and ORDERITEMs), so the sequence of events is:
- Thread #1: INSERT INTO ORDER (order locked)
- Thread #2: INSERT INTO ORDER (blocked)
- Thread #3: INSERT INTO ORDER (blocked)
- ...(e.g. thread#1 insert into orderitem) ...
- Thread #1: COMMIT (releases lock)
- Thread #3: continues work
- ...
- Thread #3: COMMIT
- Thread #2: continues work
Apparently, SQL Server has picked Thread #3 to continue, rather than Thread #2, although it was waiting longer.
What I am seeing in my logs is that every now and then under high load a thread would starve to death waiting to be picked. Other threads that came in later get served, continue their work and finish after 200-400 msecs.
Is my understanding correct? Is there a way to influence this (other than increasing the timeout, which does not actually solve the issue)?
J.-