Question

I’ve described the problem here:
Deadlock under ReadCommited IL
and got an answer:

So a deadlock can occur when running SELECTs because the transaction running 
those selects had acquired write locks before running the SELECT.

Okay, so what can I do to get rid of this? There are some common type of deadlocks which can be solved by adding covered indices or changing isolation level of changing the sql command text, using table hints, etc, but I can’t think of a proper solution for my case.

Seems like this is the most common and easiest reason of deadlock:

1. Process A acquired lock on resouce R1, Process B acquires lock on resource R2
2. Process A waits for resource R2 to be released, and process B waits for R1

So this is largely a parallelism problem, and, probably, business logic also.

Maybe I would be able to avoid the deadock if the locks were applied to rows, but seems that there are several rowlocks within a page and then lock escalation occurs and then I have the whole page locked.

What would you advice? Disable lock escalation ? Can I do it locally for 1 transaction?
Or maybe applying some table-hint (WITH ROWLOCK) or something…idk

Changing isolation level to snapshot (or other type) is not an option now.
Thanks.

Answer 1

Fixing deadlocks is mostly a task that is specific to the particular transactions under consideration. There is little general advice to be given (except enable snapshot isolation which you cannot do).

One pattern emerges as a standard fix, though: Acquire all necessary locks in the right order with the right lock-modes. This might mean selecting WITH (UPDLOCK, ROWLOCK, HOLDLOCK) in order to proactively U-lock rows.

I haven’t seen lock escalation to be the problem because it requires very high amounts of locks to kick in. Of course it might be the reason but most often, row locks are enough to trigger deadlock.