Dans l'article de 1995, Une critique des niveaux d'isolation SQL ANSI , Jim Gray et co, ont décrit Phantom Read comme :
Par conséquent, une lecture fantôme ne signifie pas que vous pouvez simplement renvoyer un instantané au début de la transaction en cours d'exécution et prétendre que fournir le même résultat pour une requête va vous protéger contre l'anomalie réelle de lecture fantôme.
Dans l'implémentation d'origine de SQL Server 2PL (verrouillage en deux phases), renvoyer le même résultat pour une requête impliquait des verrous de prédicat.
L'isolement d'instantané MVCC (Multi-Version Concurrency Control) (nommé à tort sérialisable dans Oracle) n'empêche pas réellement d'autres transactions d'insérer/supprimer des lignes qui correspondent aux mêmes critères de filtrage avec une requête qui a déjà été exécutée et a renvoyé un ensemble de résultats dans notre exécution actuelle. transaction.
Pour cette raison, nous pouvons imaginer le scénario suivant dans lequel nous souhaitons appliquer une augmentation à tous les employés :
- Tx1 :
SELECT SUM(salary) FROM employee where company_id = 1; - Tx2 :
INSERT INTO employee (id, name, company_id, salary) VALUES (100, 'John Doe', 1, 100000); - Tx1 :
UPDATE employee SET salary = salary * 1.1; - Tx2 :
COMMIT; - Tx1 :
COMMIT:
Dans ce scénario, le PDG exécute la première transaction (Tx1), donc :
- Elle vérifie d'abord la somme de tous les salaires de son entreprise.
- Pendant ce temps, le service des ressources humaines gère la deuxième transaction (Tx2) car ils viennent de réussir à embaucher John Doe et lui ont donné un salaire de 100 000 $.
- Le PDG décide qu'une augmentation de 10 % est possible en tenant compte de la somme totale des salaires, sans savoir que la somme des salaires a augmenté de 100 000.
- Pendant ce temps, la transaction HR Tx2 est validée.
- Tx1 est engagé.
Boom! Le PDG a pris une décision sur un ancien instantané, accordant une augmentation qui pourrait ne pas être soutenue par le budget salarial actualisé actuel.
Vous pouvez voir une explication détaillée de ce cas d'utilisation (avec beaucoup de diagrammes) dans le post suivant .
S'agit-il d'une lecture fantôme ou d'un Ecriture inclinée ?
Selon Jim Gray et co , il s'agit d'une lecture fantôme puisque l'inclinaison d'écriture est définie comme :
Dans Oracle, le gestionnaire de transactions peut ou non détecter l'anomalie ci-dessus car il n'utilise pas de verrous de prédicat ou verrous de plage d'index (verrous à clé suivante) , comme MySQL.
PostgreSQL parvient à détecter cette anomalie uniquement si Bob émet une lecture sur la table employee, sinon le phénomène n'est pas empêché.
MISE À JOUR
Au départ, je supposais que la sérialisabilité impliquerait également une commande temporelle. Cependant, comme très bien expliqué par Peter Bailis , l'ordre de l'horloge murale ou la linéarisabilité ne sont supposés que pour la sérialisabilité stricte.
Par conséquent, mes hypothèses ont été faites pour un système sérialisable strict. Mais ce n'est pas ce que Serializable est censé offrir. Le modèle d'isolement sérialisable ne donne aucune garantie sur le temps, et les opérations sont autorisées à être réordonnées tant qu'elles sont équivalentes à un some exécution en série.
Par conséquent, selon la définition sérialisable, une telle lecture fantôme peut se produire si la deuxième transaction n'émet aucune lecture. Mais, dans un modèle Strict Serializable, celui proposé par 2PL, la lecture fantôme serait empêchée même si la deuxième transaction n'émet pas de lecture sur les mêmes entrées que nous essayons de protéger contre les lectures fantômes.
