Read committed är en isoleringsnivå som garanterar att all data som lästs var committed för tillfället läses. Det hindrar helt enkelt läsaren från att se någon mellanliggande, oengagerad, "smutsig" läsning. Det ger inget som helst löfte att om transaktionen återutfärdar läsningen, kommer att hitta Samma data, är data fria att ändra efter att de lästes.
Repeterbar läsning är en högre isoleringsnivå, som förutom garantierna för den läskommitterade nivån också garanterar att all data som läses inte kan ändras , om transaktionen läser samma data igen, kommer den att hitta tidigare lästa data på plats, oförändrade och tillgängliga att läsa.
Nästa isoleringsnivå, som kan serialiseras, ger en ännu starkare garanti:förutom allt repeterbara läsgarantier, garanterar den också att ingen ny data kan ses av en efterföljande läsning.
Säg att du har en tabell T med en kolumn C med en rad i den, säg att den har värdet '1'. Och tänk på att du har en enkel uppgift som följande:
BEGIN TRANSACTION;
SELECT * FROM T;
WAITFOR DELAY '00:01:00'
SELECT * FROM T;
COMMIT;
Det är en enkel uppgift som ger två läsningar från tabell T, med en fördröjning på 1 minut mellan dem.
- under READ COMMITTED kan den andra SELECT returnera vilket som helst data. En samtidig transaktion kan uppdatera posten, radera den, infoga nya poster. Den andra markeringen kommer alltid att se den nya data.
- under REPEATABLE READ kommer den andra SELECT garanterat att visa åtminstone raderna som returnerades från den första SELECT oförändrade . Nya rader kan läggas till genom en samtidig transaktion under den ena minuten, men de befintliga raderna kan inte tas bort eller ändras.
- under SERIALIZABLE står det andra valet garanterat att se exakt samma rader som den första. Ingen rad kan ändras, inte tas bort eller nya rader kan infogas vid en samtidig transaktion.
Om du följer logiken ovan kan du snabbt inse att SERIALISERbara transaktioner, även om de kan göra livet enkelt för dig, alltid helt blockerande alla möjliga samtidiga operationer, eftersom de kräver att ingen kan ändra, ta bort eller infoga någon rad. Standardtransaktionsisoleringsnivån för .Net System.Transactions scope kan serialiseras, och detta förklarar vanligtvis den urusla prestandan som blir resultatet.
Och slutligen finns det också SNAPSHOT-isoleringsnivån. SNAPSHOT-isoleringsnivån ger samma garantier som kan serialiseras, men inte genom att kräva att ingen samtidig transaktion kan ändra data. Istället tvingar den varje läsare att se sin egen version av världen (det är en egen "snapshot"). Detta gör det väldigt enkelt att programmera mot samt väldigt skalbart då det inte blockerar samtidiga uppdateringar. Den fördelen kommer dock med ett pris:extra serverresursförbrukning.
Tilläggstext:
- Isoleringsnivåer i databasmotorn
- Samtidighetseffekter
- Välja radversionsbaserade isoleringsnivåer