Un livello di isolamento readcommitted può mai provocare un deadlock (server Sql)?

Question

La mia comprensione dei deadlock è: due processi che tentano di contendersi per la stessa risorsa, in genere due processi che tentano di "scrivere" nella stessa riga di dati. Se tutto ciò che sta facendo un processo è la lettura dei dati - e l'altro processo sta aggiornando i dati, qual è la contesa di una risorsa? Eppure, nel nostro database, che è impostato sul livello di transazione predefinito "ReadCommitted", stiamo vedendo diverse eccezioni deadlock. ReadComitted definitin - I dati che sono stati modificati (ma non ancora commessi) non possono essere letti. Va bene, ma SQL Server dovrebbe lanciare un'eccezione deadlock se rileva questa "lettura sporca"? Qualcuno ha esperienza del mondo reale con questo scenario? Ho trovato un post sul blog (dallo sviluppatore StackOverflow, nientemeno :) affermando che questo potrebbe essere vero.

Grazie

Answer 1

Sì, può succedere. Immagina di avere due processi ciascuno con una propria transazione. I primi aggiornamenti TabellaA quindi tenta di aggiornare TableB. Il secondo aggiorna TableB quindi tenta di aggiornare TableA. Se sei sfortunato, entrambi i processi riescono a completare il primo passo e quindi attendere all'infinito l'altro per completare il secondo passo.

Per inciso, questo è uno dei metodi più comuni per evitare i deadlock: essere coerenti nell'ordine in cui si aggiorna la tabella. Se entrambi i processi hanno aggiornato TableA prima di TableB, il deadlock non si verificherebbe.

Answer 2

ReadComitted di isolamento delle transazioni livello ottiene inizialmente un Shared Lock su una risorsa vale a dire durante la lettura della riga, ma quando si cerca di aggiornare la riga si ottiene un Exclusive lock sulle risorse. Un utente multiplo può avere blocchi condivisi sulle stesse righe e non ha effetto ma appena un utente tenta di aggiornare una riga ottiene un blocco esclusivo sulla riga che può comportare A dead lock quando un utente può inizialmente vedere il record a causa del blocchi condivisi sulla riga ma ora quando l'utente tenta di aggiornarlo ha già un blocco esclusivo su di esso dal primo utente. Immagina uno scenario in cui Utente1 e Utente2 Entrambi hanno blocchi condivisi e quando provano ad aggiornare alcuni record ottengono entrambi blocchi esclusivi sulle righe che l'altro utente deve eseguire per la transazione. questo provocherà un DEAD LOCK.
In caso di DeadLock se il server SQLattenderà per un po 'di tempo e quindi sarà RollBack la transazione che è cheaper per il rollback.
Modifica
Sì, se Utente1 sta solo leggendo i dati e User2 trys per aggiornare alcuni dati e lì un indice non cluster su quella tabella, è possibile.

1) L'utente1 sta leggendo alcuni dati e ottiene un blocco condiviso sull'indice non in cluster per eseguire una ricerca, quindi tenta di ottenere un blocco condiviso nella pagina che contamina i dati per restituire i dati stessi .

2) L'utente2 che sta scrivendo/Aggiornamento prima ottiene un blocco esclusivo nella pagina del database contenente i dati, quindi tenta di ottenere un blocco esclusivo sull'indice per aggiornare l'indice.