Read committed er et isolationsniveau, der garanterer, at enhver læst data var committed i øjeblikket er læst. Det begrænser simpelthen læseren fra at se nogen mellemliggende, uengageret, 'beskidt' læst. Det giver intet som helst løfte om, at hvis transaktionen genudsender læsningen, vil den finde Samme data, kan data frit ændres, efter at de er blevet læst.
Gentagelig læsning er et højere isolationsniveau, som ud over garantierne for det læste committede niveau også garanterer, at enhver læst data ikke kan ændres , hvis transaktionen læser de samme data igen, vil den finde de tidligere læste data på plads, uændrede og tilgængelige til at læse.
Det næste isolationsniveau, der kan serialiseres, giver en endnu stærkere garanti:Ud over alt, der kan gentages læsegarantier, garanterer det også, at ingen ny data kan ses ved en efterfølgende læsning.
Lad os sige, at du har en tabel T med en kolonne C med en række i, sig, at den har værdien '1'. Og overvej, at du har en simpel opgave som følgende:
BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;
Det er en simpel opgave, der udsteder to læsninger fra tabel T, med en forsinkelse på 1 minut mellem dem.
- under READ COMMITTED kan det andet SELECT returnere hvilket som helst data. En samtidig transaktion kan opdatere posten, slette den, indsætte nye poster. Den anden vælger vil altid se den nye data.
- under REPEATABLE READ er det andet SELECT garanteret at vise mindst de rækker, der blev returneret fra det første SELECT uændret . Nye rækker kan tilføjes ved en samtidig transaktion på det ene minut, men de eksisterende rækker kan ikke slettes eller ændres.
- under SERIALIZABLE læser det andet valg garanteret at se præcis de samme rækker som den første. Ingen række kan ændres eller slettes, eller nye rækker kunne indsættes ved en samtidig transaktion.
Hvis du følger logikken ovenfor, kan du hurtigt indse, at SERIALISERBARE transaktioner, selvom de kan gøre livet nemt for dig, altid fuldstændigt blokerer enhver mulig samtidig operation, da de kræver, at ingen kan ændre, slette eller indsætte nogen række. Standardtransaktionsisoleringsniveauet for .Net System.Transactions scope kan serialiseres, og dette forklarer normalt den afgrundsdybe ydeevne, der resulterer.
Og endelig er der også SNAPSHOT-isolationsniveauet. SNAPSHOT isolationsniveau giver de samme garantier som serialiserbare, men ikke ved at kræve, at ingen samtidige transaktioner kan ændre dataene. I stedet tvinger det enhver læser til at se sin egen version af verden (det er sit eget 'snapshot'). Dette gør det meget nemt at programmere imod samt meget skalerbart, da det ikke blokerer for samtidige opdateringer. Den fordel kommer dog med en pris:ekstra serverressourceforbrug.
Supplerende tekst:
- Isolationsniveauer i databasemotoren
- Samtidighedseffekter
- Valg af rækkeversionsbaserede isolationsniveauer