We have a table. It has lots of complex indexes with include fields. We have an update statement. It has two columns in the where clause. It's in a short SP with a couple of other update statements. The SP is only run from an interactive app a few times an hour, but still sometimes runs in a couple of sessions at the same time. Our app calls the SP inside of a transaction, though that does not seem to be the issue. The sessions are both read committed. When it runs normally it runs in under a tenth of a second.
In other words it's about as vanilla as it comes.
The same statement caused four deadlocks over two days.
The deadlock I have the most info on, each session was updating different rows, two rows in one session, one row in the other. I presume the other deadlocks were very similar.
Looking at several discussions on this forum, apparently it is known that SQL Server has this ugly behavior. To make a long story short, it seems that not even running serialized connections will avoid it. Erland recommended to one person the use of an app lock:
I can certainly slap one in here, but OMG do we have to do this with every update in the system?
FWIW this server is running SQL 2008 Standard 64bit SP1, four cores maxdop 1, under VMWare. It has oodles of RAM and is generally lightly loaded.
Thanks,
Josh