Read Committed vs Read Uncommitted si les deux transactions ne sont pas annulées

Si vous travaillez avec le niveau d'isolement de lecture validée, T2 doit attendre à l'étape 4 que T1 se termine et valide son travail. De plus, T1 à l'étape 6 ne peut pas trouver Nome avec Maria% ainsi, supprime 0 lignes.

mais au niveau d'isolement lecture non validée, les deux opérations de lecture / écriture peuvent être effectuées simultanément.

Résultat Pour le niveau d'isolement de lecture validée,

Pessoas (Joao Manuel Silva, 9699...)

alors que pour le niveau d'isolement non validé en lecture

Pessoas (Jaoa Silva, 96.....)
Pessoas (Maria Fon..., 9199...)
Pessoas (Joao Manuel Silva, 9699...)

p >

READ UNCOMMITTED vous permet de lire les données sales qui n'ont pas été validées par d'autres transactions. Le moteur SQL Server ignore tout verrou sous la table en cours de lecture et lit les données directement à partir de la mémoire.

READ COMMITTED lira les données qui ont déjà été COMMITTED mais attendra si les données sont affectées par une autre transaction.

Donc, dans l'exemple fourni, le système n'est pas seulement en train de lire mais aussi d'essayer de SUPPRIMER une ligne qui n'a toujours pas été COMMISE, donc, les deux vont attendre que l'autre transaction se termine, donc l'exemple est exemple pour DEADLOCK.

Pour illustrer les différences entre COMMITTED et UNCOMMITTED, je vais vous montrer un exemple simple et clair que nous exécuterons deux fois, dans les deux modes.

DELETE FROM Audit WHERE PrevValue LIKE 'AAA';   

Votre exemple n'a rien à voir avec les Niveaux d'isolement . C'est parce qu'ils affectent le comportement des lecteurs , pas des écrivains , et dans votre exemple, il n'y a que des écrivains .

Vous devriez vous référer à cet article BOL: Comprendre les niveaux d'isolement cela dit

Le choix d'un niveau d'isolement des transactions n'affecte pas les verrous qui sont acquis pour protéger les modifications des données . Une transaction obtient toujours un verrou exclusif sur toutes les données qu'il modifie et maintient ce verrou jusqu'à la transaction se termine, quel que soit le niveau d'isolement défini pour cette transaction. Pour opérations de lecture , niveaux d'isolement des transactions définissent principalement le niveau de protection contre les effets modifications apportées par d'autres transactions.

Dans votre exemple, aucune des transactions ne lit , elles sont toutes deux modifiées . La première transaction acquerra X sur la RID ou la clé intéressée (dépend de la structure de la table, s'il s'agit d'une table en tas ou en cluster) - I ' Je l'appellerai res_1 à l'avenir - pour l'insertion et le conservera pendant toute la durée de la transaction (il aura également IX sur la page et objet ), et il en va de même pour la première instruction de la deuxième transaction: il acquerra X sur res_2 lors de l'insertion.

Lors de la tentative DELETE , la deuxième transaction sera bloquée car elle ne pourra pas obtenir X (ou U s'il n'y a pas d'index sur < code> où condition), car il y a déjà X sur la même ressource ( res_1 ) détenue par la première transaction. Et il n'y aura pas de deuxième INSERT dans la deuxième transaction car le précédent DELETE est bloqué.

Enfin, lorsque la première transaction tente son DELETE , elle a besoin de X ou U (selon l'existence de l'index) sur res_2 , mais il est déjà bloqué avec X par tran2, il est donc également bloqué et il n'y a pas de sortie de cette situation, chaque session attend qu'une autre session se termine et aucune session ne peut se terminer, à ce moment un blocage se produit et le serveur le résoudra en annulant l'une des transactions.

Veuillez trouver le lien https://www.postgresql.org/docs /9.5/transaction-iso.html

Je réécris

13.2.1. Lire le niveau d'isolement validé

Read Committed est le niveau d'isolement par défaut dans PostgreSQL. Lorsqu'une transaction utilise ce niveau d'isolement, une requête SELECT (sans Clause FOR UPDATE / SHARE ) ne voit que les données validées avant la requête a commencé; il ne voit jamais ni les données non validées ni les modifications validées pendant l'exécution de la requête par des transactions simultanées. En effet, un La requête SELECT voit un instantané de la base de données à l'instant où la requête commence à s'exécuter. Cependant, SELECT voit les effets de mises à jour précédentes exécutées dans sa propre transaction, même si elles ne sont pas encore engagés. Notez également que deux commandes SELECT successives peut voir différentes données, même si elles se trouvent dans un seul transaction, si d'autres transactions commettent des modifications après la première SELECT démarre et avant le début du deuxième SELECT .

UPDATE , DELETE , SELECT FOR UPDATE et SELECT FOR SHARE les commandes se comportent de la même manière que SELECT en termes de recherche de cible lignes: ils ne trouveront que les lignes cibles qui ont été validées au heure de début de la commande. Cependant, une telle ligne cible peut avoir déjà été mis à jour (ou supprimé ou verrouillé) par une autre transaction simultanée par le moment où il est trouvé. Dans ce cas, le programme de mise à jour potentiel attendra la première transaction de mise à jour à valider ou à annuler (si elle est toujours en cours). Si le premier programme de mise à jour revient en arrière, ses effets sont annulé et le deuxième programme de mise à jour peut procéder à la mise à jour du ligne trouvée à l'origine. Si le premier programme de mise à jour s'engage, le deuxième programme de mise à jour ignorera la ligne si le premier programme de mise à jour l'a supprimée, sinon elle essayez d'appliquer son opération à la version mise à jour de la ligne. le la condition de recherche de la commande (la clause WHERE ) est réévaluée pour voir si la version mise à jour de la ligne correspond toujours à la recherche état. Si tel est le cas, le deuxième programme de mise à jour poursuit son opération en utilisant la version mise à jour de la ligne. Dans le cas de SELECT FOR UPDATE et SELECT FOR SHARE , cela signifie qu'il s'agit de la version mise à jour de la ligne qui est verrouillé et renvoyé au client.