Lezen vastgelegd is een isolatieniveau dat garandeert dat alle gelezen gegevens toegezegd zijn op dit moment wordt gelezen. Het weerhoudt de lezer er simpelweg van om tussentijdse, vrijblijvende, 'vuile' lectuur te zien. Het belooft geenszins dat als de transactie de read opnieuw uitgeeft, de Same . zal worden gevonden gegevens, gegevens kunnen vrij worden gewijzigd nadat ze zijn gelezen.
Herhaalbaar lezen is een hoger isolatieniveau, dat naast de garanties van het read-commit-niveau, ook garandeert dat gelezen gegevens niet kunnen veranderen , als de transactie dezelfde gegevens opnieuw leest, vindt het de eerder gelezen gegevens op hun plaats, ongewijzigd en beschikbaar om te lezen.
Het volgende isolatieniveau, serialiseerbaar, zorgt voor een nog sterkere garantie:naast alle herhaalbare leesgaranties, garandeert het ook dat geen nieuwe gegevens kan worden gezien door een volgende lezing.
Stel dat u een tabel T heeft met een kolom C met één rij erin, stel dat deze de waarde '1' heeft. En bedenk dat je een simpele taak hebt zoals de volgende:
BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;
Dat is een eenvoudige taak die twee reads uit tabel T afgeeft, met een vertraging van 1 minuut ertussen.
- onder READ COMMITTED kan de tweede SELECT elke . teruggeven gegevens. Een gelijktijdige transactie kan het record bijwerken, verwijderen en nieuwe records invoegen. De tweede selectie ziet altijd de nieuwe gegevens.
- onder REPEATABLE READ wordt gegarandeerd dat de tweede SELECT ten minste de rijen weergeeft die zijn geretourneerd door de eerste SELECT ongewijzigd . Nieuwe rijen kunnen worden toegevoegd door een gelijktijdige transactie in die ene minuut, maar de bestaande rijen kunnen niet worden verwijderd of gewijzigd.
- onder SERIALIZABLE leest de tweede selectie gegarandeerd exact dezelfde rijen als de eerste. Geen rij kan worden gewijzigd, noch verwijderd, noch nieuwe rijen kunnen worden ingevoegd door een gelijktijdige transactie.
Als u de bovenstaande logica volgt, kunt u zich snel realiseren dat SERIALIZABLE-transacties, hoewel ze het leven misschien gemakkelijk voor u maken, altijd volledig blokkeren elke mogelijke gelijktijdige bewerking, omdat ze vereisen dat niemand een rij kan wijzigen, verwijderen of invoegen. Het standaard transactie-isolatieniveau van de .Net System.Transactions scope is serialiseerbaar, en dit verklaart meestal de verschrikkelijke prestaties die eruit voortvloeien.
En tot slot is er ook nog het SNAPSHOT-isolatieniveau. Het SNAPSHOT-isolatieniveau biedt dezelfde garanties als serialiseerbaar, maar niet door te vereisen dat geen enkele gelijktijdige transactie de gegevens kan wijzigen. In plaats daarvan dwingt het elke lezer om zijn eigen versie van de wereld te zien (het is een eigen 'snapshot'). Dit maakt het heel gemakkelijk om tegen te programmeren en ook zeer schaalbaar omdat het gelijktijdige updates niet blokkeert. Dat voordeel heeft echter een prijs:extra verbruik van serverbronnen.
Aanvullende leest:
- Isolatieniveaus in de database-engine
- Gelijktijdigheidseffecten
- Isolatieniveaus op basis van rijversies kiezen