Tutta la documentazione sui deadlock di SQL Server parla dello scenario in cui l'operazione 1 blocca la risorsa A, quindi tenta di accedere alla risorsa B e l'operazione 2 blocca la risorsa B e tenta di accedere alla risorsa ASQL deadlock tra selezione/aggiornamento o selezione multipla
Tuttavia, vedo spesso deadlock tra una selezione e un aggiornamento o anche tra più selezioni in alcune delle nostre applicazioni occupate. Trovo che alcuni dei punti più fini dell'output deadlock trace siano piuttosto impenetrabili, ma mi piacerebbe davvero solo capire cosa può causare un deadlock tra due singole operazioni. Sicuramente se una select ha un lock di lettura l'aggiornamento dovrebbe solo aspettare prima di ottenere un lock esclusivo e viceversa?
Questo sta accadendo su SQL Server 2005, non penso che questo faccia la differenza.
Sono a conoscenza dei livelli di isolamento, i deadlock precedenti possono essere risolti rendendo la selezione letta senza commit MA perché una lettura che inizia PRIMA di un aggiornamento finisce in un deadlock con quell'aggiornamento con read committed? –