In de paper uit 1995, Een kritiek op ANSI SQL-isolatieniveaus , Jim Gray en co, beschreven Phantom Read als:
Daarom betekent een Phantom Read niet dat u gewoon een momentopname kunt retourneren vanaf het begin van de momenteel lopende transactie en doet alsof u hetzelfde resultaat geeft voor een query om u te beschermen tegen de daadwerkelijke Phantom Read-afwijking.
In de oorspronkelijke implementatie van SQL Server 2PL (Two-Phase Locking) impliceerde het retourneren van hetzelfde resultaat voor een query Predicate Locks.
De MVCC (Multi-Version Concurrency Control) Snapshot Isolation (verkeerd Serializable genoemd in Oracle) voorkomt niet dat andere transacties rijen invoegen/verwijderen die voldoen aan dezelfde filtercriteria met een query die al is uitgevoerd en een resultaat heeft geretourneerd dat is ingesteld in onze huidige uitvoering transactie.
Om deze reden kunnen we ons het volgende scenario voorstellen waarin we een verhoging willen toepassen op alle medewerkers:
- 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:
In dit scenario voert de CEO de eerste transactie uit (Tx1), dus:
- Ze controleert eerst de som van alle salarissen in haar bedrijf.
- Ondertussen voert de HR-afdeling de tweede transactie (Tx2) uit, omdat ze net John Doe hebben aangenomen en hem een salaris van 100.000 $ hebben gegeven.
- De CEO besluit dat een verhoging van 10% haalbaar is, rekening houdend met de totale som van de salarissen, niet wetende dat de salarissom met 100.000 is verhoogd.
- Ondertussen is de HR-transactie Tx2 vastgelegd.
- Tx1 is vastgelegd.
Boom! De CEO heeft een besluit genomen op basis van een oude momentopname, waardoor een verhoging mogelijk is die mogelijk niet wordt volgehouden door het huidige bijgewerkte salarisbudget.
U kunt een gedetailleerde uitleg van deze use-case (met veel diagrammen) bekijken in het volgende bericht .
Is dit een Phantom Read of een Schrijf scheef ?
Volgens Jim Gray en co , dit is een Phantom Read omdat de Write Skew is gedefinieerd als:
In Oracle kan de Transaction Manager de bovenstaande anomalie al dan niet detecteren omdat deze geen predikaatvergrendelingen of indexbereikvergrendelingen (volgende-sleutelvergrendelingen) , zoals MySQL.
PostgreSQL slaagt er alleen in om deze anomalie op te vangen als Bob een lezing uitvoert tegen de werknemerstabel, anders wordt het fenomeen niet voorkomen.
UPDATE
Aanvankelijk ging ik ervan uit dat serialisatie ook een tijdsvolgorde zou impliceren. Echter, zoals zeer goed uitgelegd door Peter Bailis , wandklokbestelling of lineariseerbaarheid wordt alleen verondersteld voor strikte serialiseerbaarheid.
Daarom zijn mijn veronderstellingen gemaakt voor een strikt serialiseerbaar systeem. Maar dat is niet wat Serializable zou moeten bieden. Het serialiseerbare isolatiemodel biedt geen garanties over tijd, en bewerkingen mogen opnieuw worden geordend zolang ze equivalent zijn aan een sommige seriële uitvoering.
Daarom kan, volgens de definitie van serializable, een dergelijke Phantom Read optreden als de tweede transactie geen read uitgeeft. Maar in een Strict Serializable-model, het model dat wordt aangeboden door 2PL, zou de Phantom Read worden voorkomen, zelfs als de tweede transactie geen read uitgeeft tegen dezelfde items die we proberen te beschermen tegen phantom reads.