Deadlocks

[109]

I will use English here because I am going to copy this to MSDN later on.

So.

4 out of 5 projects, which I have been involved in during last couple of years, used some kind of loop to retry in the event of database deadlock. Which made me thinking: "Why do we have to repeat this over and over again in the client code?"

It seems that we have a classic case of successful problem externalization. Seems like database architects decided not to deal with this [difficult without any doubt] issue, making it cient problem.

Both most popular database engines (Oracle, Sql Server) return deadlock exception as soon as it is detected. Which in typical scenario will be sooner than the timeout [duh! otherwise it would be timeout exception, not a deadlock one]. Default time frames for Sql Server are 5 seconds for deadlock, 30 seconds for timeout. Which means the server could try 6 times to rerun deadlocked transaction before giving up. This is a simplest thing to do. Not very smart though, but it would already help.

But, to an outsider (me), it seems that server could do more. Server detects deadlocks by walking the list of locks held by suspicious transaction[s]. Instead of rolling back all the way, it could roll back to the point just before the first deadlocked resource was locked. Wait a little (meanwhile the other transaction will go through; it can even be tracked) and retry. I am sure this is all much more complicated internally, but I don't see anything impossible here.

Anyway, even simple retry of the whole transaction would help. I am sure that Katmai is already too late in the cycle to add new feature, but it should be at least discussable for vNext + 1 version. What do you guys think?

Comments

[109.livejournal.com]

Яков, we love you!