2.1 Læs uforpligtende
"Transaktionsisolationsniveauet" refererer til graden af beskyttelse, der ydes af de interne mekanismer i DBMS (det vil sige, der ikke kræver speciel programmering) mod alle eller nogle af de ovennævnte typer datainkonsekvenser, der opstår under parallel udførelse af transaktioner. SQL-92-standarden definerer en skala med fire isolationsniveauer:
- Læs uforpligtende
- Læs engageret
- Gentagelig læsning
- Serialiserbar
Den første af dem er den svageste, den sidste er den stærkeste, hver efterfølgende inkluderer alle de foregående.
Det laveste (første) isolationsniveau. Hvis flere parallelle transaktioner forsøger at ændre den samme tabelrække, vil den sidste række have en værdi, der bestemmes af hele sættet af gennemførte transaktioner. I dette tilfælde er det muligt at læse ikke kun logisk inkonsistente data, men også data, hvis ændringer endnu ikke er blevet registreret.
En typisk måde at implementere dette isolationsniveau på er at låse data, mens ændringskommandoen udføres, hvilket sikrer, at ændringskommandoer på de samme rækker, der kører parallelt, faktisk udføres sekventielt, og ingen af ændringerne går tabt. Skrivebeskyttede transaktioner blokerer aldrig under dette isolationsniveau.
2.2 Læst engageret
De fleste industrielle DBMS, især Microsoft SQL Server, PostgreSQL og Oracle, bruger dette niveau som standard. På dette niveau ydes beskyttelse mod udkast, "beskidt" læsning, men under driften af en transaktion kan en anden fuldføres med succes, og ændringerne foretaget af den er rettet. Som et resultat vil den første transaktion arbejde med et andet datasæt.
Implementeringen af en komplet læsning kan være baseret på en af to tilgange: blokering eller versionering.
Blokering af læsbare og foranderlige data.
Det består i det faktum, at skrivetransaktionen blokerer foranderlige data til læsning af transaktioner, der opererer på læst forpligtet niveau eller højere, indtil den er fuldført, hvilket forhindrer "beskidt" læsning, og de data, der er låst af læsetransaktionen, frigives umiddelbart efter operationen er afsluttet SELECT(således kan en "ikke-gentagelig læsning"-situation forekomme på et givet isolationsniveau).
Gemmer flere versioner af rækker, der ændres parallelt.
Hver gang en række ændres, opretter DBMS en ny version af denne række, som den transaktion, der ændrede dataene, fortsætter med at arbejde med, mens enhver anden "læsende" transaktion returnerer den sidst forpligtede version. Fordelen ved denne fremgangsmåde er, at den er hurtigere, fordi den forhindrer blokering. Det kræver dog, i forhold til den første, et væsentligt større forbrug af RAM, som bruges på at opbevare rækkeversioner.
Derudover, når flere transaktioner ændrer data parallelt, kan det skabe en situation, hvor flere samtidige transaktioner foretager inkonsistente ændringer af de samme data (da der ikke er nogen låse, vil intet forhindre dette i at ske). Derefter vil den transaktion, der forpligter sig først, gemme sine ændringer i hoveddatabasen, og de resterende parallelle transaktioner vil være umulige at forpligte (da dette vil føre til tab af opdateringen af den første transaktion). Det eneste, som DBMS kan gøre i en sådan situation, er at rulle resten af transaktionerne tilbage og udstede en fejlmeddelelse "Recorden er allerede blevet ændret".
En specifik implementeringsmetode vælges af DBMS-udviklerne, og i nogle tilfælde kan den tilpasses. Så som standard bruger MS SQL låse, men (i version 2005 og nyere) når databaseparameteren indstilles READ_COMMITTED_SNAPSHOT, skifter den til versioneringsstrategien, Oracle fungerer i starten kun i henhold til det versionerede skema. I Informix kan du forhindre konflikter mellem læse- og skrivetransaktioner ved at indstille en konfigurationsmulighed USELASTCOMMITTED(fra version 11.1), der får den læste transaktion til at modtage de seneste committede data.
2.3 Gentagelig læsning
Det niveau, hvor en læsetransaktion "ikke ser" ændres til de data, den tidligere har læst. Samtidig kan ingen anden transaktion ændre de data, der læses af den aktuelle transaktion, før den slutter.
Låse i delt tilstand anvendes på alle data, der læses af enhver instruktion i en transaktion og tilbageholdes, indtil transaktionen er fuldført. Dette forhindrer andre transaktioner i at ændre rækker, der blev læst af den afventende transaktion. Andre transaktioner kan dog indsætte nye linjer, der matcher søgebetingelserne for instruktioner indeholdt i den aktuelle transaktion. Når sætningen genstartes af den aktuelle transaktion, vil nye rækker blive hentet, hvilket resulterer i en fantomlæsning.
Da delte låse holdes indtil slutningen af transaktionen, i stedet for at blive frigivet i slutningen af hver erklæring, er graden af samtidighed lavere end isolationsniveauet READ COMMITTED. Derfor anbefales det generelt ikke at bruge dette og højere transaktionsniveauer unødigt.
2.4 Serialiserbar
Det højeste niveau af isolation; transaktioner er fuldstændig isoleret fra hinanden, hver enkelt udføres, som om der ikke var nogen parallelle transaktioner. Det er kun på dette niveau, at samtidige transaktioner ikke er underlagt "phantom read"-effekten.
2.5 Understøttelse af transaktionsisolering i ægte DBMS
Transaktionelle DBMS understøtter ikke altid alle fire niveauer og kan også introducere yderligere. Der er også forskellige nuancer i at give isolering.
Så i princippet understøtter Oracle ikke nul-niveauet, da dets implementering af transaktioner udelukker "beskidte læsninger", og formelt ikke tillader indstilling af gentaget læseniveau, det vil sige, at det kun understøtter (som standard) Read committedog Serializable. På samme tid, på niveauet for individuelle kommandoer, garanterer det faktisk læsegentagelighed (hvis en kommando SELECTi den første transaktion vælger et sæt rækker fra databasen, og på dette tidspunkt ændrer en parallel anden transaktion nogle af disse rækker, så resultatsæt modtaget af den første transaktion vil indeholde uændrede rækker, som om der ikke var nogen anden transaktion). Oracle understøtter også såkaldte READ-ONLYtransaktioner, som svarer til Serializable, men kan ikke selv ændre dataene.
Og Microsoft SQL Server understøtter alle fire standardtransaktionsisoleringsniveauer, og desuden SNAPSHOT-niveauet, hvor transaktionen ser den datatilstand, der blev begået, før den blev lanceret, såvel som de ændringer, der er foretaget af sig selv, det vil sige, den opfører sig som hvis den modtages ved opstart, et øjebliksbillede af DB-dataene og arbejder med dem. Forskellen fra Serialized er, at der ikke bruges låse, men som følge heraf er det muligvis ikke muligt at foretage ændringer, hvis en samtidig transaktion har ændret de samme data før; i dette tilfælde vil den anden transaktion, når den forsøges at udføre, COMMITvise en fejlmeddelelse og blive annulleret.