We have a deadlock issue we're trying to track down. I have an deadlock graph (xdl) generated from Profiler. It shows the losing SQL statement as a simple Select statement, not an Update, Delete or Insert statement. The graph shows the losing Select statement as requesting a Shared lock on a resource **but also owning an Update lock on a resource**
. This is what is baffling me. Why would a Select statement that is not part of an Insert, Update or Delete ever hold an Update lock on a resource?
I should add that the Update lock it owns is on the table being selected against by the losing Select statement.
EDIT: Please don't suggest using NoLock. Yes that would solve the problem but introduces a new one - a dirty read issue. This query is hitting a production server. What I really want to know is why would a Select statement issue an Update lock.